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:.
*(_at_)mydomain(_dot_)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
sympa-dev+daniel_cacert(_dot_)org(_at_)cru(_dot_)fr 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev