OpenBSD Mail Box: September 2017

Saturday, September 30, 2017

Re: aarch64 bulk build report

On Sat, Sep 30, 2017 at 03:06:02AM -0600, phessler@openbsd.org wrote:
> bulk build on arm64.ports.openbsd.org
> started on Fri Sep 8 11:23:32 MDT 2017
> finished at Sat Sep 30 03:05:09 MDT 2017
> lasted 22D08h41m
> done with kern.version=OpenBSD 6.2-beta (GENERIC) #3: Fri Sep 8 05:14:33 MDT 2017
>
> built packages:8005
> Sep 8:352
> Sep 9:333
> Sep 10:920
> Sep 11:1
> Sep 12:2
> Sep 16:53
> Sep 17:1765
> Sep 18:558
> Sep 19:761
> Sep 26:859
> Sep 27:796
> Sep 28:464
> Sep 29:1140
>
>
> build failures: 232
> http://build-failures.rhaalovely.net//aarch64/2017-09-08/archivers/lzip/clzip.log
> http://build-failures.rhaalovely.net//aarch64/2017-09-08/archivers/lzip/lzip.log
> http://build-failures.rhaalovely.net//aarch64/2017-09-08/archivers/lzip/lziprecover.log
> http://build-failures.rhaalovely.net//aarch64/2017-09-08/archivers/lzip/pdlzip.log
> http://build-failures.rhaalovely.net//aarch64/2017-09-08/archivers/lzip/plzip.log

/usr/sbin/pkg_add -aI -Dunsigned -Drepair lunzip-1.9 lzlib-1.9
Error: /dev/sd0m is not large enough (/var/db/pkg/lunzip-1.9/+DESC)

When you fix that problem, the lzip programs will build fine.

> http://build-failures.rhaalovely.net//aarch64/2017-09-08/lang/gambit.log

MAXSSIZ is ((paddr_t)8*1024*1024) on arm64.

OK?

diff -r 4480970ebbd6 Makefile
--- Makefile Fri Sep 29 23:36:03 2017 +0000
+++ Makefile Sun Oct 01 04:29:21 2017 +0200
@@ -3,6 +3,7 @@
COMMENT= complete, efficient and reliable implementation of Scheme

V= 4.8.8
+REVISION= 0
DISTNAME= gambit-v${V:S/./_/g}
PKGNAME= gambit-$V
API_V= ${V:R:S/./0/}00${V:E}
@@ -30,10 +31,8 @@

MAKE_FILE= ${WRKSRC}/makefile

-# On sparc64, gcc crashes with the default stack limit:
-# "cc: Internal error: Illegal instruction" on _gambc.c
do-build:
- ulimit -s 12288 && cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
+ ulimit -s ${STACK_SIZE} && cd ${WRKSRC} && ${SETENV} ${MAKE_ENV} \
${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} ${ALL_TARGET}

do-test:
@@ -46,4 +45,12 @@
CFLAGS += -O0
.endif

+# On sparc64, gcc crashes with the default stack limit:
+# "cc: Internal error: Illegal instruction" on _gambc.c
+.if ${MACHINE_ARCH} == "sparc64"
+STACK_SIZE = 12288
+.else
+STACK_SIZE = 8192
+.endif
+
.include <bsd.port.mk>

Apollo Lake

Hi Misc,

The motherboard on my desktop machine just died. I would like to go
fanless embedded. Something like ASRock J3455-ITX.

https://www.newegg.com/Product/Product.aspx?Item=N82E16813157728&ignorebbr=1

However I am bit concern about Apollo Lake family of products. Can
anyone post a dmesg? I am open for any suggestions.

Best,
Predrag

Re: the whole greylisting, spam filtering thing

Hi Markus/all,

On Fri, 29 Sep 2017 15:06:29 +0200 Markus Rosjat wrote:
> ... greylisting ... like outlook.com and mails ending up delayed
> for ever....

The 'ungrey-robins' tool automatically solves this problem for
round-robin sending servers (Google, Outlook, Amazon, Yahoo, BT, etc.)

Start with the README & see the logs directory for evidence:
http://web.Britvault.Co.UK/products/ungrey-robins/

Otherwise;- simply set spamd's greylisting expire time to 4 days, not 4
hours. I ran servers this way for years - the mail does come through...

Cheers,
--
Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7

Re: ports broken on clang archs

On Fri, Sep 29, 2017 at 06:40:03PM +0100, Stuart Henderson wrote:
> On 2017/09/29 18:50, Jeremie Courreges-Anglas wrote:
> > I moved texmacs, avidemux and ti-msp430-gcc to COMPILER=base-gcc.
>
> Thanks.
>
> > graphics/asymptote is affected too:
> >
> > NOT_FOR_ARCHS= ${CLANG_ARCHS} # hangs during build, while running
> > # ../asy -dir ../base -config "" -render=0 -f pdf -noprc cube.asy
> > # in WRKSRC/doc. run the abovef command with -vvv for more info.
> > # this does not fail with ports clang, though.
>
> Oh I think we could do "base-gcc ports-clang" here now that we have it...

Note that in my experience, most of the clang "failures" are actually
code that has undefined behavior, and thus fails.

Re: NEW: games/soyuz

On 2017/09/30 00:41, Ian Sutton wrote:
> Hello, I've ported some software.
>
> http://ce.gl/soyuz-port.tgz
>
> games/soyuz is a spaceflight simulator used to train Soviet cosmonauts
> to fly fourth generation Soyuz rockets in the mid-to-late 1980s, it was
> designed and written by members of the Soviet space program. It
> specifically simulates the instrumentation and control interface for the
> descent module re-entering the atmosphere, and provides a virtual
> interface that functionally matches hardware found in real-life Soyuz modules.
>
> Here are some screenshots:
>
> https://ce.gl/soyuz/
>
> It passes portcheck:
>
> 0 $ pwd
> /usr/ports/games/soyuz
> 0 $ /usr/ports/infrastructure/bin/portcheck
> games/soyuz
>
> However I'm not very experienced with writing ports and would appreciate
> feedback.
>
>
> PS - I'd be interested in hearing from anyone who manages to land,
> because this is beyond difficult :)
>
> Ian
>

Diff on top to tidy it up a bit.

I don't read Russian (totally killing my chances of being an astronaut
;) but is there something on the screen you get by pressing T that would
pass for a version number? Is there copyright information anywhere
that would let us fill in the markers better?

