ietf
[Top] [All Lists]

Re: Suggestion: can we test DEMARC deployment with a mailing list?

2014-05-02 13:49:22

On May 2, 2014, at 11:22 AM, Christopher Morrow 
<morrowc(_dot_)lists(_at_)gmail(_dot_)com> wrote:

On Fri, May 2, 2014 at 2:05 PM, Fred Baker (fred) <fred(_at_)cisco(_dot_)com> 
wrote:
We have been having a fairly extended discussion, much of which seems 
hypothetical - “I don’t like DEMARC because I am worried that ... with 
mailing lists”. I wonder if we could take a moment to try it and see what 
happens?

As an example of the case that comes to mind, see attached. It is a message 
sent to v6ops(_at_)ietf(_dot_)org yesterday. The sender signed it using 
DKIM, the IETF changed the message (added some trailing text) before 
forwarding it, the receiver (e.g., Cisco IT) attempted to validate the DKIM 
signature - and failed.


dkim != dmarc (but maybe that wasn't your point)

It seems to me that we should not approve a procedure that has that effect, 
at least without some guidance for mail relay administrators. I could 
imagine two forms of guidance: “obey the end-to-end principle; don’t change 
the message the originator sent”, or “if you change a signed message, first 
validate the message you received and discard if that fails, change it, and 
then sign it yourself, so that a receiver can see who changed it and 
validate the outcome”.

Could we actually try such guidance in a sandbox, and document appropriate 
procedures for mailing lists?


which mailing list software? or did you mean test a general solution
and document the general solution?

Dear Chris and Fred,

There is a TPA (third-party authorization using hash labels) draft being 
revised aimed specifically at solving this problem without introducing new 
demands on mailing-list and other third-party services, or requiring per 
destination signatures.  The goal is to mitigate disruptions caused by strict 
policy requests as possible with DMARC while still allowing trusted domains 
(author domains) a means to effectively delist any authorized source when abuse 
is detected.  Delisting should only occur after third-party administrators have 
been allowed to correct the issue.

This approach allows author domains fine grain control over third-party 
conveyance of initial messages, even over multiple services as can occur with 
mailing-lists.  It will not increase message size.  It can scale to massive 
levels having little overhead.  Much less overhead than that required to 
support SPF or DKIM, the basis of DMARC.

Regards,
Douglas Otis