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

[Hector Santos <[e-mail]>]

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