(btw, it's easier to review if you send a tar with just portname/* rather
than usr/ports/category/portname/* .. or category/portname/* if there are
multiple ports in different categories within one submission).

Interesting idea to use dosbox in the port like this :-)

diff --git Makefile Makefile
index f499718..c40031e 100644
--- Makefile
+++ Makefile
@@ -1,51 +1,35 @@
# $OpenBSD$

-COMMENT = Training program for the Soyuz-TMA spacecraft.
-DISTNAME = soyuz-1.0
-CATEGORIES = games
+COMMENT = training program for the Soyuz-TMA spacecraft
+
+PKGNAME = soyuz-1.0
+DISTNAME = soyuz
+DISTSUBDIR = ${PKGNAME}
+EXTRACT_SUFX = .zip

-DISTFILES = soyuz.zip
-DISTFILES += soyuz.conf
-DISTFILES += soyuz.sh
+CATEGORIES = games

MAINTAINER = Ian Sutton <ians@openbsd.org>

-PERMIT_PACKAGE_CDROM = N/A
+# no license information?
+PERMIT_PACKAGE_CDROM = no license information?
PERMIT_PACKAGE_FTP = Yes

-MASTER_SITES = https://ce.gl/ports/dist/soyuz/
+HOMEPAGE = https://archive.org/details/demo211

-EXTRACT_SUFX = .zip
-EXTRACT_ONLY = soyuz.zip
+MASTER_SITES = https://ce.gl/ports/dist/soyuz/

-BUILD_DEPENDS = archivers/unzip
-RUN_DEPENDS = emulators/dosbox
+RUN_DEPENDS = emulators/dosbox

-NO_BUILD = Yes
-NO_TEST = Yes
-NO_CONFIGURE = Yes
+NO_BUILD = Yes
+NO_TEST = Yes
+WRKDIST = ${WRKDIR}

do-install:
- mkdir ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin \
- ${WRKDIR}/COLOR.SF ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin \
- ${WRKDIR}/EPROM.DAT ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin \
- ${WRKDIR}/EPROMSPS.DAT ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin \
- ${WRKDIR}/INPU.EXE ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin \
- ${WRKDIR}/KS020.DAT ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin \
- ${WRKDIR}/MODEL.DAT ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin \
- ${WRKDIR}/MONO.SF ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin \
- ${WRKDIR}/RUNTIME.WP ${PREFIX}/libexec/soyuz/
- install -D -c -m 755 -o root -g bin ${DISTDIR}/soyuz.sh ${PREFIX}/bin/soyuz
- install -D -c -m 755 -o root -g bin ${DISTDIR}/soyuz.conf \
- ${PREFIX}/libexec/soyuz/soyuz.conf
-
+ ${INSTALL_DATA_DIR} ${PREFIX}/libexec/soyuz/
+ cd ${WRKDIR}; ${INSTALL_DATA} COLOR.SF EPROM.DAT EPROMSPS.DAT \
+ INPU.EXE KS020.DAT MODEL.DAT MONO.SF RUNTIME.WP \
+ ${FILESDIR}/soyuz.conf ${PREFIX}/libexec/soyuz/
+ ${INSTALL_SCRIPT} ${FILESDIR}/soyuz.sh ${PREFIX}/bin/soyuz

.include <bsd.port.mk>

Re: zbar, python module import core dumps

On 2017/09/30 13:00, Jonathan Gray wrote:
> On Fri, Sep 29, 2017 at 04:07:08PM -0400, Jiri B wrote:
> > Hi,
> >
> > this simple things make python core dump. Anything more for this
> > issue report I could provide?
> >
> > Jiri
> >
> > # python2.7 -c 'import zbar'
> > Segmentation fault (core dumped)
>
> Here is a patch from debian that seems to avoid the crash.
> I never used the python api back when I actually used zbar.

OK for after unlock.

> You will need to create the patches directory before applying it.

patch -p0 does that automatically, by the way.

> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/graphics/zbar/Makefile,v
> retrieving revision 1.24
> diff -u -p -r1.24 Makefile
> --- Makefile 17 Jun 2017 11:36:16 -0000 1.24
> +++ Makefile 30 Sep 2017 02:52:00 -0000
> @@ -2,7 +2,7 @@
>
> COMMENT= ZBar barcode reader
> DISTNAME= zbar-0.10
> -REVISION= 16
> +REVISION= 17
>
> SHARED_LIBS= zbar 0.0 \
> zbargtk 0.0
> --- /dev/null Sat Sep 30 12:55:41 2017
> +++ patches/patch-python_imagescanner_c Sat Sep 30 12:53:24 2017
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +Index: python/imagescanner.c
> +--- python/imagescanner.c.orig
> ++++ python/imagescanner.c
> +@@ -67,7 +67,8 @@ imagescanner_get_results (zbarImageScanner *self,
> + }
> +
> + static PyGetSetDef imagescanner_getset[] = {
> +- { "results", (getter)imagescanner_get_results, },
> ++ { "results", (getter)imagescanner_get_results, NULL, NULL, NULL},
> ++ {NULL} /* Sentinel */
> + };
> +
> + static PyObject*
>

Re: the whole greylisting, spam filtering thing

On 09/30/17 04:39, Stuart Henderson wrote:
>> It won't surprise anyone here that I disagree with the assertion that
>> greylisting is in any way outdated. Come back with that assertion when
>> the SMTP RFC is amended to drop the retry requirement.
>
> These senders do retry, but not always from the same source address.
> Are you aware of any requirement in RFC5321 about source addresses
> of retries? I didn't find any when I looked (or even a requirement that
> retries are done over the same IP protocol version).

We had hoped for a clarification of the relevant parts in that RFC
update, but unfortunately the RFC still does not require retrying from
the same IP address. Back when the original was written it may have been
the default assumption that retries would come from the same host, but
even then at least some site would have had more than one outgoing mail
exchanger in place.

> Greylisting still has its place, but with the way email operates today,
> exemptions are unavoidable if you have a requirement to communicate
> reliably with users of many email services. Especially with a strict
> per-host greylisting implementation, where you don't get any benefit
> from the common thing where senders often arrange to retry from within
> the same v4 /24.

Unfortunately some senders (IIRC outlook.com being one) don't
necessarily stay within the same /24, even. That's why we need the
nospamd trick. And this will become incrementally more fun (fsvo) as
more of the traffic moves to IPv6.

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: IPsec (isakmpd) in rdomain non zero needs default route

On 2017-09-29, BARDOU Pierre <bardou.p@mipih.fr> wrote:
> Hello,
>
> I don't know if I should post this to misc@ or bugs@...
> If this is the wrong list tell me I'll file a proper bug report.
>
> I need to add a default route in rdomain 1 to be able to use the tunnels created by isakmpd.
> That is a bit weird, routes should be injected by isakmpd.

It's more of a feature request than a bug - the IPsec implementations on
OpenBSD only work with flows, there isn't a nice way to use them with routes.

It would be extremely useful though, especially in conjunction with dynamic
routing. For example: it would allow a cluster of health-checked IPsec
gateways behind relayd, advertising client routes to the rest of your
network via bgp/ospf. Sure it relies on NAT-T and DPD to notice when a
gateway goes down, but then there's no horrible mess syncing the SADB
between machines.

