subject:"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?

2016-04-09 Thread jasonsu

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

2016-04-09 Thread jasonsu



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: 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: reality-check on 2016 practical advice re: requiring inbound TLS?

2016-04-09 Thread Curtis Villamizar

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?

2016-04-09 Thread Curtis Villamizar

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 =

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

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: reality-check on 2016 practical advice re: requiring inbound TLS?

2016-04-09 Thread Curtis Villamizar

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: reality-check on 2016 practical advice re: requiring inbound TLS?

2016-04-10 Thread Bill Cole


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 mortgage servicing companies 
in the US, servicing millions of loans ultimately held by the federal 
government. They send email responses to customer service inquiries out 
via Microsoft's Office365 service, which signs it for the 
"gtservicing.onmicrosoft.com" domain, but has it routed through Cisco 
(formerly Ironport's) "iphmx.com" infrastructure for no visible reason, 
where the From header is apparently re-written to 
, breaking the DKIM signature. While the 
iphmx.com machines accept mail from Microsoft using the suboptimal 
AES256-SHA ciphersuite, they inexplicably use the affirmatively weak 
TLSv1/RC4-SHA to pass it along. Because of this arcane routing, the 
envelope sender (donotre...@gtservicing.com) has a domain with an SPF 
record that is invalid due to its excessive complexity. Topping this 
off, their messages consistently contain nothing but a bunch of 
disclaimer boilerplate plus a link to the REAL message (which thankfully 
is also usually low-content boilerplate) in a .doc file on the 
sharefile.com service, with no authentication required to access the 
link.


This is how security-competent a significant US financial services 
company is regarding email: broken DKIM signatures, invalid SPF records, 
and confidential information regarding mortgage accounts sitting at URLs 
accessible by anyone who can intercept a piece of email which AT BEST is 
transported using encryption which may be crackable in reasonable time 
by entities much weaker than the NSA.


BUT: People *REALLY* want their customer service email from Ditech. If 
you block invalid SPF, it fails. If you block invalid DKIM signatures, 
it fails. If you require strong encryption, it fails. It is possible (I 
have not tested...) that if you require strong encryption or none ("may" 
with a restrictive cipherlist) they may deliver potentially critically 
private information in the clear.


Welcome to 2016: Sturgeon's Law remains in effect.

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

2016-04-10 Thread jasonsu

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.

That I'm sold on.

> This is dangerous, 

This, not so much.

> Case in point: Ditech ...

Great example & reminder.

But,

(1) I'm not an ESP
(2) If a company publishes a policy, then fails to follow it, not my problem.  
It's theirs.

Yep I know that that's gonna cost me some 'Ditech-esque' mail.

> Welcome to 2016: Sturgeon's Law remains in effect.

Unfortunately, Sturgeon -- as was Orwell -- was an optimist :-/

Jason

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

2016-04-10 Thread Curtis Villamizar

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 is dangerous, as is raising the bar too high on ciphersuites.
>  
> Case in point: Ditech is one of the largest mortgage servicing companies 
> in the US, servicing millions of loans ultimately held by the federal 
> government. They send email responses to customer service inquiries out 
> via Microsoft's Office365 service, which signs it for the 
> "gtservicing.onmicrosoft.com" domain, but has it routed through Cisco 
> (formerly Ironport's) "iphmx.com" infrastructure for no visible reason, 
> where the From header is apparently re-written to 
> , breaking the DKIM signature. While the 
> iphmx.com machines accept mail from Microsoft using the suboptimal 
> AES256-SHA ciphersuite, they inexplicably use the affirmatively weak 
> TLSv1/RC4-SHA to pass it along. Because of this arcane routing, the 
> envelope sender (donotre...@gtservicing.com) has a domain with an SPF 
> record that is invalid due to its excessive complexity. Topping this 
> off, their messages consistently contain nothing but a bunch of 
> disclaimer boilerplate plus a link to the REAL message (which thankfully 
> is also usually low-content boilerplate) in a .doc file on the 
> sharefile.com service, with no authentication required to access the 
> link.
>  
> This is how security-competent a significant US financial services 
> company is regarding email: broken DKIM signatures, invalid SPF records, 
> and confidential information regarding mortgage accounts sitting at URLs 
> accessible by anyone who can intercept a piece of email which AT BEST is 
> transported using encryption which may be crackable in reasonable time 
> by entities much weaker than the NSA.
>  
> BUT: People *REALLY* want their customer service email from Ditech. If 
> you block invalid SPF, it fails. If you block invalid DKIM signatures, 
> it fails. If you require strong encryption, it fails. It is possible (I 
> have not tested...) that if you require strong encryption or none ("may" 
> with a restrictive cipherlist) they may deliver potentially critically 
> private information in the clear.
>  
> Welcome to 2016: Sturgeon's Law remains in effect.


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.

For my domains (all automated DNS zone file generation) I publish SPF
and DKIM (and any relevant DNSSEC crud and TLSA) and was planning to
update the homegrown tool to add DMARC.  By publishing those records,
you just avoid having someone forge mail as you (including to you, but
there are plenty of simpler ways to protect against that).  I was also
planning to reject based on opendmarc at some point in the
not-so-distant future.

Curtis

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

2016-04-10 Thread lists

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 yet to find email from an actual person that doesn't have DKIM or SPF. It 
is the "and" that doesn't work.

One of the email verification services put me in the top 3% of servers based on 
security. At the time, I though that was nuts. But looking typical email 
headers, that might be true. 

‎
‎

  Original Message  
From: jaso...@mail-central.com
Sent: Sunday, April 10, 2016 4:08 PM
To: postfix-users@postfix.org
Subject: 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.

That I'm sold on.

> This is dangerous, 

This, not so much.

> Case in point: Ditech ...

Great example & reminder.

But,

(1) I'm not an ESP
(2) If a company publishes a policy, then fails to follow it, not my problem. 
It's theirs.

Yep I know that that's gonna cost me some 'Ditech-esque' mail.

> Welcome to 2016: Sturgeon's Law remains in effect.

Unfortunately, Sturgeon -- as was Orwell -- was an optimist :-/

Jason

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

2016-04-10 Thread Viktor Dukhovni


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

2016-04-10 Thread Bill Cole


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 one approves of the company that now owns and 
inexplicably chose to revive the Ditech brand name recently is 
irrelevant, as are the predatory practices of GMAC when they existed and 
owned that brand. People with conventional "prime" mortgages don't 
really have any say in who services their loan from one year to the 
next: the servicing rights become a highly liquid market commodity once 
Fannie or Freddie holds the actual loan.


My point was that there are companies that people cannot readily choose 
to not do business with who send mail in ways which indicate that they 
have tried but very much failed to adhere to modern security standards. 
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 senders to use rigorous security correctly will 
often lead to unpleasant surprises.

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

2016-04-10 Thread jasonsu



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 senders to use rigorous security correctly will 
> often lead to unpleasant surprises.


Ya gotta break a few eggs to make an omelette ;-)

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

2016-04-11 Thread lst_hoe02



Zitat von jaso...@mail-central.com:


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 senders to use rigorous security correctly will
often lead to unpleasant surprises.



Ya gotta break a few eggs to make an omelette ;-)


