Re: False positives from header_checks
Unfortunately, I don't have time to decode this discussion. Can someone post a tested diff, someone maybe post a revised version, and when there is agreement, then I can adopt it. Wietse
rate limiting bad-bot HANGUPs in postscreen?
With postscreen in place, bad bots arr getting fended off. Many give up and go away after a couple of tries. Some, these days mostly 'ymlf-pc' bots, are more persistent. Eg, this one Apr 8 04:17:20 mail01 postfix/postscreen[20412]: CONNECT from [37.49.226.17]:52066 to [192.0.2.17]:25 Apr 8 04:17:20 mail01 postfix/dnsblog[20417]: addr 37.49.226.17 listed by domain zen.spamhaus.org as 127.0.0.4 Apr 8 04:17:21 mail01 postfix/postscreen[20412]: PREGREET 14 after 0.14 from [37.49.226.17]:52066: EHLO ylmf-pc\r\n Apr 8 04:17:21 mail01 postfix/postscreen[20412]: DNSBL rank 6 for [37.49.226.17]:52066 Apr 8 04:17:21 mail01 postfix/postscreen[20412]: HANGUP after 0.85 from [37.49.226.17]:52066 in tests after SMTP handshake Apr 8 04:17:21 mail01 postfix/postscreen[20412]: DISCONNECT [37.49.226.17]:52066 Apr 8 04:17:22 mail01 postfix/postscreen[20412]: CONNECT from [37.49.226.17]:54974 to [192.0.2.17]:25 Apr 8 04:17:22 mail01 postfix/dnsblog[20415]: addr 37.49.226.17 listed by domain zen.spamhaus.org as 127.0.0.4 Apr 8 04:17:22 mail01 postfix/postscreen[20412]: PREGREET 14 after 0.15 from [37.49.226.17]:54974: EHLO ylmf-pc\r\n Apr 8 04:17:22 mail01 postfix/postscreen[20412]: DNSBL rank 6 for [37.49.226.17]:54974 Apr 8 04:17:23 mail01 postfix/postscreen[20412]: HANGUP after 0.77 from [37.49.226.17]:54974 in tests after SMTP handshake Apr 8 04:17:23 mail01 postfix/postscreen[20412]: DISCONNECT [37.49.226.17]:54974 Apr 8 04:17:25 mail01 postfix/postscreen[20412]: CONNECT from [37.49.226.17]:58871 to [192.0.2.17]:25 ... conitinues on for a total of (in this case) 237 attempts in one continuous string over a few minutes. These do not appear as multiple CONCURRENT connection, which I think I can limit with ' postscreen_client_connection_count_limit'. Instead, they look like SEQUENTIAL connections. IIUC, this is a pretty efficient disconnection by postscreen, so not a huge load on the server. But, it's still making connections. I can rate limit these in fail2ban+firewall (e.g., http://shorewall.net/ConnectionRate.html), but would prefer to keep this re-action in Postfix. Is there a postscreen_ parameter to rate limit these "bursts"? Maybe dropping the connection sooner? Jason
reality-check on 2016 practical advice re: requiring inbound TLS?
I'm setting up mandatory TLS policy for a couple of private client servers, using - smtpd_tls_security_level = may + smtpd_tls_security_level = encrypt I started wondering whether it wouldn't be a bad thing to require ALL email delivered to my server, from anywhere, to use TLS. Reading at http://www.postfix.org/TLS_README.html It warns against doing this. You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, by setting "smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP server. This option is off by default and should only seldom be used. That RFC, though, is from January 1999 http://tools.ietf.org/html/rfc2487 and afaict has been superceded by http://tools.ietf.org/html/rfc3207 from February 2002, which also says "A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally." It's 14 years later, and a lot's changed in SSL usage. Are there any later relevant RFCs that change this advice against forced TLS? Regardless of RFC, in today's "SSL everywhere" atmosphere, is this still good, practical advice? I've turned on smtpd_tls_loglevel=1, and will watch for awhile on my own servers. What do you 'real world' Postfix admins see/do these days? Jason
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
Per the DROWN mitigation, I stopped allowing sslv2 and sslv3, so I made it a point to read the headers and look for encryption issues. My conclusion is there is always "that one guy" that doesn't use encryption. In my case, literally one guy. Not being able to get his "regular" email to work, I got him to switch to gmail. This is on my personal server. If you have customers, then each customer can have that "one guy", so it depends on how much time you want to sink into getting a third party to encrypt. I also made it a point to look for use of SPF and DKIM. Excluding the spammers that got through, nearly every user had both SPF and DKIM, but not all. One lacking SPF is a new business partner. The account without DKIM was a commercial vendor. My point here was I had considered setting up policies to reject email that didn't have both SPF and DKIM, but doing a survey realized there would be real situations where legitimate email would not get through. One person I know uses pobox.com, and that fails SPF. I think policing everyone's email set up will lead to a lot of busy work. Original Message From: jaso...@mail-central.com Sent: Saturday, April 9, 2016 8:47 AM To: postfix-users@postfix.org Subject: reality-check on 2016 practical advice re: requiring inbound TLS? I'm setting up mandatory TLS policy for a couple of private client servers, using - smtpd_tls_security_level = may + smtpd_tls_security_level = encrypt I started wondering whether it wouldn't be a bad thing to require ALL email delivered to my server, from anywhere, to use TLS. Reading at http://www.postfix.org/TLS_README.html It warns against doing this. You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, by setting "smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP server. This option is off by default and should only seldom be used. That RFC, though, is from January 1999 http://tools.ietf.org/html/rfc2487 and afaict has been superceded by http://tools.ietf.org/html/rfc3207 from February 2002, which also says "A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally." It's 14 years later, and a lot's changed in SSL usage. Are there any later relevant RFCs that change this advice against forced TLS? Regardless of RFC, in today's "SSL everywhere" atmosphere, is this still good, practical advice? I've turned on smtpd_tls_loglevel=1, and will watch for awhile on my own servers. What do you 'real world' Postfix admins see/do these days? Jason
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
On Sat, Apr 9, 2016, at 09:33 AM, li...@lazygranch.com wrote: > Per the DROWN mitigation, I stopped allowing sslv2 and sslv3 Did that as well. Actually before even that point. > so I made it a point to read the headers and look for encryption issues. I admit I never even bothered to look for the effects of that^, voting instead for the BOFH-inspired "screw-em" approach. In retrospect, I've never ended up missing a mail that made a tangible difference as a result. > My conclusion is there is always "that one guy" that doesn't use encryption. > In my case, literally one guy. Not being able to get his "regular" email to > work, I got him to switch to gmail. > > This is on my personal server. If you have customers, then each customer can > have that "one guy", so it depends on how much time you want to sink into > getting a third party to encrypt. Points made. I'm not a provider, but do have clients. I guess I'm thinking about how long to mollycoddle folks still in the dark ages, clients or not. > I also made it a point to look for use of SPF and DKIM. Excluding the > spammers that got through, nearly every user had both SPF and DKIM, but not > all. One lacking SPF is a new business partner. The account without DKIM was > a commercial vendor. My point here was I had considered setting up policies > to reject email that didn't have both SPF and DKIM, but doing a survey > realized there would be real situations where legitimate email would not get > through. One person I know uses pobox.com, and that fails SPF. I block on strict FAILs of any if SPF, DKIM or DMARC. *missing* support for those is logged, but not - yet - acted on. > I think policing everyone's email set up will lead to a lot of busy work. True. One option is to stop policing, make sure MY postfix provides correct error-messages, and leave them to their own troubles. Thanks for the comments. 'Someone' out there has some thorough statistics ... Interesting to know a bit more. Jason
Re: rate limiting bad-bot HANGUPs in postscreen?
I use a script which greps for repeated HANGUPS (and non-SNMP commands, etc) and adds them to a postscreen access file (a separate blacklist file chat can be re-compiled as and when). The black-list entry is retracted after a day or so. A second script looks for repeated black-list refusals and adds the offender to the firewall drop-list. This entry is removed after a day, AND when the iptable counters have stopped incrementing. It is overkill in my case, but it keeps my hand in at writing scripts :-) Allen C On 09/04/16 15:44, jaso...@mail-central.com wrote: > With postscreen in place, bad bots arr getting fended off. > > Many give up and go away after a couple of tries. > > Some, these days mostly 'ymlf-pc' bots, are more persistent. > > Eg, this one > > Apr 8 04:17:20 mail01 postfix/postscreen[20412]: CONNECT from > [37.49.226.17]:52066 to [192.0.2.17]:25 > Apr 8 04:17:20 mail01 postfix/dnsblog[20417]: addr 37.49.226.17 listed > by domain zen.spamhaus.org as 127.0.0.4 > Apr 8 04:17:21 mail01 postfix/postscreen[20412]: PREGREET 14 after > 0.14 from [37.49.226.17]:52066: EHLO ylmf-pc\r\n > Apr 8 04:17:21 mail01 postfix/postscreen[20412]: DNSBL rank 6 for > [37.49.226.17]:52066 > Apr 8 04:17:21 mail01 postfix/postscreen[20412]: HANGUP after 0.85 > from [37.49.226.17]:52066 in tests after SMTP handshake > Apr 8 04:17:21 mail01 postfix/postscreen[20412]: DISCONNECT > [37.49.226.17]:52066 > Apr 8 04:17:22 mail01 postfix/postscreen[20412]: CONNECT from > [37.49.226.17]:54974 to [192.0.2.17]:25 > Apr 8 04:17:22 mail01 postfix/dnsblog[20415]: addr 37.49.226.17 listed > by domain zen.spamhaus.org as 127.0.0.4 > Apr 8 04:17:22 mail01 postfix/postscreen[20412]: PREGREET 14 after > 0.15 from [37.49.226.17]:54974: EHLO ylmf-pc\r\n > Apr 8 04:17:22 mail01 postfix/postscreen[20412]: DNSBL rank 6 for > [37.49.226.17]:54974 > Apr 8 04:17:23 mail01 postfix/postscreen[20412]: HANGUP after 0.77 > from [37.49.226.17]:54974 in tests after SMTP handshake > Apr 8 04:17:23 mail01 postfix/postscreen[20412]: DISCONNECT > [37.49.226.17]:54974 > Apr 8 04:17:25 mail01 postfix/postscreen[20412]: CONNECT from > [37.49.226.17]:58871 to [192.0.2.17]:25 > ... > > conitinues on for a total of (in this case) 237 attempts in one continuous > string over a few minutes. > > These do not appear as multiple CONCURRENT connection, which I think I can > limit with ' postscreen_client_connection_count_limit'. > > Instead, they look like SEQUENTIAL connections. > > IIUC, this is a pretty efficient disconnection by postscreen, so not a huge > load on the server. > > But, it's still making connections. > > I can rate limit these in fail2ban+firewall (e.g., > http://shorewall.net/ConnectionRate.html), but would prefer to keep this > re-action in Postfix. > > Is there a postscreen_ parameter to rate limit these "bursts"? Maybe dropping > the connection sooner? > > Jason > >
why use "aNULL:!aNULL:" in Postfix default cipherlists?
While looking through the Postfix default configs about TLS ciphers, I noticed these grep -i " anull" main.cf.default tls_export_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH tls_low_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:+RC4:@STRENGTH tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH What's the reason for the aNULL:-aNULL ? That's not making sense to me. Doesn't that just remove what you just added? Is it a logging thing? Jason
Re: why use "aNULL:!aNULL:" in Postfix default cipherlists?
On Sat, Apr 09, 2016 at 12:01:20PM -0700, jaso...@mail-central.com wrote: > While looking through the Postfix default configs about TLS ciphers, I > noticed these > > grep -i " anull" main.cf.default > tls_export_cipherlist = > aNULL:-aNULL:HIGH:MEDIUM:LOW:EXPORT:+RC4:@STRENGTH > tls_high_cipherlist = aNULL:-aNULL:HIGH:@STRENGTH > tls_low_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:LOW:+RC4:@STRENGTH > tls_medium_cipherlist = aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH > > What's the reason for the > > aNULL:-aNULL The most recently removed ciphers are at the front of the list when ciphers are restored. Therefore, "aNULL:-aNULL:ALL:@STRENGTH" is different from "ALL:@STRENGTH" in that at any given strength the aNULL ciphers are listed first. There's not much point in enabling aNULL ciphers if they are not used when supported at both ends (and the client is ignoring any server certificate anyway). % bash $ diff -u \ <(openssl ciphers -v ALL:@STRENGTH) \ <(openssl ciphers -v aNULL:-aNULL:ALL:@STRENGTH) --- /dev/fd/63 2016-04-09 15:19:03.0 -0400 +++ /dev/fd/62 2016-04-09 15:19:03.0 -0400 @@ -1,3 +1,9 @@ +ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD +ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 +ADH-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=None Enc=Camellia(256) Mac=SHA256 +AECDH-AES256-SHASSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 +ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 +ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD @@ -9,7 +15,6 @@ ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256) Mac=AEAD DHE-RSA-AES256-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(256) Mac=AEAD DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256) Mac=AEAD -ADH-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=None Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384 DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256 @@ -18,17 +23,12 @@ ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(256) Mac=SHA384 DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA256 DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA256 -ADH-AES256-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(256) Mac=SHA256 -ADH-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=None Enc=Camellia(256) Mac=SHA256 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 ECDHE-RSA-AES256-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1 DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1 -AECDH-AES256-SHASSLv3 Kx=ECDH Au=None Enc=AES(256) Mac=SHA1 -ADH-AES256-SHA SSLv3 Kx=DH Au=None Enc=AES(256) Mac=SHA1 -ADH-CAMELLIA256-SHA SSLv3 Kx=DH Au=None Enc=Camellia(256) Mac=SHA1 RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK Au=RSA Enc=AESGCM(256) Mac=AEAD DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256) Mac=AEAD RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD @@ -62,6 +62,13 @@ PSK-AES256-CBC-SHA384 TLSv1 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA384 PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1 PSK-CAMELLIA256-SHA384 TLSv1 Kx=PSK Au=PSK Enc=Camellia(256) Mac=SHA384 +ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD +ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 +ADH-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=None Enc=Camellia(128) Mac=SHA256 +AECDH-AES128-SHASSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 +ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 +ADH-SEED-SHASSLv3 Kx=DH Au=None Enc=SEED(128) Mac=SHA1 +ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1 ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA
Re: why use "aNULL:!aNULL:" in Postfix default cipherlists?
On Sat, Apr 9, 2016, at 12:27 PM, Viktor Dukhovni wrote: > The most recently removed ciphers are at the front of the list when > ciphers are restored. Therefore, "aNULL:-aNULL:ALL:@STRENGTH" is > different from "ALL:@STRENGTH" in that at any given strength the > aNULL ciphers are listed first. There's not much point in enabling > aNULL ciphers if they are not used when supported at both ends (and > the client is ignoring any server certificate anyway). > > % bash > $ diff -u \ > <(openssl ciphers -v ALL:@STRENGTH) \ > <(openssl ciphers -v aNULL:-aNULL:ALL:@STRENGTH) ... Ok, that's dense. I clearly need to read some more. I simply don't get what the intent of that^ is. I thought 'NULL' were "a bad thing", and that we shouldn't be using them at all. Digging in various places, I've found a number of examples that had something close to smtp_tls_ciphers = medium smtpd_tls_ciphers = medium smtp_tls_exclude_ciphers = aDH, aDSS, aECDH, EXPORT, kDHd, kDHr, kECDHe, kECDHr, KRB5, LOW, MD5, PSK, RC2, RC5 smtpd_tls_exclude_ciphers = EXPORT, IDEA, LOW, MD5, RC2 smtp_tls_mandatory_ciphers = medium smtp_tls_mandatory_ciphers = medium those^ exclude lists are aggregated of what I've found so far. I'm reading up on each of them. What I want to get to is to make sure that the "bad" ciphers are NOT enable/used. Since I didn't think we should be using NULL-anything, I expected to see 'medium' NOT using them at all. I guess we're not here^, but I still can't understand why we ENABLE them first, & why that's a good thing. Jason
Re: why use "aNULL:!aNULL:" in Postfix default cipherlists?
On Sat, Apr 09, 2016 at 12:59:16PM -0700, jaso...@mail-central.com wrote: > > % bash > > $ diff -u \ > > <(openssl ciphers -v ALL:@STRENGTH) \ > > <(openssl ciphers -v aNULL:-aNULL:ALL:@STRENGTH) > ... > > I thought 'NULL' were "a bad thing", and that we shouldn't be using them at > all. Not at all. When not authenticating the peer, there's no point in asking for their certificates. Should bus drivers ask you wave your closed passport in the air, just to make sure you have one and withough looking at its content or which country issued it, when you board a bus? Is it bad that you can board a bus without having a passport? > What I want to get to is to make sure that the "bad" ciphers are NOT > enable/used. The anonymous ciphers are not "bad", with smtp_tls_security_level = may all ciphers are effectively anonymous. Your bus ride is no safer when some or all of the passengers bring their passports on board and wave them in the air as they board the bus. > Since I didn't think we should be using NULL-anything, I expected to see > 'medium' NOT using them at all. TLS combines multiple cryptographic primitives: * Bulk data encryption (medium excludes algorithms weaker than 3-DES and 128-bit RC4) * Data integrity (SHA1, SHA2, ... MACs or AEAD) * Key Exchange (RSA key transport, DHE, ECDHE, ...) * Authentication (Web PKI certificates, PSK, ...) The aNULL ciphers leave out authentication, and make sense for opportunistic TLS when you're otherwise willing to send cleartext. http://www.postfix.org/TLS_README.html#client_tls_levels http://www.postfix.org/TLS_README.html#client_tls_limits http://www.postfix.org/TLS_README.html#client_tls_may https://tools.ietf.org/html/rfc7435 -- Viktor.
Re: why use "aNULL:!aNULL:" in Postfix default cipherlists?
On Sat, Apr 9, 2016, at 01:16 PM, Viktor Dukhovni wrote: > Is it bad that you can board a bus without having a passport? Since you're going to torture me with a metaphor ;-) I'll answer : It depends. But I DO know that dutifully skimming the scum off the top of a pot of boiling stock DEFINITELY results in a cleaner broth. (now my head hurts) > The anonymous ciphers are not "bad", with > > smtp_tls_security_level = may > > all ciphers are effectively anonymous. I think this may be where I'm confusing myself. Since (from other thread) I'm looking at whether or not I should -- or can, in today's world -- be using smtp_tls_security_level = must smtpd_tls_security_level = must Yeah I know one frequent answer is "just leave the Postfix defaults in place", but then you don't actually learn /understanding anything. > Your bus ride is no safer > when some or all of the passengers bring their passports on board > and wave them in the air as they board the bus. Well, at least then you can see their hands! ;-p > TLS combines multiple cryptographic primitives: cryptographic primitives? (mathematicians with spears?) > * Bulk data encryption (medium excludes algorithms weaker than > 3-DES and 128-bit RC4) > * Data integrity (SHA1, SHA2, ... MACs or AEAD) > * Key Exchange (RSA key transport, DHE, ECDHE, ...) > * Authentication (Web PKI certificates, PSK, ...) > > The aNULL ciphers leave out authentication, and make sense for > opportunistic TLS when you're otherwise willing to send cleartext. > > http://www.postfix.org/TLS_README.html#client_tls_levels > http://www.postfix.org/TLS_README.html#client_tls_limits > http://www.postfix.org/TLS_README.html#client_tls_may > https://tools.ietf.org/html/rfc7435 Like I said, I really need to reread all this stuff. It makes sens to you, obviously, but afaict you WRITE this stuff! Thanks Jason
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
On Sat, Apr 09, 2016 at 08:46:54AM -0700, jaso...@mail-central.com wrote: > I'm setting up mandatory TLS policy for a couple of private client servers, > using > > - smtpd_tls_security_level = may > + smtpd_tls_security_level = encrypt > > I started wondering whether it wouldn't be a bad thing to require > ALL email delivered to my server, from anywhere, to use TLS. Your server, your rules, but be prepared to refuse a lot of legitimate email. https://www.google.com/transparencyreport/saferemail/ https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security -- Viktor.
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
On Sat, Apr 9, 2016, at 02:02 PM, Viktor Dukhovni wrote: > Your server, your rules, but be prepared to refuse a lot of legitimate > email. True, but that's neither my point, nor my goal. And, THESE (sadly, neither of which I've seen) > https://www.google.com/transparencyreport/saferemail/ > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf > > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security are great! resources. stats! For me, those mean "= may" remains for now. Thanks Jason
Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?
On Wed, Apr 6, 2016, at 11:49 AM, jaso...@mail-central.com wrote: > If it's seeing the 550, how can I stop exposing/reporting back "from > MTA(smtp:[127.0.0.1]:13002):" ? If it's just internal to my setup, then I > don't care. It's definitely being reported back to the sender. : host mail01.example.com[192.0.2.20] said: 550 5.7.1 id=14949-01 - Rejected by next-hop MTA on relaying, from MTA(smtp:[127.0.0.1]:13002): 550 5.7.1 (in reply to end of DATA command) And I *finally* found the source of the message. It's amavis amavisd.conf-default # %smtp_reason_by_ccat = ( # # currently only used for blocked messages only, status 5xx # # a multiline message will produce a valid multiline SMTP response ... # CC_MTA.',1','id=%n - Temporary MTA failure on relaying', >>> # CC_MTA.',2','id=%n - Rejected by next-hop MTA on >>> relaying', # CC_MTA, 'id=%n - Unable to relay message back to MTA', ... # ); So far though I haven't figure out what I can DO about it. There's this thread Re: [AMaViS-user] Amavis should not send DSN if D_REJECT is active https://sourceforge.net/p/amavis/mailman/message/23018531/ that originally made it possible to REJECT. That's not the problem, though. It's that that REJECT is making it back out to the sender. In my amavisd.conf if I change %smtp_reason_by_ccat = ( CC_MTA.',2','JUNK', ); I get just : host mail01.example.com[192.0.2.20] said: 550 5.7.1 JUNK, from MTA(smtp:[127.0.0.1]:13002): 550 5.7.1 (in reply to end of DATA command) where that from MTA(smtp:[127.0.0.1]:13002) is still there. I think that's "in postfix". Looking around to see. Jason
Re: rate limiting bad-bot HANGUPs in postscreen?
jaso...@mail-central.com: > conitinues on for a total of (in this case) 237 attempts in one > continuous string over a few minutes. All connections are blocked after 0.1 second, as the client fails both the DNSBL and the pregreet tests. At one connection per second, this uses very few resources, so I would not worry about this. It's certainly not worth complicating postscreen. Wietse
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
Would a guru comment on my "interpretation" of these documents? 1) It looks to me that starttls really only protects the path to the first server. Classic case being sending email over the non-secure coffee shop wifi. 2) Mail between Google/yahoo servers will enforce TLS, but other transit may not? My view of starttls email is this. At best, you only protect the endpoints. The snail mail analogy is you leave a message in an envelope for the mail carrier. That message makes it to the post office in the envelope. As the mail transits between post offices, some of those non-postal carriers may remove your envelope. The destination post office, should it find your message lacking an envelope, puts your message in another envelope, then delivers it. 3) I reviewed the DMARC. All my accounts have functional spf and dkim. If I set DMARC to quarantine, will my email at least be delivered? I've looked at dnssec, but it seems like I need a 2nd server to make it work. If not, can someone provide what they consider a good link on the topic? My understanding is only pgp or s/mime has end to end encryption. Original Message From: Viktor Dukhovni Sent: Saturday, April 9, 2016 2:03 PM To: postfix-users@postfix.org Reply To: postfix-users@postfix.org Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS? On Sat, Apr 09, 2016 at 08:46:54AM -0700, jaso...@mail-central.com wrote: > I'm setting up mandatory TLS policy for a couple of private client servers, > using > > - smtpd_tls_security_level = may > + smtpd_tls_security_level = encrypt > > I started wondering whether it wouldn't be a bad thing to require > ALL email delivered to my server, from anywhere, to use TLS. Your server, your rules, but be prepared to refuse a lot of legitimate email. https://www.google.com/transparencyreport/saferemail/ https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security -- Viktor.
Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?
On Sat, Apr 9, 2016, at 02:25 PM, jaso...@mail-central.com wrote: > I think that's "in postfix". Looking around to see. is the issue of changing ... MTA(smtp:[127.0.0.1]:13002) ... to something descriptive that I specify ... MTA(my_internal_server_A) ... a matter of http://www.postfix.org/ADDRESS_REWRITING_README.html ? Can it be changed at all? Jason
Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?
jaso...@mail-central.com: > > > On Sat, Apr 9, 2016, at 02:25 PM, jaso...@mail-central.com wrote: > > I think that's "in postfix". Looking around to see. > > is the issue of changing > > ... MTA(smtp:[127.0.0.1]:13002) ... Who cares? No-one can connect to this from outside. But, if you must, see $ man 5 postconf | less +/'^smtp_reply_filter' This feature is available in Postfix 2.7. Wietse
Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?
On Sat, Apr 9, 2016, at 05:40 PM, Wietse Venema wrote: > Who cares? Obviously you don't. But I do. That's why I'm asking. That's good enough for me. > No-one can connect to this from outside. That's correct. Not currently, to this current machine/port, in this configuration. > But, if you must, see 'must'? > $ man 5 postconf | less +/'^smtp_reply_filter' > > This feature is available in Postfix 2.7. There, that wasn't so hard. And thanks. Jason
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
In message <20160409230701.5468245.39956@lazygranch.com> li...@lazygranch.com writes: > > Would a guru comment on my "interpretation" of these documents? Not a guru but ... > 1) It looks to me that starttls really only protects the path to the >first server. Classic case being sending email over the non-secure >coffee shop wifi. If you are using TLS to port 587 then that is protecting the first hop. If both your MUA (email app) and the MSA (mail submission agent) you are talking to insist on using TLS and have some means to mutually authenticate (such as either a client cert or mutual_auth in postfix on the MSA end), then this is subject to MITM. Postfix does not support validating the client cert (AFAIK - not a guru I said). There is really no name to validate the client cert against, other than the hostname provided in the EHLO. For the MSA that could be useful or the MSA could have a sender to name to validate mapping and CAfile to use. In principle, IMAP servers could do the same. But I don't think there is much demand for that. It would mean getting clients to put certs in the MUA. The point of the article is that unless both ends insist on TLS then MITM is possible. There is a lot of discussion of STARTTLS stripping. There was not discussion of TLS downgrade attacks but those are not as easy as STARTTLS stripping. The focus of the paper was on the use of TLS between the MSA and the MX of the destination domain (an MTA - mail transfer agent). That is usually the next hop. > 2) Mail between Google/yahoo servers will enforce TLS, but other >transit may not? My view of starttls email is this. At best, you >only protect the endpoints. Google, yahoo, and many others offer STARTTLS. None require that you use TLS or check a client cert. > The snail mail analogy is you leave a message in an envelope for the > mail carrier. That message makes it to the post office in the > envelope. As the mail transits between post offices, some of those > non-postal carriers may remove your envelope. The destination post > office, should it find your message lacking an envelope, puts your > message in another envelope, then delivers it. Sort of. More like if each post office always removed the envelope and put your mail in a new one before sending to the next post office, sometime a transparent envelope. > 3) I reviewed the DMARC. All my accounts have functional spf and >dkim. If I set DMARC to quarantine, will my email at least be >delivered? No. I will be held and you (or some email address that is indicated in the DMARC record) will be notified that mail for that domain is held - typically in a daily summary for the domain. > I've looked at dnssec, but it seems like I need a 2nd server to make > it work. If not, can someone provide what they consider a good link on > the topic? You need to sign you domain RRs and then go to your domain registrar and ask that a DS record be added for your domain. In that order. http://www.internetsociety.org/deploy360/dnssec/ http://www.internetsociety.org/deploy360/home/content-providers/dnssec/ http://dnssec-debugger.verisignlabs.com/ https://www.dnssec-tools.org/test/ The last one has a link to a tutorial. Also regarding DANE: http://www.internetsociety.org/deploy360/resources/dane/ http://dane.verisignlabs.com/ https://dane.sys4.de https://dane.sys4.de/common_mistakes > My understanding is only pgp or s/mime has end to end encryption. Correct. SMTP TLS is not end-to-end. Of course to encrypt using pgp or s/mime both ends must support pgp or s/mime which has been a problem. People within various communities of interest use pgp or s/mime (for example, the security community) but use is very sparse. Curtis > > Original Message > > From: Viktor Dukhovni > > Sent: Saturday, April 9, 2016 2:03 PM > > To: postfix-users@postfix.org > > Reply To: postfix-users@postfix.org > > Subject: Re: reality-check on 2016 practical advice re: requiring inbound > > TLS? > > > > On Sat, Apr 09, 2016 at 08:46:54AM -0700, jaso...@mail-central.com wrote: > > > > > I'm setting up mandatory TLS policy for a couple of private client > > > servers, using > > > > > > - smtpd_tls_security_level = may > > > + smtpd_tls_security_level = encrypt > > > > > > I started wondering whether it wouldn't be a bad thing to require > > > ALL email delivered to my server, from anywhere, to use TLS. > > > > Your server, your rules, but be prepared to refuse a lot of legitimate > > email. > > > > https://www.google.com/transparencyreport/saferemail/ > > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf > > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security > > > > -- > > Viktor.
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
In message <20160409210245.gs26...@mournblade.imrryr.org> Viktor Dukhovni writes: > > On Sat, Apr 09, 2016 at 08:46:54AM -0700, jaso...@mail-central.com wrote: > > > I'm setting up mandatory TLS policy for a couple of private client > > servers, using > > > > - smtpd_tls_security_level = may > > + smtpd_tls_security_level = encrypt > > > > I started wondering whether it wouldn't be a bad thing to require > > ALL email delivered to my server, from anywhere, to use TLS. > > Your server, your rules, but be prepared to refuse a lot of legitimate > email. A review of maillogs would tell you how much would get tossed. I've been doing some work with automated parse of logs. If I look at that (including TLS mail rejected by postscreen vs in-the-clear mail rejected by postscreen) I'll let you know. > https://www.google.com/transparencyreport/saferemail/ > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf > > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security > > -- > Viktor. Thanks for the links. I emailed one of the authors asking why so little was said about DNSSEC and nothing at all about DANE. Curtis
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
I'm going to set the DMARC to quarantine and see what happens. I suppose I can always undo the DMARC to none. Regarding dnssec, my registrar is Hover. Their faq is mighty convoluted since they provide a DNS server, though I use the one provided by Digital Ocean. Best to just get in a chat with hover and DO. Original Message From: Curtis Villamizar Sent: Saturday, April 9, 2016 6:32 PM To: li...@lazygranch.com Reply To: Curtis Villamizar Cc: Viktor Dukhovni Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS? In message <20160409230701.5468245.39956@lazygranch.com> li...@lazygranch.com writes: > > Would a guru comment on my "interpretation" of these documents? Not a guru but ... > 1) It looks to me that starttls really only protects the path to the > first server. Classic case being sending email over the non-secure > coffee shop wifi. If you are using TLS to port 587 then that is protecting the first hop. If both your MUA (email app) and the MSA (mail submission agent) you are talking to insist on using TLS and have some means to mutually authenticate (such as either a client cert or mutual_auth in postfix on the MSA end), then this is subject to MITM. Postfix does not support validating the client cert (AFAIK - not a guru I said). There is really no name to validate the client cert against, other than the hostname provided in the EHLO. For the MSA that could be useful or the MSA could have a sender to name to validate mapping and CAfile to use. In principle, IMAP servers could do the same. But I don't think there is much demand for that. It would mean getting clients to put certs in the MUA. The point of the article is that unless both ends insist on TLS then MITM is possible. There is a lot of discussion of STARTTLS stripping. There was not discussion of TLS downgrade attacks but those are not as easy as STARTTLS stripping. The focus of the paper was on the use of TLS between the MSA and the MX of the destination domain (an MTA - mail transfer agent). That is usually the next hop. > 2) Mail between Google/yahoo servers will enforce TLS, but other > transit may not? My view of starttls email is this. At best, you > only protect the endpoints. Google, yahoo, and many others offer STARTTLS. None require that you use TLS or check a client cert. > The snail mail analogy is you leave a message in an envelope for the > mail carrier. That message makes it to the post office in the > envelope. As the mail transits between post offices, some of those > non-postal carriers may remove your envelope. The destination post > office, should it find your message lacking an envelope, puts your > message in another envelope, then delivers it. Sort of. More like if each post office always removed the envelope and put your mail in a new one before sending to the next post office, sometime a transparent envelope. > 3) I reviewed the DMARC. All my accounts have functional spf and > dkim. If I set DMARC to quarantine, will my email at least be > delivered? No. I will be held and you (or some email address that is indicated in the DMARC record) will be notified that mail for that domain is held - typically in a daily summary for the domain. > I've looked at dnssec, but it seems like I need a 2nd server to make > it work. If not, can someone provide what they consider a good link on > the topic? You need to sign you domain RRs and then go to your domain registrar and ask that a DS record be added for your domain. In that order. http://www.internetsociety.org/deploy360/dnssec/ http://www.internetsociety.org/deploy360/home/content-providers/dnssec/ http://dnssec-debugger.verisignlabs.com/ https://www.dnssec-tools.org/test/ The last one has a link to a tutorial. Also regarding DANE: http://www.internetsociety.org/deploy360/resources/dane/ http://dane.verisignlabs.com/ https://dane.sys4.de https://dane.sys4.de/common_mistakes > My understanding is only pgp or s/mime has end to end encryption. Correct. SMTP TLS is not end-to-end. Of course to encrypt using pgp or s/mime both ends must support pgp or s/mime which has been a problem. People within various communities of interest use pgp or s/mime (for example, the security community) but use is very sparse. Curtis > > Original Message > > From: Viktor Dukhovni > > Sent: Saturday, April 9, 2016 2:03 PM > > To: postfix-users@postfix.org > > Reply To: postfix-users@postfix.org > > Subject: Re: reality-check on 2016 practical advice re: requiring inbound > > TLS? > > > > On Sat, Apr 09, 2016 at 08:46:54AM -0700, jaso...@mail-central.com wrote: > > > > > I'm setting up mandatory TLS policy for a couple of private client > > > servers, using > > > > > > - smtpd_tls_security_level = may > > > + smtpd_tls_security_level = encrypt > > > > > > I started wondering whether it wouldn't be a bad thing to require > > > ALL email delivered to my server, from anywhere, to use TLS. > > > > Your server, your rules, but be prepared
Re: rate limiting bad-bot HANGUPs in postscreen?
In message <1460213048.1937714.573722321.23756...@webmail.messagingengine.com> jaso...@mail-central.com writes: > With postscreen in place, bad bots arr getting fended off. > > Many give up and go away after a couple of tries. > > Some, these days mostly 'ymlf-pc' bots, are more persistent. > > Eg, this one > > Apr 8 04:17:20 mail01 postfix/postscreen[20412]: CONNECT from > [37.49.226.17]:52066 to [192.0.2.17]:25 > Apr 8 04:17:20 mail01 postfix/dnsblog[20417]: addr 37.49.226.17 listed > by domain zen.spamhaus.org as 127.0.0.4 > Apr 8 04:17:21 mail01 postfix/postscreen[20412]: PREGREET 14 after > 0.14 from [37.49.226.17]:52066: EHLO ylmf-pc\r\n > Apr 8 04:17:21 mail01 postfix/postscreen[20412]: DNSBL rank 6 for > [37.49.226.17]:52066 > Apr 8 04:17:21 mail01 postfix/postscreen[20412]: HANGUP after 0.85 > from [37.49.226.17]:52066 in tests after SMTP handshake > Apr 8 04:17:21 mail01 postfix/postscreen[20412]: DISCONNECT > [37.49.226.17]:52066 > Apr 8 04:17:22 mail01 postfix/postscreen[20412]: CONNECT from > [37.49.226.17]:54974 to [192.0.2.17]:25 > Apr 8 04:17:22 mail01 postfix/dnsblog[20415]: addr 37.49.226.17 listed > by domain zen.spamhaus.org as 127.0.0.4 > Apr 8 04:17:22 mail01 postfix/postscreen[20412]: PREGREET 14 after > 0.15 from [37.49.226.17]:54974: EHLO ylmf-pc\r\n > Apr 8 04:17:22 mail01 postfix/postscreen[20412]: DNSBL rank 6 for > [37.49.226.17]:54974 > Apr 8 04:17:23 mail01 postfix/postscreen[20412]: HANGUP after 0.77 > from [37.49.226.17]:54974 in tests after SMTP handshake > Apr 8 04:17:23 mail01 postfix/postscreen[20412]: DISCONNECT > [37.49.226.17]:54974 > Apr 8 04:17:25 mail01 postfix/postscreen[20412]: CONNECT from > [37.49.226.17]:58871 to [192.0.2.17]:25 > ... > > conitinues on for a total of (in this case) 237 attempts in one continuous > string over a few minutes. > > These do not appear as multiple CONCURRENT connection, which I think I can > limit with ' postscreen_client_connection_count_limit'. > > Instead, they look like SEQUENTIAL connections. > > IIUC, this is a pretty efficient disconnection by postscreen, so not a huge > load on the server. > > But, it's still making connections. > > I can rate limit these in fail2ban+firewall (e.g., > http://shorewall.net/ConnectionRate.html), but would prefer to keep this > re-action in Postfix. > > Is there a postscreen_ parameter to rate limit these "bursts"? Maybe dropping > the connection sooner? > > Jason Jason, An excerpt below from a shell script to generate a access file for postscreen. I haven't automated running it but will probably zcat a day or two of prior maillog files plus the current day (for example, using "zcat /var/log/maillog.0.bz2 | cat - /var/log/maillog | ..."). It gets rid of lots of PREGREET or HANGUP in under 1 sec. The threshhold of 5 is quite low but I don't think it will catch any legit mail servers. Still playing with this. Note that the big space before reject is three tabs. Curtis echo "# HANGUP after <1 more than 5 times in one day" grep postfix/postscreen /var/log/maillog \ | grep 'HANGUP after 0\.' \ | sed -e 's,^.*HANGUP after [0-9\.]* from ,,' \ -e 's,:[0-9]* in tests after SMTP handshake$,,' \ | sort | uniq -c | sort -n \ | egrep '^ *[6-9] |^ *[1-9][0-9][0-9]* ' \ | sed -e 's,^ *[0-9]* *\[,,' -e 's,\]$, reject,' echo "# PREGREET after <1 more than 5 times" grep postfix/postscreen /var/log/maillog \ | grep 'PREGREET [0-9]* after 0\.[0-9]* ' \ | sed -e 's,^.*PREGREET [0-9]* after 0\.[0-9]* from ,,' \ -e 's,:[0-9]*: [HE]*LO .*,,' \ | sort | uniq -c | sort -n \ | egrep '^ *[6-9] |^ *[1-9][0-9][0-9]* ' \ | sed -e 's,^ *[0-9]* *\[,,' -e 's,\]$, reject,'
Re: rate limiting
In message <5707263d.7000...@caseyconnor.org> Casey Connor writes: > > Thank you -- will it accept decimal seconds? > > We are sending on the order of 50-200+ messages per second in this > stress test, so the delay between messages could be smaller than .005 > seconds. If you are trying to simulate a very busy mailserver, then you should be concerned about connections to it from multiple hosts per second most sending one or a few messages and a realistic test would have to have a nominal TCP RTT in the range of a few to a few 10s of msec since the speed of light is limited and geographic delays come into play. I've been involved in testing and some simulation of this type but on routers and various switchy-thingies rather than mailservers. Curtis > On 04/07/2016 06:19 PM, Wietse Venema wrote: > > See: > > http://www.postfix.org/postconf.5.html#default_transport_rate_delay > > http://www.postfix.org/postconf.5.html#default_destination_rate_delay > > > > The names are similar but things work differently. > > > > Wietse
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
On Sat, Apr 09, 2016 at 09:36:09PM -0400, Curtis Villamizar wrote: > > https://www.google.com/transparencyreport/saferemail/ > > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf > > > > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security > > Thanks for the links. I emailed one of the authors asking why so > little was said about DNSSEC and nothing at all about DANE. https://www.ietf.org/mail-archive/web/uta/current/msg01458.html https://www.youtube.com/watch?v=36WDbfKEIRI (final minutes of Q&A) https://www.ietf.org/mail-archive/web/uta/current/msg01459.html Short version from my perspective: The authors seem to have STS/WebPKI tunnel-vision and appear to be buying the party line that DNSSEC is too difficult to deploy, while underestimating the deployment timescale for STS. STS can only be deployed quickly between the handful of large providers, and, on that scale, they have simpler means to exchange the same data without new complex protocols. This is of course much faster than deploying DANE for a substantial fraction of the Internet. Deployment of STS for the Internet at large is unlikely to be much faster than doing DANE at the same scale, and DANE is less kludgey in this space. That said, we may well support both at some point, when STS becomes stable enough. It need not be an either/or story. -- Viktor.
Re: rate limiting
Thanks, Curtis. We have taken all that in to consideration. I'll spare you the long story, but we are testing somewhat specific things. :-) -c If you are trying to simulate a very busy mailserver, then you should be concerned about connections to it from multiple hosts per second most sending one or a few messages and a realistic test would have to have a nominal TCP RTT in the range of a few to a few 10s of msec since the speed of light is limited and geographic delays come into play. I've been involved in testing and some simulation of this type but on routers and various switchy-thingies rather than mailservers. Curtis
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
On Sat, Apr 09, 2016 at 09:31:48PM -0400, Curtis Villamizar wrote: > > 1) It looks to me that starttls really only protects the path to the > >first server. Classic case being sending email over the non-secure > >coffee shop wifi. > > If you are using TLS to port 587 then that is protecting the first > hop. If both your MUA (email app) and the MSA (mail submission agent) > you are talking to insist on using TLS and have some means to mutually > authenticate (such as either a client cert or mutual_auth in postfix > on the MSA end), then this is subject to MITM. Postfix does not > support validating the client cert (AFAIK - not a guru I said). This is wrong. > There is really no name to validate the client cert against, other > than the hostname provided in the EHLO. Submission clients are usually authenticated via SASL, and while that does not provide "channel binding", it is good enough in practice, if the client properly authenticates the server. > The point of the article is that unless both ends insist on TLS then > MITM is possible. The topic of the articles is TLS between email relays, not MUA to submission or IMAP client to IMAP srever. MITM is possible when SMTP relays (sending MTAs) don't (and generally can't even if they wanted to) authenticate the nexthop MTA. > The focus of the paper was on the use of TLS between the MSA and the > MX of the destination domain (an MTA - mail transfer agent). That is > usually the next hop. No, the topic was relay-to-relay SMTP, TLS is much more prevalent with submission and IMAP and generally works adequately with WebPKI. -- Viktor.
gmail servers requiring postscreen_access whitelisting
Since I enabled postscreen (with soft_bounce=yes in master.cf) I was getting logs of this form: Apr 9 01:08:12 mta1 postfix/postscreen[18326]: NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999: 450 4.3.2 Service currently unavailable; from=, to=, proto=ESMTP, helo= linefeeds added by me for readability. gmail would just keep trying a half hour later and mail never gets delivered. rfc3463 isn't very helpful: X.3.2 System not accepting network messages The host on which the mailbox is resident is not accepting messages. Examples of such conditions include an immanent shutdown, excessive load, or system maintenance. This is useful for both permanent and permanent transient errors. I have lines of the form: main.cf: postscreen_access_list = cidr:$config_directory/postscreen_access hash:$config_directory/postscreen_reject postscreen_access: # google mail servers 2607:f8b0:4002:c00::/60 permit [... other google server blocks ...] This is a workaround that shouldn't be needed. Any idea what the cause of this is? So far no legit mail except gmail gets caught here. Curtis
Re: gmail servers requiring postscreen_access whitelisting
On 4/9/2016 10:00 PM, Curtis Villamizar wrote: > Since I enabled postscreen (with soft_bounce=yes in master.cf) I was > getting logs of this form: > > Apr 9 01:08:12 mta1 postfix/postscreen[18326]: > NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999: > 450 4.3.2 Service currently unavailable; > from=, to=, > proto=ESMTP, helo= > > linefeeds added by me for readability. > > gmail would just keep trying a half hour later and mail never gets > delivered. > > rfc3463 isn't very helpful: > > X.3.2 System not accepting network messages > > The host on which the mailbox is resident is not accepting > messages. Examples of such conditions include an immanent > shutdown, excessive load, or system maintenance. This is > useful for both permanent and permanent transient errors. > > I have lines of the form: > > main.cf: > postscreen_access_list = > cidr:$config_directory/postscreen_access > hash:$config_directory/postscreen_reject > > postscreen_access: > # google mail servers > 2607:f8b0:4002:c00::/60 permit > [... other google server blocks ...] > > This is a workaround that shouldn't be needed. > > Any idea what the cause of this is? So far no legit mail except gmail > gets caught here. > > Curtis > Look for other warnings and errors in your logs, maybe just before the reject, maybe earlier. -- Noel Jones
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
One interesting take away is that the corporate email servers were less likely to have SPF and DKIM in use. On the weekends, more email was sent from home users who tended to use Google, Hotmail, etc., which did use SPF and DKIM. I will admit my original intent on getting SPF and DKIM was to get a good score from SpamAssassin. You would think corporate emailers would want this as well. This went out on hacker news a few days ago : https://news.ycombinator.com/item?id=11396089 Original Message From: Viktor Dukhovni Sent: Saturday, April 9, 2016 7:42 PM To: postfix-users@postfix.org Reply To: postfix-users@postfix.org Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS? On Sat, Apr 09, 2016 at 09:36:09PM -0400, Curtis Villamizar wrote: > > https://www.google.com/transparencyreport/saferemail/ > > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf > > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security > > Thanks for the links. I emailed one of the authors asking why so > little was said about DNSSEC and nothing at all about DANE. https://www.ietf.org/mail-archive/web/uta/current/msg01458.html https://www.youtube.com/watch?v=36WDbfKEIRI (final minutes of Q&A) https://www.ietf.org/mail-archive/web/uta/current/msg01459.html Short version from my perspective: The authors seem to have STS/WebPKI tunnel-vision and appear to be buying the party line that DNSSEC is too difficult to deploy, while underestimating the deployment timescale for STS. STS can only be deployed quickly between the handful of large providers, and, on that scale, they have simpler means to exchange the same data without new complex protocols. This is of course much faster than deploying DANE for a substantial fraction of the Internet. Deployment of STS for the Internet at large is unlikely to be much faster than doing DANE at the same scale, and DANE is less kludgey in this space. That said, we may well support both at some point, when STS becomes stable enough. It need not be an either/or story. -- Viktor.
Re: False positives from header_checks
On 4/9/2016 8:00 AM, Wietse Venema wrote: > Unfortunately, I don't have time to decode this discussion. Can > someone post a tested diff, someone maybe post a revised version, > and when there is agreement, then I can adopt it. > > Wietse > Does someone have a full, unmodified offending header to post so this can be tested?
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
In message <20160410024851.gu26...@mournblade.imrryr.org> Viktor Dukhovni writes: > On Sat, Apr 09, 2016 at 09:31:48PM -0400, Curtis Villamizar wrote: > > > > 1) It looks to me that starttls really only protects the path to the > > >first server. Classic case being sending email over the non-secure > > >coffee shop wifi. > > > > If you are using TLS to port 587 then that is protecting the first > > hop. If both your MUA (email app) and the MSA (mail submission agent) > > you are talking to insist on using TLS and have some means to mutually > > authenticate (such as either a client cert or mutual_auth in postfix > > on the MSA end), then this is subject to MITM. Postfix does not > > support validating the client cert (AFAIK - not a guru I said). > > This is wrong. Can you say what is wrong. Let me paraphrase and expand a bit. mutual_auth implies you are using SASL. With Opportunistic TLS without SASL in postfix you have no authentication. With TLS but with SASL plaintext you provide a MITM a means to read your password. The simplest MITM is STARTTLS stripping. If the client end doesn't insist on TLS, then STARTTLS stripping is possible. The client TCP connection can be terminated at the MITM as plain text and a TLS to the MSA can be started. In both connections the IP address can be spoofed if the MITM is in the routing middle (or acting as a L2 bridge). If both ends insist on TLS but are willing to settle for SSL, then a MITM is still possible with a TLS downgrade (but harder to do). If both ends insist on TLS and not SSL but there is no client cert and no way to tell what the client should be signing for or no CAfile to check against then a MITM is possible if a rouge CA is used (which is likely going to be a nation surveilance situation). Postfix does not support validating the client cert. Which of these are wrong? OK to pick more than one. :-) Seriously, I did say I'm not an expert. > > There is really no name to validate the client cert against, other > > than the hostname provided in the EHLO. > > Submission clients are usually authenticated via SASL, and while > that does not provide "channel binding", it is good enough in > practice, if the client properly authenticates the server. mutual_auth implies you are using SASL and with or without TLS it helps with MITM, but safe with TLS. mutual_auth such as SCRAM (or GSSAPI) are reasonably good and MITM resistant. > > The point of the article is that unless both ends insist on TLS then > > MITM is possible. > > The topic of the articles is TLS between email relays, not MUA to > submission or IMAP client to IMAP srever. > > MITM is possible when SMTP relays (sending MTAs) don't (and generally > can't even if they wanted to) authenticate the nexthop MTA. This statement was independent on MUA->MSA or MSA->MX which is a form of MTA->MTA. > > The focus of the paper was on the use of TLS between the MSA and the > > MX of the destination domain (an MTA - mail transfer agent). That is > > usually the next hop. > > No, the topic was relay-to-relay SMTP, TLS is much more prevalent > with submission and IMAP and generally works adequately with WebPKI. Sorry. We are saying the same thing here but I was keeping with MUA->MSA or MSA->MX since explaining to someone that possibly didn't know any of these terms. And MSA->MX is a form of MTA->MTA. To be pedantic, the focus of the paper is on MTA->MTA where the two MTA are in different domains. > -- > Viktor. I defer to you as an expert on this but I would like to know what is wrong in the "this is wrong" comment. Curtis
Re: reality-check on 2016 practical advice re: requiring inbound TLS?
On Sat, Apr 09, 2016 at 08:32:10PM -0700, li...@lazygranch.com wrote: > One interesting take away is that the corporate email servers were less > likely to have SPF and DKIM in use. On the weekends, more email was sent > from home users who tended to use Google, Hotmail, etc., which did use > SPF and DKIM. I suspect that's not the whole story, if you look at the weekend peaks and troughs before Gmail started displaying a transport security indication for delivered mail, you'll see that the gap between the two was much higher than it is now. You'll also notice that the mainstream senders of bulk email marketing who are always in the top 20 senders on the transparency page recently went from 0% TLS to 100% TLS. So my take on the numbers is that the commercial mailers make up a larger proportion of email traffic into Gmail on weekdays than on weekends. If it was just or predominantly the difference between corporate and home senders, the size of the weekday dip would not have changed, just the baseline would have moved up. The corporate world does not react to changes of Gmail's user interface within days of those changes. Only the professional email marketers are that agile. -- Viktor.
Re: gmail servers requiring postscreen_access whitelisting
In message <5709c8c8.1050...@megan.vbhcs.org> Noel Jones writes: > On 4/9/2016 10:00 PM, Curtis Villamizar wrote: > > Since I enabled postscreen (with soft_bounce=yes in master.cf) I was > > getting logs of this form: > > > > Apr 9 01:08:12 mta1 postfix/postscreen[18326]: > > NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999: > > 450 4.3.2 Service currently unavailable; > > from=, to=, > > proto=ESMTP, helo= > > > > linefeeds added by me for readability. > > > > gmail would just keep trying a half hour later and mail never gets > > delivered. > > > > rfc3463 isn't very helpful: > > > > X.3.2 System not accepting network messages > > > > The host on which the mailbox is resident is not accepting > > messages. Examples of such conditions include an immanent > > shutdown, excessive load, or system maintenance. This is > > useful for both permanent and permanent transient errors. > > > > I have lines of the form: > > > > main.cf: > > postscreen_access_list = > > cidr:$config_directory/postscreen_access > > hash:$config_directory/postscreen_reject > > > > postscreen_access: > > # google mail servers > > 2607:f8b0:4002:c00::/60 permit > > [... other google server blocks ...] > > > > This is a workaround that shouldn't be needed. > > > > Any idea what the cause of this is? So far no legit mail except gmail > > gets caught here. > > > > Curtis > > Look for other warnings and errors in your logs, maybe just before > the reject, maybe earlier. > > -- Noel Jones This is it for that connections: Apr 9 01:07:15 mta1 postfix/postscreen[18326]: CONNECT from [2607:f8b0:4002:c05::22d]:32999 to [2001:470:88e6:1::141]:25 Apr 9 01:07:18 mta1 postfix/tlsproxy[18331]: CONNECT from [2607:f8b0:4002:c05::22d]:32999 Apr 9 01:08:12 mta1 postfix/tlsproxy[18331]: Untrusted TLS connection established from [2607:f8b0:4002:c05::22d]:32999: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Apr 9 01:08:12 mta1 postfix/postscreen[18326]: NOQUEUE: reject: RCPT from [2607:f8b0:4002:c05::22d]:32999: 450 4.3.2 Service currently unavailable; from=, to=, proto=ESMTP, helo= Apr 9 01:08:12 mta1 postfix/postscreen[18326]: PASS NEW [2607:f8b0:4002:c05::22d]:32999 Apr 9 01:08:12 mta1 postfix/tlsproxy[18331]: DISCONNECT [2607:f8b0:4002:c05::22d]:32999 Apr 9 01:08:12 mta1 postfix/postscreen[18326]: DISCONNECT [2607:f8b0:4002:c05::22d]:32999 The IP address got whitelisted but then the next retry from gmail usually doesn't come from the same IP address and comes 30 minutes later. They seem to have some sort of pool of servers that work on the same set of mail queues. Today I caught 2 gmails where this happenned where I didn't have the block in the permit list but each got delivered on next attempt. I haven't had postscreen enabled long and only for two domain, one currently used only for a web site and therefore available for email testing and the other that is mostly mail to me and gets a fair amount of spam. I now have a non-gmail sender where this happened. In that case after the 450 it went immediately to the secondary MX that at this time is not running postscreen and all was fine. I'll recheck my configs, then post if I can't figure it out. Curtis