> My guess is that the problem is quite the same as with inter-domain
> routing with PF : destination lookup is done BEFORE processing by PF or
> IPSEC (explained here for PF :
> https://www.packetmischief.ca/2011/09/20/virtualizing-the-openbsd-routing-table/).
> So when there is no default route, it fails.

There doesn't need to be a *default* route, but there must be *a* route for
the flow destination.

> If this guess is right, the problem shoud also happen on rdomain 0.

Yes.

> Could you fix the code to make it work without the default route ?

What you propose here would mean changing pieces deep in the network
stack with tentacles in various subsystems.

> Or, as I suspect, is this too difficult and I'll go with my workaround ?

There are ways to get IPsec working with routes, but not really nice ones:

- you can configure a gif or gre tunnel on top of IKE & IPsec transport
mode at both sides, but it's a two-step config, and the other side needs
to support gif/gre.

- you can configure a gif tunnel with IPsec transport mode at one
end, and the other end can be normally configured with tunnel mode if
you like (so you can use some endpoint at the other side that doesn't
explicitly support gif). This works because gif(4) tunnel headers are
*identical* to the IPsec tunnel mode ones. The problem is that this
only currently works on OpenBSD with manual keying, not IKE.

In terms of code changes, I think the best situation would be for an
IPsec daemon to be able to negotiate tunnel mode with the peer via
IKE, but actually install just a "proto ipencap" flow between the two
endpoint hosts (*not* for the tunnel addresses), and create a gif
interface with the correct addressing so the tunnel packets flow.
Note this would be a purely userland change.

The other endpoint would just see a normal tunnel configuration so it
would be perfect for talking to other vendor's implementations.

If it helps illustrate it, here's a worked example with manual flows:
http://bodgitandscarper.co.uk/openbsd/openbsd-ipsec-and-rfc-3884/

Re: the whole greylisting, spam filtering thing

> I start greylisting on the firewall and thats ok but should I implement
> a dedicated system for rspamd and relay the "ok-Mails" from there to the
> mailsystem or simply run rspamd on the mailsystem und plug it front of
> the mailserver like postfix?

aha so if you are using Postfix then there are plenty anti-spam features
that truly reduces the amount of spam and almost wipes it all out
**during the SMTP session**: `man 5 postconf` and search for those
patterns (this is postfix 3.1).

# NETWORK restrictions (smtpd_client_restrictions)
check_policy_service unix:private/policy
reject_unknown_client_hostname
check_client_access hash:/etc/postfix/client_access
reject_rbl_client ...
reject_unauth_pipelining

unknown_client_reject_code = 554
smtpd_data_restrictions = reject_unauth_pipelining

# HELO/EHLO restrictions
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
regexp:/etc/postfix/helo.regexp

# MAIL FROM restrictions
check_sender_access hash:/etc/postfix/sender_access,
reject_non_fqdn_sender,
reject_unknown_sender_domain

# RCPT TO restrictions
reject_non_fqdn_recipient,
reject_unknown_recipient_domain

unknown_address_reject_code = 554

if some spam comes through that, it is a pretty one (and even passed tru
the SPF check). This already gets rid of 98% of the spam for me.
Adding rspamd or whatever milter on top of that would clearly get you to
99%. No greylisting is needed.

Eventually make sure STARTTLS is enabled so the MX talk through TLS,
setup your SPF records for your domain and eventually setup DKIM.

Re: the whole greylisting, spam filtering thing

Hi,

thank you all for the helpful input on that subject. I have one last
thing to ask about it.

What would be a good approach to implementing rspamd?

I start greylisting on the firewall and thats ok but should I implement
a dedicated system for rspamd and relay the "ok-Mails" from there to the
mailsystem or simply run rspamd on the mailsystem und plug it front of
the mailserver like postfix?

Regards

--
Markus Rosjat fon: +49 351 8107223 mail: rosjat@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220 fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
you print it, think about your responsibility and commitment to the
ENVIRONMENT

Re: zbar, python module import core dumps

On Sat, Sep 30, 2017 at 01:00:11PM +1000, Jonathan Gray wrote:
> > # python2.7 -c 'import zbar'
> > Segmentation fault (core dumped)
>
> Here is a patch from debian that seems to avoid the crash.
> I never used the python api back when I actually used zbar.

Thank you, works OK on amd64. Tested with qrtools[1] to decode
a sample QR code from internet.

[1] https://ralgozino.wordpress.com/2011/06/13/how-to-create-and-decode-a-qr-code-in-python-using-qrtools/

Jiri

aarch64 bulk build report

Friday, September 29, 2017

NEW: games/soyuz

Hello, I've ported some software.

http://ce.gl/soyuz-port.tgz

games/soyuz is a spaceflight simulator used to train Soviet cosmonauts
to fly fourth generation Soyuz rockets in the mid-to-late 1980s, it was
designed and written by members of the Soviet space program. It
specifically simulates the instrumentation and control interface for the
descent module re-entering the atmosphere, and provides a virtual
interface that functionally matches hardware found in real-life Soyuz modules.

Here are some screenshots:

https://ce.gl/soyuz/

It passes portcheck:

0 $ pwd
/usr/ports/games/soyuz
0 $ /usr/ports/infrastructure/bin/portcheck
games/soyuz

However I'm not very experienced with writing ports and would appreciate
feedback.

PS - I'd be interested in hearing from anyone who manages to land,
because this is beyond difficult :)

Ian

Re: zbar, python module import core dumps

On Fri, Sep 29, 2017 at 04:07:08PM -0400, Jiri B wrote:
> Hi,
>
> this simple things make python core dump. Anything more for this
> issue report I could provide?
>
> Jiri
>
> # python2.7 -c 'import zbar'
> Segmentation fault (core dumped)

Here is a patch from debian that seems to avoid the crash.
I never used the python api back when I actually used zbar.

You will need to create the patches directory before applying it.

Index: Makefile
===================================================================
RCS file: /cvs/ports/graphics/zbar/Makefile,v
retrieving revision 1.24
diff -u -p -r1.24 Makefile
--- Makefile 17 Jun 2017 11:36:16 -0000 1.24
+++ Makefile 30 Sep 2017 02:52:00 -0000
@@ -2,7 +2,7 @@

COMMENT= ZBar barcode reader
DISTNAME= zbar-0.10
-REVISION= 16
+REVISION= 17