And if you don't want to receive e-mail you should not operate a mail  
server or even publish a mail address.






smime.p7s
Description: S/MIME Cryptographic Signature

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

2016-04-11 Thread Curtis Villamizar

On 04/11/16 04:09, lst_ho...@kwsoft.de wrote:

Zitat von jaso...@mail-central.com:

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 senders to use rigorous security correctly will
often lead to unpleasant surprises.

Ya gotta break a few eggs to make an omelette ;-)

And if you don't want to receive e-mail you should not operate a mail
server or even publish a mail address.

The conversation was about SPF, DKIM, and DMARC (I think). (Drifted
from TLS).

If the sender (or sending ESP) has no clue about what SPF, DKIM, and
DMARC is, then they don't get penalized (or don't get penalized much).
If they publish SPF and/or DKIM records that are wrong, then they get
penalized more, but still not much. If the publish SPF and/or DKIM
records that are wrong and they publish a DMARC record that says "toss
my email if SPF or DKIM doesn't match", then guess what some mail
servers are going to do - including the big ESPs.

The reason DMARC exists is to prevent sender forgery. Expect some of
the big boys to enforce DMARC, meaning that if you publish a DMARC
record that says "toss and increment statistic if SPF or DKIM is wrong",
they will do exactly that. If you don't publish a DMARC record, then
someone could forge as you, but your legitimate mail won't get tossed.

