Re: Bridged vether interfaces can't talk to each other (multiple routing tables)
On 04/21/17 20:49, Anders Andersson wrote: === BACKGROUND === I'm trying to set up an OpenBSD 6.1 server having two externally visible IP numbers through one physical network port, each IP mapping to a unique MAC address[1]. I have it mostly working, but my interfaces can't talk to each other. All traffic should use the primary IP, and most services should listen on that. The secondary IP should only be used on-demand for one or two services. Thinking that separate routing tables can solve this, I have configured my network like this[2][3]: # cat hostname.em2 up # cat hostname.vether0 lladdr 00:00:00:00:00:02 # cat hostname.vether1 lladdr 00:00:00:00:00:03 rdomain 1 # cat hostname.bridge0 add em2 add vether0 add vether1 up !dhclient vether0 !dhclient vether1 # cat sysctl.conf net.inet.ip.forwarding=1 Leading to something like this[4]: (full post in monospace: http://paste.debian.net/928811 ) ..-. 10.0.0.1 .-,( ),-. | bridge0| em2 |dhcp server .-( )-. || (no ip) |---> gateway --->(internet) |'-' __ '-( ).-' | |[_...__...°] '-.( ).-' .---. .---. | vether0 | | vether1 | | rdomain 0 | | rdomain 1 | | dhcp| | dhcp| | 10.0.0.2 | | 10.0.0.3 | '---'--'---' Love the ascii art! Everything else should be the default, this is on a clean 6.1 install. This configuration works great, vether0 and vether1 both gets an IP number from my DHCP server, all traffic goes out on vether0 by default, but I can select vether1 manually: # traceroute -nvq1 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets 1 10.0.0.1 48 bytes to 10.0.0.2 0.994 ms # route -T1 exec traceroute -nvq1 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets 1 10.0.0.1 48 bytes to 10.0.0.3 0.984 ms I can also reach each IP from outside the box. They are going in on em2, through the bridge, and in to vether0 or vether1 respectively. === PROBLEM === Now to my problem: I have no connection between vether0<->vether1. # traceroute -nvq1 10.0.0.3 traceroute to 10.0.0.3 (10.0.0.3), 64 hops max, 40 byte... 1 * 2 * ^C If I listen with tcpdump on the bridge, I see lots of unanswered arp who-has: # tcpdump -nti bridge0 tcpdump: listening on bridge0, link-type EN10MB arp who-has 10.0.0.3 tell 10.0.0.2 arp who-has 10.0.0.3 tell 10.0.0.2 ^C Never done this, but maybe you need an arp proxy. Not sure which $iface to put it on, but something like: # arp -s 10.0.0.2 00:00:00:00:00:02 pub may or may not help depending on if my understanding of what I read in the manual actually does what I think it will. These packets even go out on em2 to my LAN, but no one ever answers. The same thing happens in reverse. I have experimented with these bridge settings: 'blocknonip' - adding or removing on members makes no difference 'discover' - should be the default, adding makes no difference 'learn' - should be the default, adding makes no difference === EXPECTATIONS === I expected that someone should answer those arp who-is requests, either vether1 directly, or the bridge0 who should know which interfaces it has. Is there something I must configure to make this work, or is my plan flawed from the start? === INFORMATION === Various information that could help answer my question (trimmed whitespace and boilerplate): # route -n show -inet Destination Gateway Flags Refs Use Mtu Prio Iface default 10.0.0.1 UGS 0 0 -8 vether0 224/4 127.0.0.1 URS 0 0 327688 lo0 10.0.0/24 10.0.0.2 UCn 1 0 -4 vether0 10.0.0.1 link#6UHLch1 1 -3 vether0 10.0.0.2 00:00:00:00:00:02 UHLl 0 0 -1 vether0 10.0.0.25510.0.0.2 UHb 0 0 -1 vether0 127/8 127.0.0.1 UGRS 0 0 327688 lo0 127.0.0.1 127.0.0.1 UHhl 1 2 327681 lo0 # route -T1 -n show -inet Destination Gateway Flags Refs Use Mtu Prio Iface default 10.0.0.1 UGS 0 32 -8 vether1 10.0.0/24 10.0.0.3 UCn 1 4 -4 vether1 10.0.0.1 00:00:00:00:00:01 UHLch1 3 -3 vether1 10.0.0.3 00:00:00:00:00:03 UHLl 0 0 -1 vether1 10.0.0.25510.0.0.3 UHb 0 0 -1 vether1 # for if in bridge0 em2 vether{0,1}; do ifconfig $if; done bridge0: flags=41description: Bridge for external virtual NICs index 9 llprio 3 groups: bridge priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp designated: id
Bridged vether interfaces can't talk to each other (multiple routing tables)
=== BACKGROUND === I'm trying to set up an OpenBSD 6.1 server having two externally visible IP numbers through one physical network port, each IP mapping to a unique MAC address[1]. I have it mostly working, but my interfaces can't talk to each other. All traffic should use the primary IP, and most services should listen on that. The secondary IP should only be used on-demand for one or two services. Thinking that separate routing tables can solve this, I have configured my network like this[2][3]: # cat hostname.em2 up # cat hostname.vether0 lladdr 00:00:00:00:00:02 # cat hostname.vether1 lladdr 00:00:00:00:00:03 rdomain 1 # cat hostname.bridge0 add em2 add vether0 add vether1 up !dhclient vether0 !dhclient vether1 # cat sysctl.conf net.inet.ip.forwarding=1 Leading to something like this[4]: (full post in monospace: http://paste.debian.net/928811 ) ..-. 10.0.0.1 .-,( ),-. | bridge0| em2 |dhcp server .-( )-. || (no ip) |---> gateway --->(internet) |'-' __ '-( ).-' | |[_...__...°] '-.( ).-' .---. .---. | vether0 | | vether1 | | rdomain 0 | | rdomain 1 | | dhcp| | dhcp| | 10.0.0.2 | | 10.0.0.3 | '---'--'---' Everything else should be the default, this is on a clean 6.1 install. This configuration works great, vether0 and vether1 both gets an IP number from my DHCP server, all traffic goes out on vether0 by default, but I can select vether1 manually: # traceroute -nvq1 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets 1 10.0.0.1 48 bytes to 10.0.0.2 0.994 ms # route -T1 exec traceroute -nvq1 10.0.0.1 traceroute to 10.0.0.1 (10.0.0.1), 64 hops max, 40 byte packets 1 10.0.0.1 48 bytes to 10.0.0.3 0.984 ms I can also reach each IP from outside the box. They are going in on em2, through the bridge, and in to vether0 or vether1 respectively. === PROBLEM === Now to my problem: I have no connection between vether0<->vether1. # traceroute -nvq1 10.0.0.3 traceroute to 10.0.0.3 (10.0.0.3), 64 hops max, 40 byte... 1 * 2 * ^C If I listen with tcpdump on the bridge, I see lots of unanswered arp who-has: # tcpdump -nti bridge0 tcpdump: listening on bridge0, link-type EN10MB arp who-has 10.0.0.3 tell 10.0.0.2 arp who-has 10.0.0.3 tell 10.0.0.2 ^C These packets even go out on em2 to my LAN, but no one ever answers. The same thing happens in reverse. I have experimented with these bridge settings: 'blocknonip' - adding or removing on members makes no difference 'discover' - should be the default, adding makes no difference 'learn' - should be the default, adding makes no difference === EXPECTATIONS === I expected that someone should answer those arp who-is requests, either vether1 directly, or the bridge0 who should know which interfaces it has. Is there something I must configure to make this work, or is my plan flawed from the start? === INFORMATION === Various information that could help answer my question (trimmed whitespace and boilerplate): # route -n show -inet Destination Gateway Flags Refs Use Mtu Prio Iface default 10.0.0.1 UGS 0 0 -8 vether0 224/4 127.0.0.1 URS 0 0 327688 lo0 10.0.0/24 10.0.0.2 UCn 1 0 -4 vether0 10.0.0.1 link#6UHLch1 1 -3 vether0 10.0.0.2 00:00:00:00:00:02 UHLl 0 0 -1 vether0 10.0.0.25510.0.0.2 UHb 0 0 -1 vether0 127/8 127.0.0.1 UGRS 0 0 327688 lo0 127.0.0.1 127.0.0.1 UHhl 1 2 327681 lo0 # route -T1 -n show -inet Destination Gateway Flags Refs Use Mtu Prio Iface default 10.0.0.1 UGS 0 32 -8 vether1 10.0.0/24 10.0.0.3 UCn 1 4 -4 vether1 10.0.0.1 00:00:00:00:00:01 UHLch1 3 -3 vether1 10.0.0.3 00:00:00:00:00:03 UHLl 0 0 -1 vether1 10.0.0.25510.0.0.3 UHb 0 0 -1 vether1 # for if in bridge0 em2 vether{0,1}; do ifconfig $if; done bridge0: flags=41description: Bridge for external virtual NICs index 9 llprio 3 groups: bridge priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp designated: id 00:00:00:00:00:00 priority 0 em2 flags=3 port 3 ifpriority 0 ifcost 0 vether0 flags=3 port 6 ifpriority 0 ifcost 0 vether1 flags=3 port 7 ifpriority 0 ifcost 0 Addresses (max cache: 100, timeout: 240): 00:00:00:00:00:01 em2 1 flags=0<> em2:
Re: spamd and outlook.com
On 2017-04-21, Kurt H Maierwrote: > What I don't do it set an outgoing voicemail greeting informing > correspondents that my time is more valuable than theirs, and if they > want to contact me I have a list of hoops through which they must jump. > > That would make me an asshole. Heh. I do actually have asterisk play a "press to talk to someone" message to callers who withhold caller id.
Re: spamd and outlook.com
On Fri, Apr 21, 2017 at 10:40:42PM +0100, Kevin Chadwick wrote: > On Fri, 21 Apr 2017 09:21:48 -0700 > Kurt H Maierwrote: > > > Greylisting is a hack, an abuse of a side-effect. Most such > > approaches have deleterious side effects. This particular side > > effect is why I don't like greylisting in general, even though it's > > fairly effective. > > Do you answer your phone before looking at the number/caller? In fact, there are some numbers I will not respond to (and these do not cause my phone to ring) and the rest I just answer. Just like having a blacklist I don't accept SMTP connections from at all, and the rest get processed normally. What I don't do it set an outgoing voicemail greeting informing correspondents that my time is more valuable than theirs, and if they want to contact me I have a list of hoops through which they must jump. That would make me an asshole. > It is not a hack at all. It is. SMTP is mandated to retry as a reliability factor, in a world with bad network connections and unreliable software. It is not mandated to retry so people can play cute games with the sending unit. I personally have no burning desire to see greylisting expunged from the internet, but I also have no sympathy for people who think it's a real solution to anything. If it works for someone, good for them, but I will never be even a little surprised when it becomes a pain in someone's ass. khm
Re: spamd and outlook.com
On Fri, 21 Apr 2017 09:21:48 -0700 Kurt H Maierwrote: > Greylisting is a hack, an abuse of a side-effect. Most such > approaches have deleterious side effects. This particular side > effect is why I don't like greylisting in general, even though it's > fairly effective. Do you answer your phone before looking at the number/caller? It is not a hack at all. The only problem that keeps coming up is large MTAs that I have concluded, wish to discourage it as it increases their costs (I am sure they know what IPS may send mail and could publish SPF records much more usefully (they probably block windows boxes etc. from connecting to port 25 to avoid being blacklisted)). It would be nice if SPAMD/SMTPD/GREYSCANNER/SCRIPTS could be integrated/improved to the point that checks could be completed whilst the connection is still stuttering and then the connection speed back up once completed. Unfortunately, it is often dumb spam bots that hang around and the likes of hotmail that disconnect early. So I guess any efforts there *may* be a waste of time anyway.
Re: iked/IKEv2 issue with 6.1
Thanks again. The connections are all working. On 4/20/17 8:54 PM, Igor V. Gubenko wrote: > Thank you, the patch appears to work. I haven't fully tested > connecting/establishing connections, so I'll send another update. > > Prior to the patch, iked also complained about lack of public keys for > PSK connections 1 and 2 (in /etc/iked/pubkeys/fqdn/) > It doesn't mind them being absent anymore though. > > - Igor > > On 4/20/17 5:44 PM, Reyk Floeter wrote: >> --- sbin/iked/parse.y28 Mar 2017 16:56:39 - 1.64 >> +++ sbin/iked/parse.y20 Apr 2017 21:40:14 - >> @@ -1807,7 +1807,7 @@ set_policy(char *idstr, int type, struct >> { >> char keyfile[PATH_MAX]; >> const char *prefix = NULL; >> -EVP_PKEY*key; >> +EVP_PKEY*key = NULL; >> >> switch (type) { >> case IKEV2_ID_IPV4: >> @@ -1822,6 +1822,9 @@ set_policy(char *idstr, int type, struct >> case IKEV2_ID_UFQDN: >> prefix = "ufqdn"; >> break; >> +case IKEV2_ID_ASN1_DN: >> +/* public key authentication is not supported with ASN.1 IDs */ >> +goto done; >> default: >> /* Unspecified ID or public key not supported for this type */ >> log_debug("%s: unknown type = %d", __func__, type); >> @@ -1841,6 +1844,7 @@ set_policy(char *idstr, int type, struct >> keyfile); >> } >> >> + done: >> if (set_policy_auth_method(keyfile, key, pol) < 0) { >> EVP_PKEY_free(key); >> log_warnx("%s: failed to set policy auth method for %s",
Re: OpenBSD 6.1, spamd strange behavior
On 04/21/17 10:44, Alex Shupikov wrote: > spamd is working in the greylisting mode with "-v -G 2:4:864" options. > For every trying of the delivery mail a remote host become TRAPPED for 24 > hours, and I don't understand why. is there a very restrictive spamd.alloweddomains you're not showing us? (see the GREYTRAPPING section of the man page) -- 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: WARNING: symbol(icudt58_dat) size mismatch, relink your program
On 2017-04-21 19:09, bian wrote: I did not try slappasswd but the message is triggered from other places as well. From my ~/.xsession-errors (using 6.1 , xfce4): firefox-esr:/usr/local/lib/libicuuc.so.12.0: /usr/local/lib/libicudata.so.12.0 : WARNING: symbol(icudt58_dat) size mismatch, relink your program soffice.bin:/usr/local/lib/libicuuc.so.12.0: /usr/local/lib/libicudata.so.12.0 : WARNING: symbol(icudt58_dat) size mismatch, relink your program vlc:/usr/local/lib/libicuuc.so.12.0: /usr/local/lib/libicudata.so.12.0 : WARNING: symbol(icudt58_dat) size mismatch, relink your program Best regards /Birger On 2017-04-20 21:40, Predrag Punosevac wrote: Sorry for the noise. Did anybody try to use slappasswd after upgrading from 6.0 to 6.1 (amd64). I get slappasswd:/usr/local/lib/libicuuc.so.12.0: /usr/local/lib/libicudata.so.12.0 : WARNING: symbol(icudt58_dat) size mismatch, relink your program I tried reinstalling openldap-server-2.4.44p3 which I only keep around. I actually use ldapd from the base. Best, Predrag
Re: spamd and outlook.com
Stuart Henderson wrote: > On 2017-04-21, Craig Skinnerwrote: > > Email is not instant messaging. > > > > Customers need educated to that fact. > > How do you educate them to that when they send to their gmail account > and it shows up on their phone within seconds? We, at school, used the pen as blowgun.
understanding ldapd log error messages
Hi misc, ldapd on one of my two ldap servers stop working overnight # uname -a OpenBSD atlas.int.autonlab.org 6.1 GENERIC.MP#20 amd64 I manually restarted it and it appears to work OK. I started digging little bit through the log files and I see the following in my /var/log/message file before and after the upgrade. Can somebody help me understand what I see and point me to some kind reading? Is my database corrupted for some reason? The LDAP server overall has being working really well for the past 3.5 years with Red Hat, FreeBSD, and OpenBSD clients. I have being upgrading this server since the last database format change (I think OpenBSD 5.3 or 5.4). Best, Predrag Apr 17 04:03:39 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 17 04:03:39 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 17 04:03:44 atlas ldapd[83666]: error 0x24 on connection 17 Apr 17 04:04:20 atlas last message repeated 3 times Apr 17 04:04:31 atlas ldapd[83666]: error 0x24 on connection 13 Apr 17 04:05:02 atlas last message repeated 3 times Apr 17 04:05:12 atlas ldapd[83666]: error 0x24 on connection 13 Apr 17 04:05:24 atlas ldapd[83666]: error 0x24 on connection 18 Apr 17 04:05:57 atlas last message repeated 3 times Apr 17 04:08:08 atlas last message repeated 12 times Apr 17 04:08:41 atlas last message repeated 3 times Apr 17 04:08:53 atlas ldapd[83666]: error 0x24 on connection 20 Apr 17 04:09:05 atlas ldapd[83666]: error 0x24 on connection 22 Apr 17 04:09:36 atlas last message repeated 3 times Apr 17 04:09:57 atlas last message repeated 2 times Apr 17 04:10:07 atlas ldapd[83666]: error 0x24 on connection 38 Apr 17 04:10:18 atlas ldapd[83666]: error 0x24 on connection 25 Apr 17 04:10:28 atlas ldapd[83666]: error 0x24 on connection 25 Apr 17 04:10:40 atlas ldapd[83666]: error 0x24 on connection 38 Apr 17 04:10:52 atlas ldapd[83666]: error 0x24 on connection 40 Apr 17 04:11:23 atlas last message repeated 3 times Apr 17 04:11:34 atlas ldapd[83666]: error 0x24 on connection 26 Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 17 04:11:39 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 17 04:11:44 atlas ldapd[83666]: error 0x24 on connection 40 Apr 17 04:11:56 atlas ldapd[83666]: error 0x24 on connection 41 Apr 17 04:12:29 atlas last message repeated 3 times Apr 17 04:12:50 atlas last message repeated 2 times Apr 17 04:13:00 atlas ldapd[83666]: error 0x24 on connection 28 Apr 17 04:13:36 atlas last message repeated 3 times Apr 17 04:14:09 atlas last message repeated 3 times Apr 17 04:14:21 atlas ldapd[83666]: error 0x24 on connection 14 Apr 17 04:14:44 atlas last message repeated 2 times Apr 17 04:14:54 atlas ldapd[83666]: error 0x24 on connection 15 Apr 17 04:15:25 atlas last message repeated 3 times Apr 17 04:16:10 atlas last message repeated 4 times Apr 17 04:16:20 atlas ldapd[83666]: error 0x24 on connection 29 Apr 17 04:16:53 atlas last message repeated 3 times Apr 17 04:17:05 atlas ldapd[83666]: error 0x24 on connection 29 Apr 17 04:17:17 atlas ldapd[83666]: error 0x24 on connection 32 Apr 17 04:17:50 atlas last message repeated 3 times Apr 17 04:18:23 atlas last message repeated 3 times Apr 17 04:18:33 atlas ldapd[83666]: error 0x24 on connection 16 Apr 17 04:19:06 atlas last message repeated 3 times Apr 17 04:19:18 atlas ldapd[83666]: error 0x24 on connection 33 Apr 17 04:19:51 atlas last message repeated 3 times Apr 17 04:20:01 atlas ldapd[83666]: error 0x24 on connection 33 Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 17 04:20:11 atlas ldapd[83666]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 17 04:20:12 atlas ldapd[83666]: error 0x24 on connection 34 Apr 17 04:20:22 atlas ldapd[83666]: error 0x24 on connection 13 Apr 17 04:20:33 atlas ldapd[83666]: error 0x24 on connection 34 and this is from today Apr 21 12:04:41 atlas ldapd[78718]: error 0x24 on connection 19 Apr 21 12:04:52 atlas ldapd[78718]: error 0x24 on connection 19 Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 21 12:04:59 atlas ldapd[78718]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,] doesn't exist! Apr 21 12:05:00 atlas ldapd[78718]: indexed key [uid=seohyuns,ou=users,] doesn't exist! Apr 21 12:05:01 atlas ldapd[78718]: indexed key [uid=dwang,ou=users,] doesn't exist! Apr 21 12:05:01 atlas ldapd[78718]: indexed key [uid=emcfowla,ou=users,] doesn't exist!
Re: spamd and outlook.com
On Fri, Apr 21, 2017 at 04:02:20PM +, Stuart Henderson wrote: > On 2017-04-21, Craig Skinnerwrote: > > Hi Markus, > > > > On Fri, 21 Apr 2017 11:25:14 +0200 Markus Rosjat wrote: > >> so if you have spamd in place in greylisting mode and you have > >> customers that work with people who use Office365 as a service you > >> will get calls that emails are delayed for a freaking long time > > > > Email is not instant messaging. > > > > Customers need educated to that fact. > > How do you educate them to that when they send to their gmail account > and it shows up on their phone within seconds? > > Sometimes there are delays but there's no reason for that to be the norm. > There's no reason email can't be instant messaging. Postmasters have spent decades training users that email just sucks and is necessarily unreliable. All they did was corral users toward services where they don't have to hear the administrators whining about how hard that job is. Greylisting is a hack, an abuse of a side-effect. Most such approaches have deleterious side effects. This particular side effect is why I don't like greylisting in general, even though it's fairly effective. khm
Re: spamd and outlook.com
On Fri, 21 Apr 2017 16:02:20 + (UTC) Stuart Hendersonwrote: > > > > Email is not instant messaging. > > > > Customers need educated to that fact. > > How do you educate them to that when they send to their gmail account > and it shows up on their phone within seconds? > > Sometimes there are delays but there's no reason for that to be the > norm. Unfortunately, I disagree. Instant messaging has a friends/block facility, email is for strangers too. The delay doesn't need to be long however but your chances of receiving spam are far better with the checks before accepting. Hotmail users skip through the spam and pick valid messages out of their spam folder. A colleague of mine commented on having a spam message as if it was rare the other day.
Re: Is randomizing UID/GUID would make sense?
On Fri, 21 Apr 2017 22:39:39 +1000wrote: > Thanks for the start points, Christian and Philip. > I would have never thought about those use cases. > I'll definitely look into this further. I rewrote some code for key generation for particular memory handling/protection reasons and it certainly provides some extra confidence to yourself and/or other if you find your implementation and four others all produce the same 1 outputs with the same repeatable but random looking inputs. Usually specific and well chosen test vectors are available, but not always. I did have a cry/laugh at the function name of the deterministic "random" generator in mbedtls though and reminding me of the OpenBSD commentry on them. Unfortunately I forget the details of what was particularly alarming/funny though.
Re: spamd and outlook.com
Like I said I had one case where I had the same message send from 20 different outlook.com servers that's just stupid Regards Markus Ursprüngliche Nachricht Von: Edgar PettijohnDatum: 21.04.17 15:20 (GMT+01:00) An: misc@openbsd.org Betreff: Re: spamd and outlook.com On 04/21/17 07:12, Reyk Floeter wrote: > On Fri, Apr 21, 2017 at 01:52:05PM +0200, Boudewijn Dijkstra wrote: >> Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter : >>> On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote: On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote: >>> I use the attached script to fetch the SPF entries recursively, in a >>> plain text format that can be fed into pfctl. >> Have you tried mx3a.certifiedfactory.info ? ;) >> > great > > I think you got something wrong: > > I don't use this simple script automatically or for "untrusted > domains", I just use it _manually_ and for _well-known_ offenders like > outlook.com that break greylisting. SPF is not a security solution, > but it is a band-aid that helps to handle these stupid cloud-based MTAs. > > The script below fixes it - or akpoff's slightly more complicated (and > probably more correct) version. > > Reyk > > ---snip--- > #!/usr/bin/perl > > # Copyright (c) 2016, 2017 Reyk Floeter > # > # Permission to use, copy, modify, and distribute this software for any > # purpose with or without fee is hereby granted, provided that the above > # copyright notice and this permission notice appear in all copies. > # > # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > > $domain = shift @ARGV or die "usage: $0 domain"; > %seen = {}; > > sub parsespf > { > my $domain = shift; > my @foo = `nslookup -q=TXT $domain`; > my @results = (); > > foreach (@foo) { > next if not /$domain\ttext/; > next if not s/$domain\ttext = "v=spf1([^"]+)"/$1/; > > @results = split /\s+/; > foreach (@results) { > next if /.all/; > if (s/^ip[46]://) { > print "$_\n"; > } elsif (s/^(redirect|include)[:=]//) { > print "\n#$_\n"; > if (!$seen{$_}) { > $seen{$_} = true; > parsespf($_); > } > } > } > } > } > > parsespf($domain); > > 0; I'm glad I'm not the only one with this problem. I started off just adding individual ip's to my nospamd as needed, but they deliver mail so stupidly. One message may get sent from in my experience 4 different ip's so they get trapped each time and I'm guessing they eventually give up. Luckily https://home.nuug.no/~peter/nospamd came across my screen one day. It seems to have cured my problem. Thanks Peter!
Re: spamd and outlook.com
On 2017-04-21, Craig Skinnerwrote: > Hi Markus, > > On Fri, 21 Apr 2017 11:25:14 +0200 Markus Rosjat wrote: >> so if you have spamd in place in greylisting mode and you have >> customers that work with people who use Office365 as a service you >> will get calls that emails are delayed for a freaking long time > > Email is not instant messaging. > > Customers need educated to that fact. How do you educate them to that when they send to their gmail account and it shows up on their phone within seconds? Sometimes there are delays but there's no reason for that to be the norm.
Re: spamd and outlook.com
On 2017-04-21, Markus Rosjatwrote: > so if you have spamd in place in greylisting mode and you have customers > that work with people who use Office365 as a service you will get calls > that emails are delayed for a freaking long time and if you check the ip > range that outlook.com could send from you get scared. > > So what are the strategies out there to handle this kind of situation? I stopped simple spamd-style greylisting years ago, I was spending far more time waiting for verification mails and figuring out the cause for mail delays than it saved me in deleting spam (especially considering a lot still gets past greylisting). I switched to using postfix's "after-accept" checks (which drop the first attempt from a new source, blacklisting if they make certain SMTP errors, but don't have a timeout period - allows delivery immediately on reconnect). And these days I exempt hosts on dnswl.org from this. I now also do greylisting via rspamd for high-ish scoring mail, if it suspects it's likely to be spam but isn't quite sure, it greylists for a while; often the sender is added to enough RBL or RHSBLs by the time it retries and is then detected as spam right away. There are still some delays from legit-but-spammy-looking mail, but real "written by a human" mail, and the majority of address verification mails, usually get through without greylisting. > Do you let them all pass and trust that microsoft is protecting there > service enough to stop spamming from hijacked machines that use office365 ? Never mind spam, from what I can see Microsoft don't even kill off actual malware hosted on their own domains (e.g. sharepoint.com) in a timely fashion.. But they undoubtedly will have per-sender rate limits on email. I don't see greylisting from the address space listed in their SPF records or dnswl entries as doing much good. > I'm a little reluctant to whitelist a shitload of ips just to get rid of > a 1 or 2 day delay in delivering the message and yes this was the case And if you're unlucky they don't retry from the same IP before the message gets too old and falls out of the sender's queue.
Re: spamd and outlook.com
Op Fri, 21 Apr 2017 14:12:56 +0200 schreef Reyk Floeter: On Fri, Apr 21, 2017 at 01:52:05PM +0200, Boudewijn Dijkstra wrote: Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter : > On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote: > > On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote: > > > > > I use the attached script to fetch the SPF entries recursively, in a > plain text format that can be fed into pfctl. Have you tried mx3a.certifiedfactory.info ? ;) great I think you got something wrong: I don't use this simple script automatically or for "untrusted domains", I just use it _manually_ and for _well-known_ offenders like outlook.com that break greylisting. I only pointed out a weakness. Infinite loops may happen regardless of trust or reputation, so the weakness should IMHO be either documented or fixed. SPF is not a security solution, but it is a band-aid that helps to handle these stupid cloud-based MTAs. The script below fixes it - or akpoff's slightly more complicated (and probably more correct) version. Thanks. -- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
Re: spamd and outlook.com
Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter: On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote: On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote: > I use the attached script to fetch the SPF entries recursively, in a plain text format that can be fed into pfctl. Have you tried mx3a.certifiedfactory.info ? ;) -- Gemaakt met Opera's e-mailprogramma: http://www.opera.com/mail/
no network in bsd.rd when wifi card is present
My main OpenBSD system is a Shuttle SH81R4 with a 4th Gen i5. I run the latest snapshot on it and once or twice a week I will boot into bsd.rd and run update. A week or two ago I put a mini-pcie wifi card in it (athn0) and after getting some help from this mailing list, I got this system running as an Access Point. I have since noticed a strange issue. Now, when I boot into bsd.rd, I have no network. When i try to upgrade, I will see the DHCPDISCOVER, DHCPOFFER, etc go by and it is all right, but when get to the “lets upgrade the sets” part, i get the (Unable to get list from ftp.openbsd.org, but that is OK) message and any attempt to actually download the updated packages fails. If I ctrl+c to a prompt, i can run ‘dhclient re0’ and it looks like it succeeds, but when I run ‘ifconfig’, re0 does not have an ip address. I can’t even ping the ip address of my router. If I actually remove the wifi adapter (as in, open the case and physically remove the mini-pcie card from its slot) and try it, it works fine (though entering a number for a different mirror doesn’t seem to work). Removing the pcie card every time I want to install the latest build is very inconvenient. Is there a workaround for this? Jordon
Re: spamd and outlook.com
On 04/21/17 07:12, Reyk Floeter wrote: On Fri, Apr 21, 2017 at 01:52:05PM +0200, Boudewijn Dijkstra wrote: Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter: On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote: On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote: I use the attached script to fetch the SPF entries recursively, in a plain text format that can be fed into pfctl. Have you tried mx3a.certifiedfactory.info ? ;) great I think you got something wrong: I don't use this simple script automatically or for "untrusted domains", I just use it _manually_ and for _well-known_ offenders like outlook.com that break greylisting. SPF is not a security solution, but it is a band-aid that helps to handle these stupid cloud-based MTAs. The script below fixes it - or akpoff's slightly more complicated (and probably more correct) version. Reyk ---snip--- #!/usr/bin/perl # Copyright (c) 2016, 2017 Reyk Floeter # # Permission to use, copy, modify, and distribute this software for any # purpose with or without fee is hereby granted, provided that the above # copyright notice and this permission notice appear in all copies. # # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. $domain = shift @ARGV or die "usage: $0 domain"; %seen = {}; sub parsespf { my $domain = shift; my @foo = `nslookup -q=TXT $domain`; my @results = (); foreach (@foo) { next if not /$domain\ttext/; next if not s/$domain\ttext = "v=spf1([^"]+)"/$1/; @results = split /\s+/; foreach (@results) { next if /.all/; if (s/^ip[46]://) { print "$_\n"; } elsif (s/^(redirect|include)[:=]//) { print "\n#$_\n"; if (!$seen{$_}) { $seen{$_} = true; parsespf($_); } } } } } parsespf($domain); 0; I'm glad I'm not the only one with this problem. I started off just adding individual ip's to my nospamd as needed, but they deliver mail so stupidly. One message may get sent from in my experience 4 different ip's so they get trapped each time and I'm guessing they eventually give up. Luckily https://home.nuug.no/~peter/nospamd came across my screen one day. It seems to have cured my problem. Thanks Peter!
Re: Bad kernel for OpenBSD 6.1 sparc64 ?
On Fri, 21 Apr 2017, Stefan Sperling wrote: > On Thu, Apr 20, 2017 at 06:13:47PM -0600, Jeff wrote: > > Hi, > > > > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0. > > I attempted to update to OpenBSD 6.1 using the files first from: > > > > http://mirrors.sonic.net/pub/OpenBSD/6.1/sparc64 > > > > Then from: > > > > https://ftp3.usa.openbsd.org/pub/OpenBSD/6.1/sparc64 > > > > First I tried to copy bsd.rd to / and boot from it. When I boot > > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show > > OpenBSD 6.0. > > Did you actually type '/boot bsd.rd'? > When booting from softraid you need to pass the virtual 'sr' drive > as part of the boot path. Try again with: boot sr0a:/bsd.rd > > >From the boot_sparc64(8) man page: > > To boot from a softraid(4) volume by default, boot-device must be set to > a disk device hosting a chunk of the softraid volume: > >ok setenv boot-device disk0 > > and boot-file must contain the (sr) device name of the softraid volume > and optionally a partition letter and/or kernel: > >ok setenv boot-file sr0a:/bsd > Hi Stefan, Thanks! I must have missed that man page when I originally installed 6.0. Booting with sr0a:/bsd* did work but it took a much longer time loading the symbols with both bsd & bsd.rd. I'll be sure to read that man page and try again later today after I'm done working (in case I muck it up again). Using a non-standard name for the bsd.rd file seems to help clarify things. ok printenv boot-device boot-device = disk1:a /pci@1f,0/pci@1/scsi@8/disk@1,0:a ok boot disk1:a /bsd.rd.61 ... Executing last command: boot disk1:a /bsd.rd.61 Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a File and args: /bsd.rd.61 OpenBSD IEEE 1275 Bootblock 1.4 ..>> OpenBSD BOOT 1.7 Can't read disk label. Can't open disk label package Drive not ready Can't read disk label. Can't open disk label package sr0* open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/etc/random.seed: No such file or directory open /pci@1f,0/pci@1/scsi@8/disk@1,0:a/bsd.rd.61: No such file or directory Boot: lom> reset ok boot sr0a:/bsd.rd.61 Boot device: /pci@1f,0/pci@1/scsi@8/disk@1,0:a File and args: sr0a:/bsd.rd.61 OpenBSD IEEE 1275 Bootblock 1.4 ..>> OpenBSD BOOT 1.7 Can't read disk label. Can't open disk label package Drive not ready Can't read disk label. Can't open disk label package sr0* Booting sr0:a/bsd.rd.61 4045496@0x100+1352@0x13dbab8+3251904@0x180+942400@0x1b19ec0 symbols @ 0xfff42300 120 start=0x100 console is /pci@1f,0/pci@1,1/isa@7/serial@0,3f8 Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2017 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.1 (RAMDISK) #55: Sat Apr 1 17:41:52 MDT 2017 dera...@sparc64.openbsd.org:/usr/src/sys/arch/sparc64/compile/RAMDISK
Re: Is randomizing UID/GUID would make sense?
Thanks for the start points, Christian and Philip. I would have never thought about those use cases. I'll definitely look into this further. On Wed, 19 Apr 2017 13:31:08 + (UTC) Christian Weisgerberwrote: > On 2017-04-19, Philip Guenther wrote: > > > For a broader answer to the "why?", take a look at the patches under > > /usr/ports/ which add uses of the *_deterministic() calls. > > For instance, take graphics/netpbm and look at its multitude of > image manipulation tools that take a -randomseed=integer argument > to ensure that the same result can be obtained on separate > invocations. >
acme-client(1) and http_proxy
Hi, I'm trying to use the new acme-client on a server behind a corporate proxy (i.e. I have to set a http_proxy to get out). It seems (from reading the code) that acme-client(1) does not honor http_proxy. Is this on purpose? If so, can someone point me to another acme client that does this? -- Manuel Giraud
Re: spamd and outlook.com
And apropos of the subject, quite on-topic: https://home.nuug.no/~peter/dmarc-reject_openbsd-misc_spadm_and_spf.txt - P (pats robot on virtual head) -- 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: spamd and outlook.com
On Fri, Apr 21, 2017 at 01:52:05PM +0200, Boudewijn Dijkstra wrote: > Op Fri, 21 Apr 2017 12:16:31 +0200 schreef Reyk Floeter: > > On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote: > > > On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote: > > > > > > > > I use the attached script to fetch the SPF entries recursively, in a > > plain text format that can be fed into pfctl. > > Have you tried mx3a.certifiedfactory.info ? ;) > great I think you got something wrong: I don't use this simple script automatically or for "untrusted domains", I just use it _manually_ and for _well-known_ offenders like outlook.com that break greylisting. SPF is not a security solution, but it is a band-aid that helps to handle these stupid cloud-based MTAs. The script below fixes it - or akpoff's slightly more complicated (and probably more correct) version. Reyk ---snip--- #!/usr/bin/perl # Copyright (c) 2016, 2017 Reyk Floeter # # Permission to use, copy, modify, and distribute this software for any # purpose with or without fee is hereby granted, provided that the above # copyright notice and this permission notice appear in all copies. # # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. $domain = shift @ARGV or die "usage: $0 domain"; %seen = {}; sub parsespf { my $domain = shift; my @foo = `nslookup -q=TXT $domain`; my @results = (); foreach (@foo) { next if not /$domain\ttext/; next if not s/$domain\ttext = "v=spf1([^"]+)"/$1/; @results = split /\s+/; foreach (@results) { next if /.all/; if (s/^ip[46]://) { print "$_\n"; } elsif (s/^(redirect|include)[:=]//) { print "\n#$_\n"; if (!$seen{$_}) { $seen{$_} = true; parsespf($_); } } } } } parsespf($domain); 0;
Re: Strange PF behaviour after 6.0 -> 6.1 pgrade
> On 21 Apr 2017, at 10:34, Stuart Hendersonwrote: > > On 2017-04-20, Sjöholm Per-Olov wrote: >> Could it be any buffers that is causing this in 6.1 but not in 6.0 ? > > There were changes that would allow larger TCP buffers in 6.1. This > would not have made a difference to normal or natted connections from > non-OpenBSD going through PF to non-OpenBSD but could possibly affect > some configurations with proxies (though only if PF rules were already > dodgy - you would have active states in "pfctl -ss|grep -A1 tcp" > without wscale values if this was the case). > > Might be worth bumping up the pf log level and seeing if system logs > give you more clues. Default is "error", you need "notice" to get the > ones which might give useful clues (loose state match warnings or > state mismatch errors). (On a busy machine, be ready to back-off on > the debug level in case it causes too much load). > > Another addition… This is what the problem actually looks like ## 1 ## When the problem is ongoing…. Telnet from internet to DMZ server FAIL [sjoholmp@dewey ~]$ telnet mail.dyn.incedo.org 25 Trying 155.4.8.28... ^C ## 2 ## This looks like this Apr 21 14:06:28.751796 rule 573/(match) pass in on em3: 168.235.89.110.42126 > 192.168.1.12.25: S 2597688027:2597688027(0) win 29200 (DF) Apr 21 14:06:28.751824 rule 63/(match) block out on em3: 155.4.8.28.25 > 168.235.89.110.42126: R 0:0(0) ack 2597688028 win 0 (DF) ## 3 ## Reload PF root@xanadu:/var/log#pfctl -f /etc/pf.conf root@xanadu:/var/log# ## 4 ## Telnet from internet again WORKS [sjoholmp@dewey ~]$ telnet mail.dyn.incedo.org 25 Trying 155.4.8.28... Connected to mail.dyn.incedo.org. Escape character is '^]'. 220 mail.dyn.incedo.org ESMTP Sendmail; Fri, 21 Apr 2017 14:08:16 +0200 ## 5 ## Looks like this Apr 21 14:08:16.239213 rule 573/(match) pass in on em3: 168.235.89.110.42168 > 192.168.1.12.25: S 4285065753:4285065753(0) win 29200 (DF) Apr 21 14:08:16.239267 rule 89/(match) pass out on vlan3: 168.235.89.110.42168 > 192.168.1.12.25: S 4285065753:4285065753(0) win 29200 (DF) ## 6 ## After a few hours the same problem occurs again which requires a PF reload The dmesg extra output ater pfctl -x notice only shows.. pf: pf_map_addr: selected address 155.4.8.28 I have serious problems with 6.1. I will probably go back to 6.0. I will giveit to the end of this day and check what I can… Peo
Re: Strange PF behaviour after 6.0 -> 6.1 pgrade
> On 21 Apr 2017, at 10:34, Stuart Hendersonwrote: > > On 2017-04-20, Sjöholm Per-Olov wrote: >> Could it be any buffers that is causing this in 6.1 but not in 6.0 ? > > There were changes that would allow larger TCP buffers in 6.1. This > would not have made a difference to normal or natted connections from > non-OpenBSD going through PF to non-OpenBSD but could possibly affect > some configurations with proxies (though only if PF rules were already > dodgy - you would have active states in "pfctl -ss|grep -A1 tcp" > without wscale values if this was the case). > > Might be worth bumping up the pf log level and seeing if system logs > give you more clues. Default is "error", you need "notice" to get the > ones which might give useful clues (loose state match warnings or > state mismatch errors). (On a busy machine, be ready to back-off on > the debug level in case it causes too much load). > > Tnx for the answer Stuart I will check and do what you suggest. In the meanwhile some additions… I have removed all tuning in sysctl.conf to make sure we have nothing that interfere. When pf is reloaded it works perfect for hours. And then the kernel, just like that stops route some packages. when it works it could look like this in the logg… Apr 21 10:32:14.734332 rule 573/(match) pass in on em3: 202.67.41.252.49461 > 192.168.1.12.25: S 583218598:583218598(0) win 8192 (DF) Apr 21 10:32:14.734356 rule 89/(match) pass out on vlan3: 202.67.41.252.49461 > 192.168.1.12.25: S 583218598:583218598(0) win 8192 (DF) Note that the problem appeared and started just between these above and below connections. When it happens I have permanent intermittent issues that is only solved by reloading pf. When it stops working after a few hours it then looks like this where the kernel simply refuse to forward the incoming internet packet on em3 packet to the dmz1 (i.e vlan3)… Apr 21 10:32:17.373591 rule 573/(match) pass in on em3: 122.200.1.158.55956 > 192.168.1.12.25: S 1479648704:1479648704(0) win 8192 (DF) Apr 21 10:32:17.373618 rule 63/(match) block out on em3: 155.4.8.28.25 > 122.200.1.158.55956: R 0:0(0) ack 1479648705 win 0 (DF) root@xanadu:/var/log#pfctl -g -sr|grep @573 @573 pass in log quick on em3 inet proto tcp from any to 192.168.1.12 port = 25 flags S/FSRA keep state (source-track rule, max-src-states 90, max-src-conn 90, max-src-conn-rate 30/30, max-src-nodes 70, overload flush global, src.track 30) label "MAIL" root@xanadu:/var/log#pfctl -g -sr|grep @89 @89 pass out log quick on vlan3 inet proto tcp all flags S/SA root@xanadu:/var/log#pfctl -g -sr|grep @63 @63 block drop log all So is it perhaps possible to give any more hints based on this extra info? Here I see wscale in both cases. Note though that on 6.0 it worked flawlessly. I upgraded from 6.0 and just did what the upgrade guide said + did a sysmerge where I kept my pf.conf as is. Peo
Re: spamd and outlook.com
Hello Peter/all, On Fri, 21 Apr 2017 11:59:20 +0200 "Peter N. M. Hansteen" wrote: > > start with > > $ host -ttxt outlook.com > > and follow the includes to the very end. Then weep. > In February 2015 Paul de Weerd calculated Google published 217,088 IPv4 addresses, and 29,710,560,942,849,126,597,578,981,376 IPv6 addresses as valid SMTP servers. See: http://marc.info/?l=openbsd-misc=142478407909186 It would be reasonable to state Google (and others) have populated SPF with LIES. Boudewijn Dijkstra wrote: "SPF was never meant for making accept/reject decisions on arbitrary domains. If you don't trust the sending domain, then SPF evaluation is pointless." http://marc.info/?l=openbsd-misc=148232868408696 Regards, -- Craig Skinner | http://linkd.in/yGqkv7
Re: spamd and outlook.com
Hi Markus, On Fri, 21 Apr 2017 11:25:14 +0200 Markus Rosjat wrote: > so if you have spamd in place in greylisting mode and you have > customers that work with people who use Office365 as a service you > will get calls that emails are delayed for a freaking long time Email is not instant messaging. Customers need educated to that fact. > > So what are the strategies out there to handle this kind of > situation? Do you let them all pass and trust that microsoft is > protecting there service enough to stop spamming from hijacked > machines that use office365 ? > http://web.britvault.co.uk/products/ungrey-robins/logs/outlook.txt The ungrey-robins tool, with patterns for Outlook, Google, Amazon, etc: http://web.britvault.co.uk/products/ungrey-robins/ > > Just curious here I had a case where you could dig the mx for a > domain and it was a outlook.com server. No. DNS MX records are used for sending mail _TO_ a domain. Inbound mail routing doesn't apply to outbound mail. Domains may relay out via other domains (e.g. their ISP's mail farm). When sending, many domains SMTP HELO with google, outlook, etc... The ungrey-robins tool looks at the HELO hostname, not the FROM domain. See the misc@ thread "spamd and network whitelisting" http://marc.info/?t=14818982922 Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: Van Jacobson network channels
On 03/04/17(Mon) 10:41, Hrvoje Popovski wrote: > Hi all, > > i'm reading some networking stuff and I saw Van Jacobson presentation > about net channels concept. > For me, as user that doesn't know net internals, this presentation seems > quite reasonable. > > Beside that it's about linux network stack, what net gurus think about > VJ net channels ? > > http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf It's an interesting idea. But you have to understand the context in which it has been presented. I doubt that replacing "mbuf queue" (see mq_init(9)) by net channels will buy us anything for now. We're still in the phase of eliminating the 'softint' context and moving everything to tasks, close to where the packets will be consumed, as explained in the presentation. Once that's done we might see if a lock-free FIFO helps to pass packets between contexts.
Re: spamd and outlook.com
On Fri, Apr 21, 2017 at 11:59:20AM +0200, Peter N. M. Hansteen wrote: > On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote: > > > > so if you have spamd in place in greylisting mode and you have customers > > that work with people who use Office365 as a service you will get calls that > > emails are delayed for a freaking long time and if you check the ip range > > that outlook.com could send from you get scared. > > start with > > $ host -ttxt outlook.com > > and follow the includes to the very end. Then weep. > > TL;DR: last time I looked that expanded to eighty-some *networks* of varying > sizes. > > https://github.com/akpoff/spf_fetch fed the relevant domains is one solution, > and in addition you will find my collection of manually maintained SPF > sedimentation > is available at https://home.nuug.no/~peter/nospamd > I use the attached script to fetch the SPF entries recursively, in a plain text format that can be fed into pfctl. outlook.com gives me 82 networks. Reyk ---snip--- #!/usr/bin/perl # Copyright (c) 2016 Reyk Floeter# # Permission to use, copy, modify, and distribute this software for any # purpose with or without fee is hereby granted, provided that the above # copyright notice and this permission notice appear in all copies. # # THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES # WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR # ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES # WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN # ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF # OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. $domain = shift @ARGV or die "usage: $0 domain"; sub parsespf { my $domain = shift; my @foo = `nslookup -q=TXT $domain`; my @results = (); foreach (@foo) { next if not /$domain\ttext/; next if not s/$domain\ttext = "v=spf1([^"]+)"/$1/; @results = split /\s+/; foreach (@results) { next if /.all/; if (s/^ip[46]://) { print "$_\n"; } elsif (s/^(redirect|include)[:=]//) { print "\n#$_\n"; parsespf($_); } } } } parsespf($domain); 0;
Re: spamd and outlook.com
hey peter, like your pf book very much helped me a lot to grasp some stuff :) fot the host solution I already did this but skiped the part with following the includes. MS is providing a list of there possible ip ranges here https://technet.microsoft.com/en-us/library/dn163583(v=exchg.150).aspx and thats just scary ... Am 21.04.2017 um 11:59 schrieb Peter N. M. Hansteen: On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote: so if you have spamd in place in greylisting mode and you have customers that work with people who use Office365 as a service you will get calls that emails are delayed for a freaking long time and if you check the ip range that outlook.com could send from you get scared. start with $ host -ttxt outlook.com and follow the includes to the very end. Then weep. TL;DR: last time I looked that expanded to eighty-some *networks* of varying sizes. https://github.com/akpoff/spf_fetch fed the relevant domains is one solution, and in addition you will find my collection of manually maintained SPF sedimentation is available at https://home.nuug.no/~peter/nospamd The problem is that the 'architects' behind outlook.com and their ilk are really not on board with the idea that having some tiny bit of control over where your mail comes from is a good idea, but they were made to comply with the SPF/DKIM/DMARC scheme (straight out of the Rube Goldberg school of engineering), which is one of those endless and endlessly tiresome artifacts of the "something has to be done", "this is something" 'system architect' responses. -- Markus Rosjatfon: +49 351 8107223mail: ros...@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: spamd and outlook.com
On Fri, Apr 21, 2017 at 11:25:14AM +0200, Markus Rosjat wrote: > > so if you have spamd in place in greylisting mode and you have customers > that work with people who use Office365 as a service you will get calls that > emails are delayed for a freaking long time and if you check the ip range > that outlook.com could send from you get scared. start with $ host -ttxt outlook.com and follow the includes to the very end. Then weep. TL;DR: last time I looked that expanded to eighty-some *networks* of varying sizes. https://github.com/akpoff/spf_fetch fed the relevant domains is one solution, and in addition you will find my collection of manually maintained SPF sedimentation is available at https://home.nuug.no/~peter/nospamd The problem is that the 'architects' behind outlook.com and their ilk are really not on board with the idea that having some tiny bit of control over where your mail comes from is a good idea, but they were made to comply with the SPF/DKIM/DMARC scheme (straight out of the Rube Goldberg school of engineering), which is one of those endless and endlessly tiresome artifacts of the "something has to be done", "this is something" 'system architect' responses. -- 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: Bad kernel for OpenBSD 6.1 sparc64 ?
On 2017-04-21 10:50, Stefan Sperling wrote: On Fri, Apr 21, 2017 at 09:04:07AM +0200, Mickael Torres wrote: On 2017-04-21 02:13, Jeff wrote: > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0. > ... > First I tried to copy bsd.rd to / and boot from it. When I boot > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show > OpenBSD 6.0. Hi Jeff, If you use softraid on sparc64, you should have a small ffs FS on your first disk, containing the kernel and ofwboot. That *is* where you should put the new bsd.rd, and copy the new kernel(s) at the end of install. The firmware doesn't know how to boot a softraid volume, hence the need for this small FS. A separate boot partition is not required. The first stage boot loader is a Forth script which reads a second stage (ofwboot) from the softraid meta data area. ofwboot will load a kernel from RAID1 and CRYPTO volumes. See the last few slides in https://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf The install/upgrade scripts run installboot(8) to set this up. The only differences to i386/amd64 is that bootable sparc64 RAID partitions must use the letter 'a' (the first stage does not try any other letters) and that the boot-device and boot-file open firmware environment variables must be set up correctly (see boot_sparc64(8)). Wow, you've just made my day! Thanks, Stefan. Best regards, Mickael.
spamd and outlook.com
Hi there, so if you have spamd in place in greylisting mode and you have customers that work with people who use Office365 as a service you will get calls that emails are delayed for a freaking long time and if you check the ip range that outlook.com could send from you get scared. So what are the strategies out there to handle this kind of situation? Do you let them all pass and trust that microsoft is protecting there service enough to stop spamming from hijacked machines that use office365 ? Do you gradually grand access to a new ip rang if you see its tring to reach your server and let the rest be? Just curious here I had a case where you could dig the mx for a domain and it was a outlook.com server. It was whitelisted in my system but it seems MS is using this mx to retrieve mail and still send mails even from that domain with other mx in diffrent ranges. So you see 30 grey entries from diffent mx that trying to reach the customers mailbox. I'm a little reluctant to whitelist a shitload of ips just to get rid of a 1 or 2 day delay in delivering the message and yes this was the case regards -- Markus Rosjatfon: +49 351 8107223mail: ros...@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: Bad kernel for OpenBSD 6.1 sparc64 ?
On Fri, Apr 21, 2017 at 09:04:07AM +0200, Mickael Torres wrote: > On 2017-04-21 02:13, Jeff wrote: > > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0. > > ... > > First I tried to copy bsd.rd to / and boot from it. When I boot > > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show > > OpenBSD 6.0. > > Hi Jeff, > > If you use softraid on sparc64, you should have a small ffs FS on your > first disk, containing the kernel and ofwboot. > That *is* where you should put the new bsd.rd, and copy the new kernel(s) > at the end of install. > > The firmware doesn't know how to boot a softraid volume, hence the need > for this small FS. A separate boot partition is not required. The first stage boot loader is a Forth script which reads a second stage (ofwboot) from the softraid meta data area. ofwboot will load a kernel from RAID1 and CRYPTO volumes. See the last few slides in https://www.openbsd.org/papers/eurobsdcon2015-softraid-boot.pdf The install/upgrade scripts run installboot(8) to set this up. The only differences to i386/amd64 is that bootable sparc64 RAID partitions must use the letter 'a' (the first stage does not try any other letters) and that the boot-device and boot-file open firmware environment variables must be set up correctly (see boot_sparc64(8)).
OpenBSD 6.1, spamd strange behavior
Hello misc I'm setting the small mail system and I don't investigate with the working of spamd. spamd is working in the greylisting mode with "-v -G 2:4:864" options. For every trying of the delivery mail a remote host become TRAPPED for 24 hours, and I don't understand why. Please help me change the situation. And excuse my English, I'm still learning it. -- /Alex
Re: Bad kernel for OpenBSD 6.1 sparc64 ?
On Thu, Apr 20, 2017 at 06:13:47PM -0600, Jeff wrote: > Hi, > > I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0. > I attempted to update to OpenBSD 6.1 using the files first from: > > http://mirrors.sonic.net/pub/OpenBSD/6.1/sparc64 > > Then from: > > https://ftp3.usa.openbsd.org/pub/OpenBSD/6.1/sparc64 > > First I tried to copy bsd.rd to / and boot from it. When I boot > using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show > OpenBSD 6.0. Did you actually type '/boot bsd.rd'? When booting from softraid you need to pass the virtual 'sr' drive as part of the boot path. Try again with: boot sr0a:/bsd.rd >From the boot_sparc64(8) man page: To boot from a softraid(4) volume by default, boot-device must be set to a disk device hosting a chunk of the softraid volume: ok setenv boot-device disk0 and boot-file must contain the (sr) device name of the softraid volume and optionally a partition letter and/or kernel: ok setenv boot-file sr0a:/bsd
Re: Strange PF behaviour after 6.0 -> 6.1 pgrade
On 2017-04-20, Sjöholm Per-Olovwrote: > Could it be any buffers that is causing this in 6.1 but not in 6.0 ? There were changes that would allow larger TCP buffers in 6.1. This would not have made a difference to normal or natted connections from non-OpenBSD going through PF to non-OpenBSD but could possibly affect some configurations with proxies (though only if PF rules were already dodgy - you would have active states in "pfctl -ss|grep -A1 tcp" without wscale values if this was the case). Might be worth bumping up the pf log level and seeing if system logs give you more clues. Default is "error", you need "notice" to get the ones which might give useful clues (loose state match warnings or state mismatch errors). (On a busy machine, be ready to back-off on the debug level in case it causes too much load).
new groups
0 C Iran P Tehran T Tehran F irregular O Iranian meetBSD Group I abdorrahman homaei M d.orien...@gmail.com U http://meetbsd.ir N *BSD
Re: Bad kernel for OpenBSD 6.1 sparc64 ?
On 2017-04-21 02:13, Jeff wrote: I have a Sunfire V120 (Sparc) with mirrored disks running OpenBSD 6.0. ... First I tried to copy bsd.rd to / and boot from it. When I boot using 6.1 bsd.rd (boot /bsd.rd), the boot messages still show OpenBSD 6.0. Hi Jeff, If you use softraid on sparc64, you should have a small ffs FS on your first disk, containing the kernel and ofwboot. That *is* where you should put the new bsd.rd, and copy the new kernel(s) at the end of install. The firmware doesn't know how to boot a softraid volume, hence the need for this small FS. Best regards, Mickael.
Re: Performance Clang
On Thu, Apr 20, 2017 at 07:31:47PM +, Christian Weisgerber wrote: > On 2017-04-19, Heikowrote: > > > I'm using current on amd64 (Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz, > > 3411.91 MHz) > > > > I noticed that with clang it needs 109 minutes for "make build" and > > before with gcc 32 minutes. > > Not sure what you mean by "performance" in the subject. We're not > building anything with clang yet, apart from clang itself. We have > simply added clang. The rest of the build is identical. > > And yes, clang is a big C++ program and C++ code compiles s l o w l y. > > > Is this a normal behavior? > > The exact numbers are a bit odd, but generally speaking, yes, adding > clang has substantially increased the build time. I see about a > doubling on Xeon E3-12xx-based machines for make -j4 build. I'm happy as long as building the complete base system takes less than a day. I'm more concerned with the compiler generating good code, to be honest. Cheers, Kusalananda
Re: Adding default IPv6 route fails on 6.1
On 2017-04-19, Harald Dunkelwrote: > > On 04/18/17 17:05, Stuart Henderson wrote: >> >> Mine is in the pkg-readme. >> >> > > A pkg-readme? Is this included in the binary package? Yes - pkg_add should have drawn your attention to it: # pkg_add dhcpcd dhcpcd-6.11.5: ok The following new rcscripts were installed: /etc/rc.d/dhcpcd See rcctl(8) for details. Look in /usr/local/share/doc/pkg-readmes for extra documentation.