SHARED_LIBS= zbar 0.0 \
zbargtk 0.0
--- /dev/null Sat Sep 30 12:55:41 2017
+++ patches/patch-python_imagescanner_c Sat Sep 30 12:53:24 2017
@@ -0,0 +1,15 @@
+$OpenBSD$
+
+Index: python/imagescanner.c
+--- python/imagescanner.c.orig
++++ python/imagescanner.c
+@@ -67,7 +67,8 @@ imagescanner_get_results (zbarImageScanner *self,
+ }
+
+ static PyGetSetDef imagescanner_getset[] = {
+- { "results", (getter)imagescanner_get_results, },
++ { "results", (getter)imagescanner_get_results, NULL, NULL, NULL},
++ {NULL} /* Sentinel */
+ };
+
+ static PyObject*

Re: the whole greylisting, spam filtering thing

On 2017-09-29, Peter N. M. Hansteen <peter@bsdly.net> wrote:
> On 09/29/17 15:06, Markus Rosjat wrote:
>
>> my boss is getting on my nerves that greylisting is basically out of
>> date because of things like outlook.com and mails ending up delayed for
>> ever. So the next logical step would be to deploy a tool like rspamd or
>> spamassasin to examin mail content. These tools need to be trained and
>> if you have a small mailserver with less accounts this could take a
>> while I imagine.
>
> It won't surprise anyone here that I disagree with the assertion that
> greylisting is in any way outdated. Come back with that assertion when
> the SMTP RFC is amended to drop the retry requirement.

These senders do retry, but not always from the same source address.
Are you aware of any requirement in RFC5321 about source addresses
of retries? I didn't find any when I looked (or even a requirement that
retries are done over the same IP protocol version).

Greylisting still has its place, but with the way email operates today,
exemptions are unavoidable if you have a requirement to communicate
reliably with users of many email services. Especially with a strict
per-host greylisting implementation, where you don't get any benefit
from the common thing where senders often arrange to retry from within
the same v4 /24.

What you can do with rspamd is only greylist mail that looks spammy
but isn't scored highly enough to block outright. (Or you could think
of that as making an exemption for mail that doesn't look too spammy).
This works quite well in my experience. Unfortunately it's a lot more
complex to configure than spamd, though once you start adding
scripts and trying to work out who to whitelist, the spamd setup
doesn't seem quite so straightforward either.

Most of the spam that reaches my mailbox is forwarded by a (high
IP reputation) host that sits behind spamd. (I'm looking at you,
Chinese state-owned enterprise trying to order a batch of fox
fur from my @openbsd address! And others.) That's a lot trickier
to block on my side without false positives..

Re: the whole greylisting, spam filtering thing

On 2017-09-29, Larry Hynes <larry@larryhynes.com> wrote:
> Markus Rosjat <rosjat@ghweb.de> wrote:
>> my boss is getting on my nerves
>
> It may be mutual.
>
>> that greylisting is basically out of date because of things like
>> outlook.com and mails ending up delayed for ever. So the next logical
>> step would be to deploy a tool like rspamd or spamassasin to examin
>> mail content. These tools need to be trained and if you have a small
>> mailserver with less accounts this could take a while I imagine.
>
> Specifically in relation to rspamd: If you spend some time reading
> the documentation on the rspamd website you might find that:
>
> 1. the weight of rules which classify messages as 'ham' or 'spam'
> i.e. those rules which rely on the 'training' of messages, does not
> have to be, in the overall context, critical. rspamd deploys a
> boatload of 'tests', by default, and even more can be enabled, and
> each of those can be assigned a score. hamminess or spamminess is
> just one 'test'.

+1. rspamd doesn't do badly even with little/no training for spam/ham.

It does have problems with certain mail, for example it likes to have various
MIME headers, so you may need to make some exemptions for things like
daily/security mail output, or mail from people who don't use MIME MUAs.

> 2. That the rspamd website specifically links to 'pre-built' ham
> and spam databases which you are free to download and use.

Definitely you would need to read documentation if using tools like
rspamd or spamassassin.

OT: Re: Strange sed substitution removes text

howdee,

i am not quoting any text, because this note is OffTopic-ish...

i was looking at the comments from kshe regarding a full rewrite
of the sed-utility... in particular, that there were obscure corner
cases of tests that seemed to fail due to NULL or EOL or whatnot...

apparently, sed is a Turing-complete language - and hence,
given enough time/space/memory, will surely not give a single
TRUE/FALSE answer to some questions...

to be honest, i do not understand all of the details or theory,
that are involved in the statements i _just_ made - but...

since sed is a STREAM editor, and since sed-scripts are usually
finite-length, then maybe there should be some way to enforce
a limit (like was done for string-buffers) on the inputs...

again, this is all just my pie-in-the-sky OT-commentary...

sincerely, harold.

zbar, python module import core dumps

Hi,

this simple things make python core dump. Anything more for this
issue report I could provide?

Jiri

# python2.7 -c 'import zbar'
Segmentation fault (core dumped)

# pkg_info | egrep '^(python-2|zbar)'
python-2.7.14 interpreted object-oriented programming language
zbar-0.10p16 ZBar barcode reader

$ sysctl kern.version
kern.version=OpenBSD 6.2 (GENERIC.MP) #115: Wed Sep 27 10:45:53 MDT 2017
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

