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