Re: DMARC: perspectives from a listadmin of large open-source lists

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 4/11/2014 6:40 AM, Alessandro Vesely wrote:> On Tue 08/Apr/2014 19:34:35 +0200 John R Levine wrote:

Just today I did modify it so that any list mail with a From: address
@yahoo.com is re written to @yahoo.com.INVALID.  That's the least
intrusive way I've been able to come up with to mitigate the damage.

Fair enough.  I've copied that suggestion to
http://en.wikipedia.org/wiki/DMARC#Human_policy
Please feel free to amend that page at your leisure.


Hi Alessandro,

You added (I presume):

   According to John Levine, a well known mail expert, the least
   intrusive way to mitigate the damage would be to rewrite the
   From: address in a predictable, comprehensible manner, such as
   the following:

It may be the "quickest" way, but I would consider this the most intrusive and even email damaging, extremely harmful suggestion to electronic mail communications.

It opens a can of worms, Pandora's box, so to speak, to begin suggesting one can modifying and tampering with one the key x822/5322 mail headers, From:, for any local reason.

In my ethical engineering book, it would just be major TABOO to do this. The 5322.From one is the anchor for fundamental electronic mail I/O for both networking and non-networking and for other technologies. To tamper with it, it is bound to break other things.

Keep in mind, ADSP also proposed a "radical" DISCARD concept for mail. But because of the ADSP standard track work and synergism at the time, we did get RFC2821BIS (RFC5322) to recognize the new reality that there are new reasons to ACCEPT and DISCARD rather than ACCEPT and BOUNCE without referring to the ADSP work (it was still a draft).

    side note:

    There was also a new modern reality where the SMTP DATA state point
    would be used more as a CALL OUT, SHIM, HOOK to handle new RFC5322
    based Payload technology such as DKIM verification where a ADSP
    policy check would also apply.  One main goal was dynamic processing
    with instant non-bounce notifications.  But with ADSP, there was
    suggestions for an implementation to set a ADSP fail that allows
    the acceptance of mail so it can be quietly discarded. IOW, no
dynamic 55x rejection at the SMTP level for ADSP fail policies because
    that caused problems for the blind mailing list servers.

Yes, it is all complex, but here, the real solution is for John Levine and other large list operators to update their mail listing software to follow the suggestions in RFC6377:

   RFC6377 DomainKeys Identified Mail (DKIM) and Mailing List

Its not a new problem, its been known since 2006. There are secondary DKIM security "wrapper" layers that augment DKIM. DMARC may be the focus, but the issue existed since SSP and ADSP. If the list service is going to resign mail with DKIM, it needs to recognize that DKIM does comes with signature security baggage that the not covered by the trust model.

So this is a "integration" issue. Honestly, the changes are not too difficult and IMO, it is far less intrusive than changing the 5322.From.

1) When a new subscriber applies to a list, check for restrictive domain policies. Deny subscribers and explain why in the notification message.

2) Check for restrictive domains in list mail submissions.

The first one is the piece a cake. The 2nd one can be more complex due to the wider number of software things to do here.

2a) Dynamic SMTP check, reject (55x) the message with policy reason.

2b) Accept message and send a "no access" notification message. Explain why.

2c) During the redesign software change, write a one time membership scanner to remove restrictive domain members. Send email notification explaining why.

Etc. My main point is that we been doing this for 9+ years. We knew the problems and we have the ideas for solutions. Whether it was all practical and could scale, well, everyone had different opinions here.

But we got a different issue here when list operations don't want to change to add policy protocol support but change enough to support a pure DKIM-BASE but nothing else. I fail to see how it can work that way.

This is a "integration" issue and can only be solved using an integrated DKIM+POLICY framework and mentality.


--
HLS






[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]