Thread 1 (process 469219):
#0 strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:124
No locals.
#1 0x0000089fb71af88e in PyString_FromString (str=0x8 <Address 0x8 out of bounds>) at Objects/stringobject.c:121
size = 9483253481056
op = (PyStringObject *) 0xfb33092845f4980d
#2 0x0000089fb71993c9 in PyDict_GetItemString (v=0x89ffdf555c8, key=0x8 <Address 0x8 out of bounds>) at Objects/dictobject.c:2505
kv = (PyObject *) 0x89ffdf555c8
rv = (PyObject *) 0x89fdc72ab51
#3 0x0000089fb71cb65d in add_getset (type=0x89fdc82e698, gsp=0x89fdc82e698) at Objects/typeobject.c:3784
descr = (PyObject *) 0x89ffdf47e60
dict = (PyObject *) 0x89ffdf555c8
#4 0x0000089fb71c7576 in PyType_Ready (type=0x89fdc82e698) at Objects/typeobject.c:4203
dict = (PyObject *) 0x89ffdf555c8
bases = (PyObject *) 0x89ffdf48d50
base = (PyTypeObject *) 0x89fb755d7c0
i = 1
n = 1
#5 0x0000089fdc620d9d in initzbar () at python/zbarmodule.c:126
ei = 2208
mod = (PyObject *) 0x89fac440000
dict = (PyObject *) 0x89fc86ee800
tp_dict = (PyObject *) 0x0
#6 0x0000089fb726a785 in _PyImport_LoadDynamicModule (name=0x89fac44b800 "zbar", pathname=0x89fc86ee800 "/usr/local/lib/python2.7/site-packages/zbar.so", fp=0x8a035d78760) at ./Python/importdl.c:53
m = (PyObject *) 0x0
lastdot = 0x0
shortname = 0x89fac44b800 "zbar"
packagecontext = 0x0
oldcontext = 0x0
p = 0x89fdc620c70 <initzbar>
#7 0x0000089fb72663a0 in load_module (name=0x89fac44b800 "zbar", fp=0x8a035d78760, pathname=0x89fc86ee800 "/usr/local/lib/python2.7/site-packages/zbar.so", type=3, loader=0x0) at Python/import.c:1937
modules = (PyObject *) 0x2
m = (PyObject *) 0x401
err = 0
#8 0x0000089fb7268081 in import_submodule (mod=0x89fb7557b58, subname=0x89fac44b800 "zbar", fullname=0x89fac44b800 "zbar") at Python/import.c:2725
buf = 0x89fc86ee800 "/usr/local/lib/python2.7/site-packages/zbar.so"
fp = (FILE *) 0x8a035d78760
path = (PyObject *) 0x0
loader = (PyObject *) 0x0
fdp = (struct filedescr *) 0x89f86855e80
modules = (PyObject *) 0x8a020ea9b40
m = (PyObject *) 0x0
#9 0x0000089fb72678bd in load_next (mod=0x89fb7557b58, altmod=0x89fb7557b58, p_name=0x7f7ffffc4990, buf=0x89fac44b800 "zbar", p_buflen=0x7f7ffffc4988) at Python/import.c:2539
name = 0x89ffdf53234 "zbar"
dot = 0x0
len = 4
p = 0x89fac44b800 "zbar"
result = (PyObject *) 0xffffffffabe4c180
#10 0x0000089fb72658e4 in import_module_level (name=0x0, globals=0x89f80530168, locals=0x89f80530168, fromlist=0x89fb7557b58, level=-1) at Python/import.c:2247
buf = 0x89fac44b800 "zbar"
buflen = 4
parent = (PyObject *) 0x89fb7557b58
head = (PyObject *) 0x89fb72940f0
next = (PyObject *) 0x7f7ffffc4970
tail = (PyObject *) 0x0
#11 0x0000089fb726572a in PyImport_ImportModuleLevel (name=0x89ffdf53234 "zbar", globals=0x89f80530168, locals=0x89f80530168, fromlist=0x89fb7557b58, level=-1) at Python/import.c:2312
result = (PyObject *) 0x0
#12 0x0000089fb722eb32 in builtin___import__ (self=0x0, args=0x89fba637cb0, kwds=0x0) at Python/bltinmodule.c:49
kwlist = 0x89fb756f210
name = 0x89ffdf53234 "zbar"
globals = (PyObject *) 0x89f80530168
locals = (PyObject *) 0x89f80530168
fromlist = (PyObject *) 0x89fb7557b58
level = -1
#13 0x0000089fb719f651 in PyCFunction_Call (func=0x8a020eadfc8, arg=0x89fba637cb0, kw=0x0) at Objects/methodobject.c:85
f = (PyCFunctionObject *) 0x8a020eadfc8
meth = 0x89fb722ea80 <builtin___import__>
self = (PyObject *) 0x0
size = 9483840078184
#14 0x0000089fb713ce07 in PyObject_Call (func=0x8a020eadfc8, arg=0x89fba637cb0, kw=0x0) at Objects/abstract.c:2547
result = (PyObject *) 0x7f7ffffc4b50
call = 0x89fb719f590 <PyCFunction_Call>
#15 0x0000089fb72448a0 in PyEval_CallObjectWithKeywords (func=0x8a020eadfc8, arg=0x89fba637cb0, kw=0x0) at Python/ceval.c:4226
result = (PyObject *) 0x89fba637cb0
#16 0x0000089fb7240cfb in PyEval_EvalFrameEx (f=0x8a020ea3c20, throwflag=0) at Python/ceval.c:2628
opcode_targets = 0x89fb756f320
exit = (PyObject *) 0x8a020e96e10
enter = (PyObject *) 0x8a020e96de0
stack_pointer = (PyObject **) 0x8a020ea3da0
next_instr = (unsigned char *) 0x89ffdf51a6d "Z"
opcode = 108
oparg = 0
why = WHY_NOT
err = 0
x = (PyObject *) 0x8a020eadfc8
v = (PyObject *) 0x8a020eadfc8
w = (PyObject *) 0x89fba637cb0
u = (PyObject *) 0x89fc31fbb68
t = (PyObject *) 0x8a020ea3c20
stream = (PyObject *) 0x0
fastlocals = (PyObject **) 0x8a020ea3d98
freevars = (PyObject **) 0x8a020ea3d98
retval = (PyObject *) 0x0
tstate = (PyThreadState *) 0x8a03b114d00
co = (PyCodeObject *) 0x89fba64fd30
instr_ub = -1
instr_lb = 0
instr_prev = -1
first_instr = (unsigned char *) 0x89ffdf51a64 "d"
names = (PyObject *) 0x89ffdf29350
consts = (PyObject *) 0x89ffdf2e7a0
#17 0x0000089fb7238b05 in PyEval_EvalCodeEx (co=0x89fba64fd30, globals=0x89f80530168, locals=0x89f80530168, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3589
f = (PyFrameObject *) 0x8a020ea3c20
retval = (PyObject *) 0x0
fastlocals = (PyObject **) 0x8a020ea3d98
freevars = (PyObject **) 0x8a020ea3d98
tstate = (PyThreadState *) 0x8a03b114d00
x = (PyObject *) 0x89fb7183ba5
u = (PyObject *) 0x7f7ffffc51d0
#18 0x0000089fb7237a15 in PyEval_EvalCode (co=0x89fba64fd30, globals=0x89f80530168, locals=0x89f80530168) at Python/ceval.c:669
No locals.
#19 0x0000089fb7279292 in run_mod (mod=0x89fbfe3b080, filename=0x89fb73fb773 "<string>", globals=0x89f80530168, locals=0x89f80530168, flags=0x7f7ffffc55b0, arena=0x89fb5fcc3c0) at Python/pythonrun.c:1376
co = (PyCodeObject *) 0x89fba64fd30
v = (PyObject *) 0x89fbfe3b080
#20 0x0000089fb727983e in PyRun_StringFlags (str=0x89febefba90 "import zbar\n", start=257, globals=0x89f80530168, locals=0x89f80530168, flags=0x7f7ffffc55b0) at Python/pythonrun.c:1339
ret = (PyObject *) 0x0
mod = 0x89fbfe3b080
arena = (PyArena *) 0x89fb5fcc3c0
#21 0x0000089fb7279731 in PyRun_SimpleStringFlags (command=0x89febefba90 "import zbar\n", flags=0x7f7ffffc55b0) at Python/pythonrun.c:974
m = (PyObject *) 0x89f8051cbe8
d = (PyObject *) 0x89f80530168
v = (PyObject *) 0x7f7ffffc55b0
#22 0x0000089fb7296bac in Py_Main (argc=3, argv=0x7f7ffffc5628) at Modules/main.c:589
c = 99
sts = 834981888
command = 0x89febefba90 "import zbar\n"
filename = 0x0
module = 0x0
fp = (FILE *) 0x8a035d68890
p = 0x0
unbuffered = 0
skipfirstline = 0
stdin_is_interactive = 1
help = 0
version = 0
saw_unbuffered_flag = 0
cf = {cf_flags = 0}
#23 0x0000089d68a00592 in main (argc=3, argv=0x7f7ffffc5628) at ./Modules/python.c:20
No locals.