As far as strict TLS - been there, done that - don't recommend it. If
you use ECDSA, then have a long key RSA as a backup. I've had no
trouble AFAIK setting TLS to high though Viktor doesn't recommend it. I
have not yet analyzed logs to see how often this is causing a fallback.

I recently had a problem with mail where an ESP was in three blacklists
plus SPF failed and spamassassin tossed some mail. That ESP is down to
one blacklist now. A sender got to me out-of-band and I dug up the
maillog from a few days earlier and informed them about how good their
ESP was serving them. btw- If I had been using postscreen back then, I
could not have found this in the logs based on sender email.

Curtis

ps - works for google, though dmarc says "accept and report". Google and
Yahoo are allegedly enforcing or will soon be enforcing dmarc (if you
publish a dmarc record).

gmail.com descriptive text "v=spf1 redirect=_spf.google.com"
20120113._domainkey.gmail.com descriptive text "k=rsa;
p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Kd87/UeJjenpabgbFwh+eBCsSTrqmwIYYvywlbhbqoo2DymndFkbjOVIPIldNs/m40KF+yzMn1skyoxcTUGCQs8g3FgD2Ap3ZB5DekAo5wMmk4wimDO+U8QzI3SD0"
"7y2+07wlNWwIt8svnxgdxGkVbbhzY8i+RQ9DpSVpPbF7ykQxtKXkv/ahW3KjViiAH+ghvvIhkx4xYSIc9oSwVmAl5OctMEeWUwg8Istjqz8BZeTWbf41fbNhte7Y+YqZOwq1Sd0DbvYAD9NOZK9vlfuac0598HY+vtSBczUiKERHv1yRbcaQtZFh5wtiRrN04BLUTD21MycBX5jYchHjPY/wIDAQAB
_dmarc.gmail.com descriptive text "v=DMARC1; p=none;
rua=mailto:mailauth-repo...@google.com";

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

2016-04-11 Thread lists

Just a quickie here on DMARC. I set one domain to "quarantine" and set up the 
rua to email me a report. Thus far, only MS Hotmail sends me anything, even 
though I have emailed yahoo accounts.  

The MS Hotmail report is in XML, which I can read in vim or whatever. I'm not 
sure what they intended me to use. 

Doing a survey of email clients with SPF and DKIM verification, I only found 
Thunderbird does this, and with a plugin.  Thunderbird is in caretaker status, 
so I don't use it. 

Thus an identification system (SPF and DKIM ) had been created that mail system 
administrators are loathe to strictly enforce for received email, and with no 
consequences, is only half heartedly complied with on the sending side.  
(Congrats to the interwebs for at least providing many DKIM/SPf verification 
websites.)

And if we agree (OK, some agree) that strict rejection of received email based 
on SPF and DKIM is not a good idea, you would think at least the email clients 
would make detection of these identification methods more automatic.

Hats off to programmers for providing/maintaining tools that the masses don't 
appreciate.

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

2016-04-12 Thread Wietse Venema

