[Mailman-Developers] dkim-signature headers

[Michael Thomas]

The very basic test I use is what's in the From: address. That's the thing
that's pretty universally displayed and one that users are most likely to
grok. Anything beyond From, and you've probably lost at least half of
the user population at least.

So mailing lists preserve the original From: and perhaps add a Sender:.
If I had to chose a signature which was most relevant for _display_ purposes
(note that display purposes is but _one_ reason for signatures), I'd 
like to
be able to say something good about the From address that most users
grok. It's unclear that I'd want to say something nice about the Sender or
any other third party signature because it may confuse users that the
mere presence of a signature imputes some trust, where it actually needs
to be considered on a case by case basis. I for one would only render the
sender: as "verified" both if it verified correctly as well as it being 
on some
known whitelist of domains that I trust.

So the bottom line is that a valid third party signature from, say, a 
mailing
list is not safe a priori. It requires special handling by the ultimate 
receiver
in the form of a trust relationship with that domain which needs be done
out of band. The same is not of a first party signature because you're only
vouching for yourself which is already as good you trust that domain (or
not).

       Mike, is this making any sense?

Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I'm not sure what the right answer is just yet, but I'll offer some of 
> my thoughts FWIW.
>
> I think the fundamental question is whether the mailing list is the 
> originator of the messages its members receive or whether the original 
> author is.  This question has come up in other contexts before, and I 
> don't think it's ever been answered satisfactorily.   A quick search 
> through DKIM archives seems to indicate that this question has come up 
> there too, and I think answering it will help us understand what we 
> should be doing here.
>
> On Feb 1, 2007, at 3:00 PM, Mark Sapiro wrote:
>
>> Consider that while Mailman doesn't do all of these things to every
>> message, it can do any of the following:
> [munge the original message]
>
> From the DKIM FAQ:
>
>     - What is the purpose of DKIM?
>
>     DKIM lets an organization take responsibility for a message.  The 
> organization taking responsibility is a handler of the
>     message, either as its originator or as an intermediary. Their 
> reputation is the basis for evaluating whether to trust the
>     message for delivery.
>
> I think you can make a legitimate case that Mailman is the originator 
> of messages its members receive.  The message is certainly different 
> than the one the original poster sent to the list, and Mailman is 
> clearly an intermediary.  Perhaps the message has only been munged in 
> very trivial ways, but it's also possible to munge it in ways that 
> could potentially be viewed as spammy.  For example, what if a site 
> decides to put some advertisements in the footer?
>
> If you take this view then it seems reasonable to say that it is the 
> mailing list's system that "take[s] responsibility for a message."  
> Sure, the mailing list system could verify the DKIM headers on the 
> message it receives, but ultimate, it is up to the mailing list system 
> to decide whether that message (or some derivative of that message) 
> gets transmitted to its recipients.
>
> Or looked at another way, if I send a message through a mailing list, 
> I wouldn't want to vouch for whatever comes out the other end because 
> I don't know what they're going to do to my original content.  Maybe 
> then, it's correct for the DKIM signature on the copied message to be 
> broken because what recipients got was /not/ the message I sent, and I 
> don't know how it was munged.  But that view implies that I am the 
> originator of the recipient's message.  I am, sort of, but also sort 
> of not.
>
> I'm not convinced that DKIM is really designed to handle the mailing 
> list use case.  It seems to me that it was designed to handle 
> point-to-point messages, not messages that flow through an 
> intermediary, because it's not an enveloping system.  Contrast that 
> with S/MIME or OpenPGP.  I can sign the message I send from my mailer 
> and that could be preserved through the transformations that Mailman 
> performs, with Mailman wrapping my original in its own signature if it 
> wanted to.
>
> Practically speaking, if we can't come up with a consensus on the 
> interpretation of which "organization [should] take responsibility 
> for" the actual message that recipients receive, then what would be 
> the right thing to do?  (Note that this answer is different depending 
> on whether we're talking about Mailman 2.1 or some future version.)
>
> When this came up before I statement my preference not to make a 
> "strip DKIM headers" selectable by the list owner.  I still prefer 
> this for Mailman 2.1 because doing so would clearly be a new feature.  
> Maybe a future version could treat the DKIM header the way it treats 
> the RFC 2369 headers, with a separate selector for List-Post.  
> Ideally, we'd have a more general way to decide which headers get 
> cleansed and which new ones get added.  But that's for the future.
>
> One elaboration you /might/ be able to get away with in Mailman 2.1 
> occurs to me as I look at Mark's list:
>
>>  - Add text to the beginning of the message body (msg_header)
>>  - Add text to the end of the message body (msg_footer)
>>  - Remove text from the beginning of the message body (Approved: line)
>>  - Add additional MIME parts to a multipart message (msg_header,
>> msg_footer)
>>  - Convert a single part message to multipart in order to add
>> msg_header/msg_footer
>>  - Remove parts from a multipart message (content filtering)
>>  - Convert an HTML part to plain text (content filtering)
>>  - Decode a base64 or quoted-printable encoded part and perhaps
>> re-encode it with a different encoding.
>>  - Change or delete various headers including Subject:, To:, From:
>>  - Replace some MIME parts with URLs of where they were stored and
>> flatten the entire message into a single plain text message (scrubber).
>>  - Probably other things I'm overlooking.
>
> If you could identify the message transformations that break the 
> signature, then you could remove the signature.  If the signature of 
> the outgoing message were still valid because Mailman didn't touch any 
> part of the message affecting the signature, then you could keep it.  
> The implementation of this would be fairly simple; the hard part is 
> writing the code to verify a DKIM signature and parse the selectors 
> (IIUC the specification) to figure out which of the above 
> transformations would break the signature.  That might be enough to 
> not do it in Mailman 2.1.
>
> I'm not sure how much I like that anyway, so comments are definitely 
> welcome.  After mulling over this post for an hour ;) I'm starting to 
> believe that it's the mailing list system that needs to vouch for the 
> messages its recipients receive.  Of course, it could be Mailman doing 
> the DKIM signing, or it could be Mailman's outgoing MTA, etc.  But, 
> ISTM Mailman is ultimately deciding what goes into the list copy, so 
> it is responsible for it.
>
> - -Barry
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
>
> iEYEARECAAYFAkXCt04ACgkQ2YZpQepbvXHsAACfVOu25u2Ps2MrC0qQE7i/W5sx
> ZdYAoL0z9q0+zjt7gpI3JrFy62m4DkAq
> =+a49
> -----END PGP SIGNATURE-----