security/encfs problem - fusefs: access error 35

Hello,

I use encfs to share files on dual-boot laptop with Linux. The
partition is ext2. I get quite often encfs mount issues, it
becomes not available. Any tips how could I provide more info?

# pkg_info | grep encfs
encfs-1.9.2 fuse-based cryptographic filesystem

$ sysctl kern.version
kern.version=OpenBSD 6.2 (GENERIC.MP) #115: Wed Sep 27 10:45:53 MDT 2017
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

# mount -v | grep fuse
fusefs on /home/jirib/share type fuse (rw, local, ctime=Fri Sep 29 20:07:02 2017)

# rsync -av /home/jirib/share/ /home/jirib/
sending incremental file list
rsync: change_dir "/home/jirib/share" failed: Resource temporarily unavailable (35)

sent 20 bytes received 12 bytes 3.05 bytes/sec
total size is 0 speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1178) [sender=3.1.2]

# dmesg | grep fuse | tail -n1
fusefs: access error 35

The encfs process is still running and it is shown in mount output:

# ps auxww | grep '[e]ncfs'
root 80178 0.0 0.0 1740 1880 ?? TXs 8:07PM 0:00.00 encfs /home/jirib/.share /home/jirib/share

j.

Re: ports broken on clang archs

On 2017/09/29 18:50, Jeremie Courreges-Anglas wrote:
> I moved texmacs, avidemux and ti-msp430-gcc to COMPILER=base-gcc.

Thanks.

> graphics/asymptote is affected too:
>
> NOT_FOR_ARCHS= ${CLANG_ARCHS} # hangs during build, while running
> # ../asy -dir ../base -config "" -render=0 -f pdf -noprc cube.asy
> # in WRKSRC/doc. run the abovef command with -vvv for more info.
> # this does not fail with ports clang, though.

Oh I think we could do "base-gcc ports-clang" here now that we have it...

Re: the whole greylisting, spam filtering thing

On 09/29/17 15:06, Markus Rosjat wrote:

> my boss is getting on my nerves that greylisting is basically out of
> date because of things like outlook.com and mails ending up delayed for
> ever. So the next logical step would be to deploy a tool like rspamd or
> spamassasin to examin mail content. These tools need to be trained and
> if you have a small mailserver with less accounts this could take a
> while I imagine.

It won't surprise anyone here that I disagree with the assertion that
greylisting is in any way outdated. Come back with that assertion when
the SMTP RFC is amended to drop the retry requirement.

