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:

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

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

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

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

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

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,

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

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

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 > > > >

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

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.

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

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 =

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

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

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,

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

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

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,

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.

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/

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

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

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

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.

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 = >

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

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

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

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,

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.

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

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