Click the comments link on any story to see comments or add your own.
Subscribe to this blog
18 Jan 2006
It's fairly straightforward to see how DKIM applies to normal mail--I send the mail, my mail system signs it, you get it, and you check the signature from my mail system. But it's a lot less clear what the best approach is for mailing lists, the discussion type that forward messages from members out to the list.
One model which we might call the "thin" model considers mailing lists to be essentially mail forwarders, so the identity of the mail is that of the original sender. This encourages list software to minimize the changes they make to mail on the way through to avoid breaking the signature, and perhaps to add its own signature on the way through. IIM, one of DKIM's predecessors, had a few hacks intended to help this, a length field to tell the recipient that the signature doesn't cover all of the message, and copies of signed headers so that the recipient can see what, for example, the Subject line said before the list added a [listname] tag. I've never seen a persuasive description of what recipient MUAs are supposed to do with subject lines that don't match the signed copy and chunks of unsigned trailing material but I expect people who think it's a good idea can explain it. Another way to be sure the signature stays intact would be to encapsulate every incoming signed message like a one-message MIME digest, but list reading users would probably not enjoy that.
The other "thick" model considers the mailing list to be the originator of the message. In this model, the list software would strip off the signature from the incoming message, do whatever it does to the message, and re-sign it on the way out. This better matches modern list software that can reorder and delete MIME parts and flatten HTML messages to plain text. There are a variety of plausible things the list software might do with the inbound signature, ranging from discarding it (on the theory that it's the list's reputation that matters for list mail, not the reputation of the contributors) to using a different header to log the fact that the inbound message had a good signature, and signing that.
Depending on your view of what a list is and the way your list software works, you could try and implement either of these. One thing I can definitely promise is that people will have religious beliefs as deep and irrational as the ones they have about Reply-To: headers, so no matter what you do, you can be sure that someone will tell you that you are an idiot for not doing it his way.
My other sites
© 2005-2013 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.