[Mailman-Developers] ARC module implementation [was: GSOC 2016]

[Stephen J. Turnbull]

Aditya Divekar writes:

 > Since the receiver is going to get the mail through the mailing
 > list anyway, personally I think that the From munging strategy is
 > not a bad idea.

Yeah, everybody who advocates it "personally thinks" it's a not bad
strategy.  The problem is that it out-and-out violates the RFCs,
general ethics, and possibly copyright law, unless you think that
forwarding something verbatim with possible addition of non-editorial
content (eg, list serial numbers and subscription information in the
footer) makes you an author.  There's no other use case I can think of
where people seriously maintain that editors are authors.

One minor UI problem is that some MUAs can and are configured to
display a personal icon rather than the display name -- choice of
which is usually based on the email address.

To my mind, though, the big problem is that from-munging does cause a
number of technical problems, such as handling of reply-to.  There
simply is no satisfactory answer for all use cases that are served by
RFC 5322.  There is a minor functionality loss to sophisticated users,
and there is a real privacy risk (of posting what was intended as a
private message, mostly to naive users).

Anyway, I don't think this has anything to do with ARC, in the sense
that we can assume that we're going to invalidate the original DKIM
signature.  AFAICT, ARC needs to do its validation on the received
message, then add the headers on the way back out.  This will work
fine in the no-modification case as well.

 > P.S. Also, I have noticed that there is a feature defined in the
 > handlers to cleanse all the dkim headers from a mail sent to the
 > list before it is forwarded to the subscribers. We could simply use
 > this to extract the previous dkim signature, and generate the ARC
 > authentication results since its a copy of the previous results.

I don't understand what you mean by "extract the previous DKIM
signature and generate the ARC authentication results since it's a
copy of the previous results."

Among other things that seems to assume there was no forward between
you and the originating domain that might invalidate the original
signature.

Now, we need to be very careful to follow the protocol as set out by
the RFC.  I haven't looked recently (and don't have time to right
now), but I seem to recall that each ARC participant must validate all
header fields it vouches for (ie, signs in the ARC-Seal).  To me that
means that we need to provide the DKIM validation service in any case,
unless we 100% trust the MTA.  That means identifying our MTA's
Authentication-Results field, and trusting that our MTA removes any
Authentication-Results field that appears to be from our domain,
before adding an authentic Authentication-Results.

If there are trustworth MTAs in that sense, you could take the
strategy of requiring it, but we still might need to do some
validation that DKIM-enabled MTAs don't necessarily do, such as
earlier ARC fields.

Gotta run now, but really before we start trying to design the code,
we need to figure out exactly what we're required to do.

Steve