Developers of Sympa

[Daniel Black <address@concealed>]

Folks,

Please excuse the massive cross post and reply to the dkim-dev list if 
possible and it is of collective interest to many email list software 
implementers.

I've put together a paper on DKIM that I've just put out for review. It is 
available here[1] if anyone would like to review it. Feedback can still be 
incorporated.

As you may know ([2] and others), DKIM has an incompatibility with email list 
software message modification and ADSP verification (RFC5617).

The incompatibility is as follows:
1. An author emails to a mailing list. 
2. The author's email infrastructure DKIM signs the email message and 
publishes a ADSP dkim record saying 'I sign all messages for this domain'
3. The message is received by the email list
4. the email list software removes the DKIM-signature or, though message 
modification, invalidates the signature
5. the email list subscriber receivers the email and attempts a 
DKIM-signature   
validation. If the signature did not exist it will validate ok.
6. the email list subscriber attempts to validated the DKIM-ADSP. The author 
domain, taken from the From: address, has a DKIM-ADSP record saying "all" 
(meaning I sign all messages) or "discard" (discard if the author domain 
signature is invalid or missing).
7. email gets dropped due to ADSP

The ways email list software can deal with this is (from [2]):
1. ignore the problem - not really friendly given social demand for 
antispoofing
2. Parse DKIM-Signature and don't do transforms that break this - will end up 
lots of exception handling code and an inconstant emails to the subscriber 
that may not meet the list owner's policy.
3. remove DKIM-Signature conditionally - fails ADSP really badly
4. sign list-ID headers and ask verifiers to check for list-id tags in a 
spamyness way - complicates verification, provides spoofing loophole as DKIM 
is 
antispoofing more that anitspam
5. remove DKIM-Signature always - fails ADSP really badly

As we can see none of these are ideal.

What I propose as a solution is:

1. rewrite the From: address of the email to include the domain of the email 
address.
and one or both of:
2. make "sender" or "reply-to" email headers contain the original sender
3. make the mail list contain a delivery from the rewitten address in#1 to 
the 
original sender.

Rational:
For #1:
Rewriting the From address immediately makes the Author domain the email 
list. 
As such the ADSP verification by the receiver immediately looks to the email 
list domain for signatures.

The original DKIM-signature is there and should not be removed despite being 
invalid (as recommended in one of the RFC), however as it is no longer the 
Author Domain Signature its criticality is not as important.

Having a From domain here makes it easy for DKIM signing software to sign all 
email for the for email list. Some signing software says sign only "From:. 
*@mydomain.com".

I discarded the idea of adding a From address as sender-id verification will 
fail if two (or more) from addresses though earlier versions do and DKIM 
supports it.

For #2:
Having a reply-to and sender (RFC5322 3.6.2) gives the MUA the hint as to 
where to send the reply now that we have altered the from address.

I acknowledge that email lists already mundge this sometimes hence option #3.

For #3:
Taking care of those cases where the MUA or user just copies the from address 
or where option #2 is not considered, it would be just polite to deliver the 
munged email address of the email list domain back to the author.

Careful consideration here needs to take care of the transformation. Relaying 
through a mail server should require some checks and here it is particular 
important. Mutilating an address to address@concealed 
without 
checks would just encourage spammers to send email to sympa-
dev+(arbitaryemailaddress)@cru.fr and the email list would become effectively 
an open relay. Some kind of check to make sure the arbitaryemailaddress is a 
subscriber of the list would be a primary check though other encrypted/signed 
 
addresses are also possible here.

I see this as the solution that requires the least amount of code changes, 
preserves most existing behaviour, and becomes it becomes DKIM friendly. I'm 
keen to know if you agree or think otherwise. I don't know how IETF authors 
feel about this but I'll also find out fairly soon :-)

The referenced paper[1] contains some guidelines for DKIM signing list 
messages too. Feedback on that also welcome.

[1] https://community.cacert.org/dkim/ - dkim paper talking about email lists
[2] http://wiki.list.org/display/DEV/DKIM

Cheers,
-- 
Daniel Black
Infrastructure Administrator
CAcert

Attachment: signature.asc
Description: This is a digitally signed message part.