Curtis Villamizar:
> I recently had a problem with mail where an ESP was in three blacklists 
> plus SPF failed and spamassassin tossed some mail.  That ESP is down to 
> one blacklist now.  A sender got to me out-of-band and I dug up the 
> maillog from a few days earlier and informed them about how good their 
> ESP was serving them.  btw- If I had been using postscreen back then, I 
> could not have found this in the logs based on sender email.

Incorrect. In the recommended configuration, postscreen will log
IP address, helo, sender, and recipient.

Wietse

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

2016-04-12 Thread Robert Schetterer

Am 12.04.2016 um 07:56 schrieb li...@lazygranch.com:
> Just a quickie here on DMARC. I set one domain to "quarantine" and set up the 
> rua to email me a report. Thus far, only MS Hotmail sends me anything, even 
> though I have emailed yahoo accounts.  
> 
> The MS Hotmail report is in XML, which I can read in vim or whatever. I'm not 
> sure what they intended me to use. 

or use

https://dmarcian.com/dmarc-xml/


> 
> Doing a survey of email clients with SPF and DKIM verification, I only found 
> Thunderbird does this, and with a plugin.  Thunderbird is in caretaker 
> status, so I don't use it. 
> 
> Thus an identification system (SPF and DKIM ) had been created that mail 
> system administrators are loathe to strictly enforce for received email, and 
> with no consequences, is only half heartedly complied with on the sending 
> side.  (Congrats to the interwebs for at least providing many DKIM/SPf 
> verification websites.)
> 
> And if we agree (OK, some agree) that strict rejection of received email 
> based on SPF and DKIM is not a good idea, you would think at least the email 
> clients would make detection of these identification methods more automatic.
> 
> Hats off to programmers for providing/maintaining tools that the masses don't 
> appreciate.
> 



Best Regards
MfG Robert Schetterer

-- 
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein

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




On 04/12/16 12:06, Robert Schetterer wrote:

Am 12.04.2016 um 07:56 schrieb li...@lazygranch.com:

Just a quickie here on DMARC. I set one domain to "quarantine" and set up the 
rua to email me a report. Thus far, only MS Hotmail sends me anything, even though I have 
emailed yahoo accounts.

The MS Hotmail report is in XML, which I can read in vim or whatever. I'm not 
sure what they intended me to use.

or use

https://dmarcian.com/dmarc-xml/


Since programs will usually be reading the XML and producing reports 
locally, XML is a good format.  Plenty of perl and python modules to 
parse XML.


I use emacs and it does a nice job of coloring XML according to function 
(element, attribute, etc).  Its no worse that reading HTML source.

Doing a survey of email clients with SPF and DKIM verification, I only found 
Thunderbird does this, and with a plugin.  Thunderbird is in caretaker status, 
so I don't use it.


I use my phone and thunderbird to preview my IMAP accounts and 
occasionally respond on one or the other.  Then I run fetchmail (with 
TLS) to empty the folder and actually read and archive my mail.


DKIM signature should be done by the MSA.  That would mean postfix for 
most of the people on this list.  Therefore mail sent from any client 
gets DKIM signed.  There is an opendkim milter for this.  MSA should 
authenticate, match to sender (or verify sender somehow) and then DKIM sign.



Thus an identification system (SPF and DKIM ) had been created that mail system 
administrators are loathe to strictly enforce for received email, and with no 
consequences, is only half heartedly complied with on the sending side.  
(Congrats to the interwebs for at least providing many DKIM/SPf verification 
websites.)
That might be partially because they don't understand how it was 
intended to be deployed.  DKIM signature is not intended to be done by 
the MUA as the general case.


And if we agree (OK, some agree) that strict rejection of received email based 
on SPF and DKIM is not a good idea, you would think at least the email clients 
would make detection of these identification methods more automatic.

Hats off to programmers for providing/maintaining tools that the masses don't 
appreciate.