But there are actors in the email market that do not particularly care
about standards compliance one way or the other, unfortunately (at least
for those of us below critical mass in terms of volume) is to use the
nospamd feature and not exposing those sending domains to greylisting at
all. My sedimentary nospamd file, built on discovering SPF info for
badly behaved domains, is available here
https://home.nuug.no/~peter/nospamd - I only started commenting entries
after a while, but it's a Works for me(tM) file. See man spamd for
examples of how to include that in your config. If you want to build and
maintain your own nospamd based on SPF records, Aaron Poffenberger's
spf_fetch is very well worth looking into (see
https://github.com/akpoff/spf_fetch)

> So my question is, is there some source that you could use to train
> these kind of tools (like a database that you could connect to for
> training conntent ) or is every one here, that uses these tools, lucky
> enough to have a shit load of users that do the training for your systems?

Yes, you need content filtering too. As others have said, you won't be
able to totally avoid the training effort based on local preferences,
but with working greylisting in front of the content filtering, those
servers will run a lot cooler than without.

I suppose my long rant from a few years back is still relevant -
https://bsdly.blogspot.no/2014/02/effective-spam-and-malware.html, for
the fun parts of doing greytrapping see
https://bsdly.blogspot.no/2013/05/keep-smiling-waste-spammers-time.html
and
https://bsdly.blogspot.no/2013/04/maintaining-publicly-available.html
and of course
https://bsdly.blogspot.no/2012/05/in-name-of-sane-email-setting-up-spamd.html
might still be of some use.

- P

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Re: ports broken on clang archs

On Thu, Sep 28 2017, Stuart Henderson <stu@spacehopper.org> wrote:
> On 2017/09/28 15:06, Jeremie Courreges-Anglas wrote:
>> That would disable said ports on eg amd64, like what we have now
>> (NOT_FOR_ARCHS).
>
> Yes. It's the way I've done it for some other things (e.g. festival) and
> I'd rather be consistent.

I moved texmacs, avidemux and ti-msp430-gcc to COMPILER=base-gcc.

graphics/asymptote is affected too:

NOT_FOR_ARCHS= ${CLANG_ARCHS} # hangs during build, while running
# ../asy -dir ../base -config "" -render=0 -f pdf -noprc cube.asy
# in WRKSRC/doc. run the abovef command with -vvv for more info.
# this does not fail with ports clang, though.

--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

Re: lastpass-cli segfaulting

Stuart Henderson:

> REVISION goes to 0 first. Add the upstream commit information to the
> patch.
>
> I think this should probably go in if there's still time.. What do
> you think naddy?

Obvious fix, ok

> Index: Makefile
> ===================================================================
> RCS file: /cvs/ports/security/lastpass-cli/Makefile,v
> retrieving revision 1.11
> diff -u -p -r1.11 Makefile
> --- Makefile 6 Jul 2017 11:09:50 -0000 1.11
> +++ Makefile 29 Sep 2017 14:03:03 -0000
> @@ -5,6 +5,7 @@ COMMENT = LastPass command line interfac
> GH_ACCOUNT = lastpass
> GH_PROJECT = lastpass-cli
> GH_TAGNAME = v1.2.1
> +REVISION = 0
> CATEGORIES = security
>
> MAINTAINER = Bjorn Ketelaars <bjorn.ketelaars@hydroxide.nl>
> Index: patches/patch-http_c
> ===================================================================
> RCS file: patches/patch-http_c
> diff -N patches/patch-http_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-http_c 29 Sep 2017 14:03:03 -0000
> @@ -0,0 +1,19 @@
> +$OpenBSD$
> +
> +From 68cfae08b22954fe952cfe590daa4b81a7f7124b Mon Sep 17 00:00:00 2001
> +Date: Fri, 29 Sep 2017 14:06:25 +0200
> +Subject: [PATCH] use-after-free bug in http.c
> +
> +Index: http.c
> +--- http.c.orig
> ++++ http.c
> +@@ -310,8 +310,8 @@ char *http_post_lastpass_v_noexit(const char *server,
> + ret = curl_easy_perform(curl);
> + unset_interrupt_detect();
> +
> +- curl_easy_cleanup(curl);
> + curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, http_code);
> ++ curl_easy_cleanup(curl);
> + *curl_ret = ret;
> +
> + if (ret != CURLE_OK) {

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Re: the whole greylisting, spam filtering thing

Hi Leo,

Am 29.09.2017 um 16:57 schrieb Leo Unglaub:
> Hey,
>
> On 09/29/17 15:06, Markus Rosjat wrote:
>> my boss is getting on my nerves that greylisting is basically out of
>> date because of things like outlook.com and mails ending up delayed
>> for ever. So the next logical step would be to deploy a tool like
>> rspamd or spamassasin to examin mail content. These tools need to be
>> trained and if you have a small mailserver with less accounts this
>> could take a while I imagine
>
> i assume that your boss is not an engineer and also not very familiar
> with how emails work. Greylisting it clearly NOT out of date at all.
> Greylisting simply makes use of stuff that is defined in the SMTP RFC.
> Every email server is allowed to temporary deny the delivery of an email
> and ask the sending server for another try.
>

well we use greylisting and I gave MS a free pass but sometimes it
doesn't seem to work anyway but that's ok for me.

> The problem in this case is clearly Microsoft who has no idea how email
> is supposed to work. You have two options here.
>

the customer will always complain no matter how often you explain the
real problem :)

> A: Simply don't care about Microsoft and just send customers to a
> website where you describe the problem and tell them to contact
> Microsoft in order to fix there stuff. This works very well, my Company
> hosts around 2,3 Million mailboxes and we use Greylisting and customers
> are okay with it.
>
> B: You exclude the outlook.com outgoing servers from greylisting.
> Microsoft provides a list of IP addresses that they use for delivery:
> https://mail.live.com/mail/ipspace.aspx
>
>> 65.54.190.0/26
>> 65.54.190.64/26
>> 65.54.190.128/26
>> 65.54.190.192/26
>> 65.55.116.0/26
>> 65.55.111.64/26
>> 65.55.116.64/26
>> 65.55.111.128/26
>> 65.55.34.0/26
>> 65.55.34.64/26
>> 65.55.34.128/26
>> 65.55.34.192/26
>> 65.55.90.0/26
>> 65.55.90.64/26
>> 65.55.90.128/26
>> 65.55.90.192/26
>> 65.54.51.64/26
>> 65.54.61.64/26
>> 207.46.66.0/28
>> 157.55.0.192/26
>> 157.55.1.128/26
>> 157.55.2.0/26
>> 157.55.2.64/26
>
> Greetings
> Leo
>

I also check the spf record files of MS and added them too so we will
see what's going to happen. I need to move to a more up to date setup so
I just check my options what's used these days and yes greylisting works
for me as long as no office 365 is involved but a lot of business
partners of our customers moving to 365 and the email solution so it
becomes a problem for me too. It's just fustrating to see a mail
greylisted from 40 different ips ...

regards

--
Markus Rosjat fon: +49 351 8107223 mail: rosjat@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220 fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
you print it, think about your responsibility and commitment to the
ENVIRONMENT

net-snmp client library use-after-free

Reported by a zabbix developer. I have asked for a test, but I think
this is likely to be correct, strdup is used in similar situations in
other net-snmp code. OK if testing is positive?

Index: Makefile
===================================================================
RCS file: /cvs/ports/net/net-snmp/Makefile,v
retrieving revision 1.94
diff -u -p -r1.94 Makefile
--- Makefile 12 Oct 2016 10:50:33 -0000 1.94
+++ Makefile 29 Sep 2017 14:55:23 -0000
@@ -4,7 +4,7 @@ COMMENT-main= extendable SNMP implementa
COMMENT-tkmib= graphical SNMP MIB browser

V= 5.7.3
-REVISION-main= 11
+REVISION-main= 12

DISTNAME= net-snmp-$V
MULTI_PACKAGES= -main -tkmib
Index: patches/patch-snmplib_snmp_api_c
===================================================================
RCS file: patches/patch-snmplib_snmp_api_c
diff -N patches/patch-snmplib_snmp_api_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-snmplib_snmp_api_c 29 Sep 2017 14:55:23 -0000
@@ -0,0 +1,32 @@
+$OpenBSD$
+
+https://support.zabbix.com/browse/ZBX-12726
+https://sourceforge.net/p/net-snmp/bugs/2803/
+
+Index: snmplib/snmp_api.c
+--- snmplib/snmp_api.c.orig
++++ snmplib/snmp_api.c
+@@ -1546,8 +1546,8 @@ _sess_open(netsnmp_session * in_session)
+
+ if (NULL != in_session->localname) {
+ clientaddr_save =
+- netsnmp_ds_get_string(NETSNMP_DS_LIBRARY_ID,
+- NETSNMP_DS_LIB_CLIENT_ADDR);
++ strdup(netsnmp_ds_get_string(NETSNMP_DS_LIBRARY_ID,
++ NETSNMP_DS_LIB_CLIENT_ADDR));
+ netsnmp_ds_set_string(NETSNMP_DS_LIBRARY_ID,
+ NETSNMP_DS_LIB_CLIENT_ADDR,
+ in_session->localname);
+@@ -1565,9 +1565,11 @@ _sess_open(netsnmp_session * in_session)
+ NULL);
+ }
+
+- if (NULL != clientaddr_save)
++ if (NULL != clientaddr_save) {
+ netsnmp_ds_set_string(NETSNMP_DS_LIBRARY_ID,
+ NETSNMP_DS_LIB_CLIENT_ADDR, clientaddr_save);
++ free(clientaddr_save);
++ }
+ }
+
+ if (transport == NULL) {

Re: the whole greylisting, spam filtering thing

Hey,

On 09/29/17 15:06, Markus Rosjat wrote:
> my boss is getting on my nerves that greylisting is basically out of
> date because of things like outlook.com and mails ending up delayed for
> ever. So the next logical step would be to deploy a tool like rspamd or
> spamassasin to examin mail content. These tools need to be trained and
> if you have a small mailserver with less accounts this could take a
> while I imagine

i assume that your boss is not an engineer and also not very familiar
with how emails work. Greylisting it clearly NOT out of date at all.
Greylisting simply makes use of stuff that is defined in the SMTP RFC.
Every email server is allowed to temporary deny the delivery of an email
and ask the sending server for another try.

The problem in this case is clearly Microsoft who has no idea how email
is supposed to work. You have two options here.

A: Simply don't care about Microsoft and just send customers to a
website where you describe the problem and tell them to contact
Microsoft in order to fix there stuff. This works very well, my Company
hosts around 2,3 Million mailboxes and we use Greylisting and customers
are okay with it.

B: You exclude the outlook.com outgoing servers from greylisting.
Microsoft provides a list of IP addresses that they use for delivery:
https://mail.live.com/mail/ipspace.aspx

> 65.54.190.0/26
> 65.54.190.64/26
> 65.54.190.128/26
> 65.54.190.192/26
> 65.55.116.0/26
> 65.55.111.64/26
> 65.55.116.64/26
> 65.55.111.128/26
> 65.55.34.0/26
> 65.55.34.64/26
> 65.55.34.128/26
> 65.55.34.192/26
> 65.55.90.0/26
> 65.55.90.64/26
> 65.55.90.128/26
> 65.55.90.192/26
> 65.54.51.64/26
> 65.54.61.64/26
> 207.46.66.0/28
> 157.55.0.192/26
> 157.55.1.128/26
> 157.55.2.0/26
> 157.55.2.64/26

Greetings
Leo

Re: the whole greylisting, spam filtering thing

Hi,

Am 29.09.2017 um 15:39 schrieb Larry Hynes:
> Markus Rosjat <rosjat@ghweb.de> wrote:
>> my boss is getting on my nerves
>
> It may be mutual.
>

of course but well :)

