On May 2, 2014, at 11:22 AM, Christopher Morrow <morrowc.lists@xxxxxxxxx> wrote: > On Fri, May 2, 2014 at 2:05 PM, Fred Baker (fred) <fred@xxxxxxxxx> 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@xxxxxxxx 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