Rejection of mail with DNS records that indicate that mail MUST be from 
a given address range, or MUST be signed, should be honored to prevent 
forgery.  Those domains are saying that they do have their act together 
and know where their mail should be originating from and have the the 
ability to sign it.  The error in DKIM design was that there is no way 
to determine that unsigned mail should have been signed and DMARC fixes 
that.



Best Regards
MfG Robert Schetterer



Curtis

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



On 04/12/16 06:25, Wietse Venema wrote:

Curtis Villamizar:

I recently had a problem with mail where an ESP was in three blacklists
plus SPF failed and spamassassin tossed some mail.  That ESP is down to
one blacklist now.  A sender got to me out-of-band and I dug up the
maillog from a few days earlier and informed them about how good their
ESP was serving them.  btw- If I had been using postscreen back then, I
could not have found this in the logs based on sender email.

Incorrect. In the recommended configuration, postscreen will log
IP address, helo, sender, and recipient.

Wietse


My inexperience with debugging problems with postscreen logs is showing.

Curtis

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


Not an expert on DMARC, but ...

On 04/12/16 01:56, li...@lazygranch.com wrote:

Just a quickie here on DMARC. I set one domain to "quarantine" and set up the 
rua to email me a report. Thus far, only MS Hotmail sends me anything, even though I have 
emailed yahoo accounts.

The MS Hotmail report is in XML, which I can read in vim or whatever. I'm not 
sure what they intended me to use.


The DMARC RFC (rfc7489) indicates that this is failure reporting. That 
would imply that so far only hotmail got forged email that looked like 
it was from your domain.


If you are not getting reports from anyone else, that is a good thing.  
I don't think there is any requirement to send empty reports or that 
those reports would serve any purpose (except maybe create "I got your 
report and here is your" loops).


Curtis

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

2016-04-12 Thread lists

‎No. The report says everything is kosher. 

  Original Message  
From: Curtis Villamizar
Sent: Tuesday, April 12, 2016 10:57 AM
To: li...@lazygranch.com; postfix-users@postfix.org
Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Not an expert on DMARC, but ...

On 04/12/16 01:56, li...@lazygranch.com wrote:
> Just a quickie here on DMARC. I set one domain to "quarantine" and set up the 
> rua to email me a report. Thus far, only MS Hotmail sends me anything, even 
> though I have emailed yahoo accounts.
>
> The MS Hotmail report is in XML, which I can read in vim or whatever. I'm not 
> sure what they intended me to use.

The DMARC RFC (rfc7489) indicates that this is failure reporting. That 
would imply that so far only hotmail got forged email that looked like 
it was from your domain.

If you are not getting reports from anyone else, that is a good thing. 
I don't think there is any requirement to send empty reports or that 
those reports would serve any purpose (except maybe create "I got your 
report and here is your" loops).

Curtis

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

2016-04-12 Thread Noel Jones

On 4/12/2016 11:38 AM, Curtis Villamizar wrote:
> 
> On 04/12/16 06:25, Wietse Venema wrote:
>> Curtis Villamizar:
>>> I recently had a problem with mail where an ESP was in three
>>> blacklists
>>> plus SPF failed and spamassassin tossed some mail.  That ESP is
>>> down to
>>> one blacklist now.  A sender got to me out-of-band and I dug up the
>>> maillog from a few days earlier and informed them about how good
>>> their
>>> ESP was serving them.  btw- If I had been using postscreen back
>>> then, I
>>> could not have found this in the logs based on sender email.
>> Incorrect. In the recommended configuration, postscreen will log
>> IP address, helo, sender, and recipient.
>>
>> Wietse
> 
> My inexperience with debugging problems with postscreen logs is
> showing.
> 
> Curtis


Note the helpful logging of helo/sender/recipient requires the
offending test be set to "enforce" rather than "drop".  This is
noted in the docs.
See the various postscreen_*_action parameters for details, such as:
http://www.postfix.org/postconf.5.html#postscreen_dnsbl_action




  -- Noel Jones

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