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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

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 ;-)
Reply | Threaded
Open this post in threaded view
|

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

lst_hoe02

Zitat von [hidden email]:

> 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 (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Curtis Villamizar


On 04/11/16 04:09, [hidden email] wrote:

>
> Zitat von [hidden email]:
>
>> 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:[hidden email]"

Reply | Threaded
Open this post in threaded view
|

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

lists@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. 

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.

Reply | Threaded
Open this post in threaded view
|

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

Wietse Venema
In reply to this post by Curtis Villamizar
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
Reply | Threaded
Open this post in threaded view
|

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

Robert Schetterer-2
In reply to this post by lists@lazygranch.com
Am 12.04.2016 um 07:56 schrieb [hidden email]:
> 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
Reply | Threaded
Open this post in threaded view
|

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

Curtis Villamizar


On 04/12/16 12:06, Robert Schetterer wrote:
> Am 12.04.2016 um 07:56 schrieb [hidden email]:
>> 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

Reply | Threaded
Open this post in threaded view
|

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

Curtis Villamizar
In reply to this post by Wietse Venema

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
Reply | Threaded
Open this post in threaded view
|

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

Curtis Villamizar
In reply to this post by lists@lazygranch.com
Not an expert on DMARC, but ...

On 04/12/16 01:56, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

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

lists@lazygranch.com
‎No. The report says everything is kosher. 

  Original Message  
From: Curtis Villamizar
Sent: Tuesday, April 12, 2016 10:57 AM
To: [hidden email]; [hidden email]
Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Not an expert on DMARC, but ...

On 04/12/16 01:56, [hidden email] 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

Reply | Threaded
Open this post in threaded view
|

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

Noel Jones-2
In reply to this post by Curtis Villamizar
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
Reply | Threaded
Open this post in threaded view
|

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

Curtis Villamizar


On 04/12/16 14:26, Noel Jones wrote:

> 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

I have nothing set to drop.  Just been running postscreen for such a
short time and on a little used domain (not this one) that mostly gets
spammed a lot but gets a small amount of legit email from people that
forgot that I told them not to use it.  So I haven't had to debug a "got
a bounce" issue with postscreen.

Thanks for the heads up.  By the time I run postscreen on a domain that
matters I hope to have a good configuration.

Curtis

12