[Mailman-Developers] dkim-signature headers

Michael Thomas mat at cisco.com
Fri Feb 2 16:57:21 CET 2007


Barry Warsaw wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Feb 1, 2007, at 2:17 PM, Michael Thomas wrote:
>
>> I've for quite a while thought that part of an ultimate DKIM BCP would
>> give some guidance on what a "well behaved mailing list" would be. It
>> would certainly be good if mailman were an example of that because at
>> least at Cisco it accounts for the bulk of external mailing list traffic
>> we see.
>
> I agree with both statements.  Note that there are many email related 
> RFCs that are ambiguous in the mailing list use case.  We make choices 
> based on our best interpretation but it's never fully satisfactory.  
> If there's a possibility to have DKIM specify what a properly behaving 
> mailing should do (with of course, consensus from this community and 
> other listserver vendors), then I'm all for it.
>
>> (at least by default). The main issue is that there is a 
>> security/robustness
>> tradeoff with the use of l=. That is, bad guys could append content too.
>> On the other hand, *if* that comes to pass, receivers are completely at
>> liberty to scan the covered and uncovered parts of the body differently,
>> delete the appended text, etc, etc.
>
> Isn't it possible that from the point of view of the original sender, 
> the mailing list /is/ the bad guy?

Absolutely! Consider:

From: barry at python.org
Sender: fooledyou at badguy.com
DKIM-Signature: d=badguy.com [...]


So you'd have a perfectly legitimate signature that corresponded with the
Sender: badguy.com. I know who barry at python.org is but haven't a clue
about badguy.com (or better, something just plain obscure). Would I want
to bring it to the attention of the receiver (say in the MUA) "barry" is 
more
well known now? Certainly not, because you're not. The only time you
might consider that ok is if and only if you had some warm fuzzies about
the third party signing. Which scales about as well as whitelists scale in
general, which is to say that I would expect that we'll need a *lot* more
experience to see how this actually will play out.

Note that this is not to discourage resigning by lists: it's cheap 
enough these
days that if they're there for a reasonable % of lists, it will at least 
sow the
ground for making whitelisting-like approaches more friendly (either local,
aggregated...).


(Note too that of course it's trivial to disable DKIM header cleansing 
in Cisco's own copy of Mailman.)

Right -- we found this on some non-Cisco run lists though.

       Mike

> -


More information about the Mailman-Developers mailing list