dkim and email list software - potential solution

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: publishes a ADSP dkim record saying 'I sign all messages for this domain'
- An author emails to a mailing list.
- The author's email infrastructure DKIM signs the email message and
- The message is received by the email list
- the email list software removes the DKIM-signature or, though message modification, invalidates the signature
- the email list subscriber receivers the email and attempts a DKIM-signature
validation. If the signature did not exist it will validate ok. - 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).
- email gets dropped due to ADSP
The ways email list software can deal with this is (from [2]): that may not meet the list owner's policy.
- ignore the problem - not really friendly given social demand for antispoofing
- 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
- remove DKIM-Signature conditionally - fails ADSP really badly
- 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
- remove DKIM-Signature always - fails ADSP really badly
As we can see none of these are ideal.
What I propose as a solution is:
- rewrite the From: address of the email to include the domain of the email address. and one or both of:
- make "sender" or "reply-to" email headers contain the original sender
- 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 sympa-dev+daniel_cacert.org@cru.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

wow. more than 16 hours and no one has posted anything.
Daniel Black wrote:
I'm going to respond without getting into any of the ADSP emotional debate. ADSP is what it is. DKIM is what it is. You are asking a legitimate question about a potential scenario that seems likely to occur.
If someone registers an ADSP record that says that any failed or absent signatures should cause the message to be dropped, they are responsible for making the assertion and for its consequences.
The presumption behind this bit of mechanism is that the ADSP registrant knows enough, and can control enough, to produce the desired outcome.
The scenario you are exploring demonstrates a case in which they were wrong.
I think it a mistake to ask intermediaries to fix the effects of their own legitimate actions, really caused by inappropriate policy choices of an organization earlier in the handling sequence.
The core problem, here, is that the signing organization asserted a generality that was incorrect. It's not your job to hack your system or the messages you process to try to fix their mistaken generality.
d/
ps. There are cases of SPF -a being set incorrectly, and it didn't even take a mailing list to create undelivered mail. The solution is to change the -a setting, rather than try to hack around it.
--
Dave Crocker Brandenburg InternetWorking bbiw.net

On 9/29/09 12:10 PM, Dave CROCKER wrote:
wow. more than 16 hours and no one has posted anything.
There are no good solutions. This feature was intended to cause messages with their signatures damaged or missing to not end up in someone's mailbox. Any domain making an ADSP discard assertion should expect the domain will become usable on mailing lists. Such domains should be limited to handling transactional emails.
Unfortunately, this view might lead to more phishing exploits whenever alternative domains are then used by the same organization. When there is nothing good to be said, perhaps the better choice is to say nothing. Perhaps there should be a standardization for transactional sub-domains and stringent requirements where ADSP transactions then become superfluous. Where subdomains like secure, or signed.somedomain.com versus somedomain.com might be used as a way to establish a visual convention.
-Doug

wow. more than 16 hours and no one has posted anything.
Daniel Black wrote:
I'm going to respond without getting into any of the ADSP emotional debate. ADSP is what it is. DKIM is what it is. You are asking a legitimate question about a potential scenario that seems likely to occur.
If someone registers an ADSP record that says that any failed or absent signatures should cause the message to be dropped, they are responsible for making the assertion and for its consequences.
The presumption behind this bit of mechanism is that the ADSP registrant knows enough, and can control enough, to produce the desired outcome.
The scenario you are exploring demonstrates a case in which they were wrong.
I think it a mistake to ask intermediaries to fix the effects of their own legitimate actions, really caused by inappropriate policy choices of an organization earlier in the handling sequence.
The core problem, here, is that the signing organization asserted a generality that was incorrect. It's not your job to hack your system or the messages you process to try to fix their mistaken generality.
d/
ps. There are cases of SPF -a being set incorrectly, and it didn't even take a mailing list to create undelivered mail. The solution is to change the -a setting, rather than try to hack around it.
--
Dave Crocker Brandenburg InternetWorking bbiw.net

On 9/29/09 12:10 PM, Dave CROCKER wrote:
wow. more than 16 hours and no one has posted anything.
There are no good solutions. This feature was intended to cause messages with their signatures damaged or missing to not end up in someone's mailbox. Any domain making an ADSP discard assertion should expect the domain will become usable on mailing lists. Such domains should be limited to handling transactional emails.
Unfortunately, this view might lead to more phishing exploits whenever alternative domains are then used by the same organization. When there is nothing good to be said, perhaps the better choice is to say nothing. Perhaps there should be a standardization for transactional sub-domains and stringent requirements where ADSP transactions then become superfluous. Where subdomains like secure, or signed.somedomain.com versus somedomain.com might be used as a way to establish a visual convention.
-Doug
participants (3)
-
Daniel Black
-
Dave CROCKER
-
Douglas Otis