>> that greylisting is basically out of date because of things like
>> outlook.com and mails ending up delayed for ever. So the next logical
>> step would be to deploy a tool like rspamd or spamassasin to examin
>> mail content. These tools need to be trained and if you have a small
>> mailserver with less accounts this could take a while I imagine.
>
> Specifically in relation to rspamd: If you spend some time reading
> the documentation on the rspamd website you might find that:
>
> 1. the weight of rules which classify messages as 'ham' or 'spam'
> i.e. those rules which rely on the 'training' of messages, does not
> have to be, in the overall context, critical. rspamd deploys a
> boatload of 'tests', by default, and even more can be enabled, and
> each of those can be assigned a score. hamminess or spamminess is
> just one 'test'.
>
> 2. That the rspamd website specifically links to 'pre-built' ham
> and spam databases which you are free to download and use.
>

I'll check this out !

Thank you for the hint !!!

regards

--
Markus Rosjat fon: +49 351 8107223 mail: rosjat@ghweb.de

G+H Webservice GbR Gorzolla, Herrmann
Königsbrücker Str. 70, 01099 Dresden

http://www.ghweb.de
fon: +49 351 8107220 fax: +49 351 8107227

Bitte prüfen Sie, ob diese Mail wirklich ausgedruckt werden muss! Before
you print it, think about your responsibility and commitment to the
ENVIRONMENT

Re: lastpass-cli segfaulting

On 2017/09/29 16:00, Björn Ketelaars wrote:
> Raf Czlonka contacted me offlist concerning lastpass-cli segfaulting.
> I assisted him in fixing the bug. A patch has been sent upstream [0].
>
> I do not know when a new version will be released, and I prefer having a well
> behaving lastpass-cli in ports. My proposal would be to update the port.
>
> OK?

REVISION goes to 0 first. Add the upstream commit information to the
patch.

I think this should probably go in if there's still time.. What do
you think naddy?

Index: Makefile
===================================================================
RCS file: /cvs/ports/security/lastpass-cli/Makefile,v
retrieving revision 1.11
diff -u -p -r1.11 Makefile
--- Makefile 6 Jul 2017 11:09:50 -0000 1.11
+++ Makefile 29 Sep 2017 14:03:03 -0000
@@ -5,6 +5,7 @@ COMMENT = LastPass command line interfac
GH_ACCOUNT = lastpass
GH_PROJECT = lastpass-cli
GH_TAGNAME = v1.2.1
+REVISION = 0
CATEGORIES = security

MAINTAINER = Bjorn Ketelaars <bjorn.ketelaars@hydroxide.nl>
Index: patches/patch-http_c
===================================================================
RCS file: patches/patch-http_c
diff -N patches/patch-http_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-http_c 29 Sep 2017 14:03:03 -0000
@@ -0,0 +1,19 @@
+$OpenBSD$
+
+From 68cfae08b22954fe952cfe590daa4b81a7f7124b Mon Sep 17 00:00:00 2001
+Date: Fri, 29 Sep 2017 14:06:25 +0200
+Subject: [PATCH] use-after-free bug in http.c
+
+Index: http.c
+--- http.c.orig
++++ http.c
+@@ -310,8 +310,8 @@ char *http_post_lastpass_v_noexit(const char *server,
+ ret = curl_easy_perform(curl);
+ unset_interrupt_detect();
+
+- curl_easy_cleanup(curl);
+ curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, http_code);
++ curl_easy_cleanup(curl);
+ *curl_ret = ret;
+
+ if (ret != CURLE_OK) {

> [0]
> https://github.com/lastpass/lastpass-cli/commit/68cfae08b22954fe952cfe590daa4b81a7f7124b
>
> --
> Björn Ketelaars
> GPG key: 0x4F0E5F21
>
>
> diff --git security/lastpass-cli/Makefile security/lastpass-cli/Makefile
> index ed60b8f5df7..ea74da15e3b 100644
> --- security/lastpass-cli/Makefile
> +++ security/lastpass-cli/Makefile
> @@ -5,6 +5,7 @@ COMMENT = LastPass command line interface tool
> GH_ACCOUNT = lastpass
> GH_PROJECT = lastpass-cli
> GH_TAGNAME = v1.2.1
> +REVISION = 1
> CATEGORIES = security
>
> MAINTAINER = Bjorn Ketelaars <bjorn.ketelaars@hydroxide.nl>
> diff --git security/lastpass-cli/patches/patch-http_c security/lastpass-cli/patches/patch-http_c
> new file mode 100644
> index 00000000000..895604edd39
> --- /dev/null
> +++ security/lastpass-cli/patches/patch-http_c
> @@ -0,0 +1,15 @@
> +$OpenBSD$
> +
> +Index: http.c
> +--- http.c.orig
> ++++ http.c
> +@@ -310,8 +310,8 @@ char *http_post_lastpass_v_noexit(const char *server,
> + ret = curl_easy_perform(curl);
> + unset_interrupt_detect();
> +
> +- curl_easy_cleanup(curl);
> + curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, http_code);
> ++ curl_easy_cleanup(curl);
> + *curl_ret = ret;
> +
> + if (ret != CURLE_OK) {
>