Re: reality-check on 2016 practical advice re: requiring inbound TLS?

On Sun, Apr 10, 2016, at 07:46 PM, Bill Cole wrote: > On a system where you know enough about all your users to know that they > don't want to get critical email from clueless sources, you can make > restrictive choices with no trouble. If you don't actually know that, > choosing to require se

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

On 10 Apr 2016, at 20:00, Curtis Villamizar wrote: Great anecdote of a really bad email setup but ... For a lot of us missing out on Ditech, a specialist in preditory lending, is not a compelling reason not to enable SPF, DKIM and DMARC. The power of a brand shows itself... Whether or not on

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

> On Apr 10, 2016, at 8:49 PM, li...@lazygranch.com wrote: > > I've yet to find email from an actual person that doesn't have DKIM or SPF. I've never emailed you directly. This will be the first time. -- Viktor.

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Then again, the customer service department for an item I ordered has no DKIM. The company is using netsuite.com as a portal.  I suppose I can try to contact their IT... I found another legit emailer with SPF but no DKIM. A corporate user that is using a barracuda service of some sort.  I've y

Re: gmail servers requiring postscreen_access whitelisting

On 11/04/16 11:37, Curtis Villamizar wrote: > btw- I don't think list.dnswl.org is a viable workaround for the post > 220 problem. This just affects the dnsbl score which would already be > zero. The post 220 checks would still be run before putting the gmail > server IP into the temporary whitel

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

In message <500a9284-b549-460d-8207-f52534e09...@billmail.scconsult.com> "Bill Cole" writes: > > On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote: > > > I block on strict FAILs of any if SPF, DKIM or DMARC. *missing* > > support for those is logged, but not - yet - acted on. > > This

Re: gmail servers requiring postscreen_access whitelisting

In message "@lbutlr" writes: > > On Apr 10, 2016, at 10:24 AM, Curtis Villamizar = > wrote: > > postscreen_dnsbl_sites =3D > > list.dnswl.org*-5 > > # followed by some blacklist sites > > It was my understanding that eh the order of test said not matter > because all the dnsbls list

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

On Sun, Apr 10, 2016, at 03:13 PM, Bill Cole wrote: > On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote: > > > I block on strict FAILs of any if SPF, DKIM or DMARC. *missing* > > support for those is logged, but not - yet - acted on. > > as is raising the bar too high on ciphersuites. T

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote: I block on strict FAILs of any if SPF, DKIM or DMARC. *missing* support for those is logged, but not - yet - acted on. This is dangerous, as is raising the bar too high on ciphersuites. Case in point: Ditech is one of the largest mortg

Re: False positives from header_checks

Bill Cole: > On 9 Apr 2016, at 9:00, 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. > > > Simplest fix: prevent *that* class of

Re: bad.psky.me RBL?

When this question first arrived, I mediated on why would anyone even bother to set up a RBL these days, as if there aren't enough players. Some do charge for the service if you are a large volume user, but to charge you do need a track record to prove your worth. RBL seems like a not so profita

Re: False positives from header_checks

On 9 Apr 2016, at 9:00, 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. Simplest fix: prevent *that* class of false positives by narrowing t

Re: gmail servers requiring postscreen_access whitelisting

@lbutlr: > On Apr 10, 2016, at 10:24 AM, Curtis Villamizar = > wrote: > > postscreen_dnsbl_sites =3D > > list.dnswl.org*-5 > > # followed by some blacklist sites > > It was my understanding that eh the order of test said not matter = > because all the dnsbls listed would be checked, a

Re: gmail servers requiring postscreen_access whitelisting

On Apr 10, 2016, at 10:24 AM, Curtis Villamizar wrote: > postscreen_dnsbl_sites = > list.dnswl.org*-5 > # followed by some blacklist sites It was my understanding that eh the order of test said not matter because all the dnsbls listed would be checked, a final score computed, and the

Re: Improving / fixing my helo_access restriction matches?

On 8 Apr 2016, at 11:22, /dev/rob0 wrote: EHLO outbound-42.compuserv.com Yes, compuserv is gone, but it's a nice illustration of how the string, "user", can appear in a legitimate EHLO. Tangent: CompuServe was indeed bought by AOL via WorldCom and eventually (just a few years ago... ) all th

Re: bad.psky.me RBL?

On 6 Apr 2016, at 10:48, Quanah Gibson-Mount wrote: Is anyone familiar with this RBL and its quality? Not a whole lot of info at . Terms seem probably ok . Not trustable: in blackhat vs. whitehat terms: nowhere to put a hat) 1. Not clea

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

In message <3qjzc32dcxzj...@spike.porcupine.org> Wietse Venema writes: > > > > No-one can connect to this from outside. > > > > That's correct. Not currently, to this current machine/port, in > > this configuration. > > If someone can connect from outside to your 127.0.0.1 port, then > you hav

Re: gmail servers requiring postscreen_access whitelisting

In message <570a341b.9000...@pajamian.dhs.org> Peter writes: > > On 10/04/16 15:00, Curtis Villamizar wrote: > > 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. > > gmail uses hundreds, or thousa

Re: gmail servers requiring postscreen_access whitelisting

In message <3qjz5d5s15zj...@spike.porcupine.org> Wietse Venema writes: > > Curtis Villamizar: > > 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

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

On Sun, Apr 10, 2016, at 06:42 AM, Wietse Venema wrote: > > > No-one can connect to this from outside. > > > > That's correct. Not currently, to this current machine/port, in > > this configuration. > > If someone can connect from outside to your 127.0.0.1 port, then > you have a serious infra

Re: what error is being reported back to sender, and how to avoid reporting back internal server ports?

> > No-one can connect to this from outside. > > That's correct. Not currently, to this current machine/port, in > this configuration. If someone can connect from outside to your 127.0.0.1 port, then you have a serious infrastructure problem. Wietse

Re: gmail servers requiring postscreen_access whitelisting

Curtis Villamizar: > 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=, >

Re: gmail servers requiring postscreen_access whitelisting

On Sat, Apr 09, 2016 at 11:00:53PM -0400, Curtis Villamizar wrote: > Any idea what the cause of this is? So far no legit mail except gmail > gets caught here. Don't use after-greeting tests in postscreen. The postscreen documentation explains exactly why this happens. Bastian -- "What

Re: gmail servers requiring postscreen_access whitelisting

On 10/04/16 15:00, Curtis Villamizar wrote: > 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. gmail uses hundreds, or thousands of MTAs and has the unique property that when they retry after a deferral i