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