[Mailman-Developers] dkim-signature headers

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Feb 7, 2007, at 4:31 AM, Stephen J. Turnbull wrote:

>> Let me float this though: how about a "signature friendly" knob that
>> configures the list to not do things that are known to be harmful to
>> signatures (including s/mime and pgp for that matter). I don't think
>> this needs to be _especially_ complicated, but it would probably need
>> to be fleshed out.
>
> [ Actually, for Mailman 3 it would be nice to have a general "theme"
>   engine that handles this kind of thing. ]

And I'm strongly in favor of having such a framework.

> I think as a practical matter it's only a matter of time before this
> becomes a FAQ in *both* directions (people who are having problems
> similar to Joe Petersen's as well as those similar to Cisco's).  So I
> agree here.

Yep.

> I would answer Barry that Mailman SHOULD preserve existing signatures
> because the spec will get language saying
>
>   o signers SHOULD NOT refuse to re-sign
>   o policy agents SHOULD report only successes by default
>   o policy agents MAY provide an option to acquire information about
>     failures
>
> In particular, in section 6.1,
>
>       INFORMATIVE NOTE:  The rationale of this requirement is to  
> permit
>       messages that have invalid signatures but also a valid signature
>       to work.  For example, a mailing list exploder might opt to  
> leave
>       the original submitter signature in place even though the  
> exploder
>       knows that it is modifying the message in some way that will  
> break
>       that signature, and the exploder inserts its own signature.  In
>       this case the message should succeed even in the presence of the
>       known-broken signature.
>
> I'd like to see that last "should" in all uppercase<wink>.  Then
> (sorry, Barry!) IMO the burden is clearly on Mailman and other list
> manager projects to either implement signing themselves, or publish
> their own BCPs strongly recommending use in combination with an MTA
> that will do the signing.

I agree.

> What I really fear is that
>
>     (1) everybody's intuition is that a failed verification is a
>         positive indicator for spam (as compared to no signature, as
>         well as compared to verified signature), and they want to
>         apply policy filters based on that---we can expect that lots
>         of people (and let's not forget AOL) will (ab)use the
>         information that way, and
>
>     (2) we've already seen list-hostile implementations in the wild---
>         we can expect that there will be more.
>
> Both of these are evidently conformant to the current spec.

I echo Steve's fear.  I think without clarifying language, that's  
exactly what we'll see.  We'll probably see it anyway, but at least  
when Mailman gets screwed, we can at least point to the spec and say  
"you're being unfair to us!".

>> Destroying information -- especially when you're charged with
>> forensic exercises like spam filters are -- is *rarely* the right
>> thing to do.
>
> True, but this is a Pythonic bunch.  "Practicality beats purity." :-)

Indeed.

Let me bring this back around to the question of what Mailman should  
do.  Clearly we aren't going to implement DKIM verification and  
signatures in Mailman 2.1, although it would not be unreasonable to  
add such a handler modules as unsupported contributions.  Is anybody  
motivated enough to implement them?  I could see such handlers  
becoming officially supported in Mailman 2.2/3.0.

What should MM2.1 do now?  Here's a proposal for 2.1.10: Add an  
mm_cfg.py variable that controls whether DKIM headers are stripped or  
not.  I think Mark suggested that this should be a site-wide  
variable, and I tend to agree.  The reasoning being that all the  
outbound Mailman traffic will be ultimately delivered by an MTA under  
the site admin's control.  Either they have a milter that refuses to  
resign or they have a working milter.  If their milter doesn't  
resign, then less harm is done by stripping the header.  If their  
milter does resign, then less harm is done by allowing it to resign,  
even if Mailman has broken the original signature.

I don't think there's any feasible way for MM2.1 to determine whether  
its transformations break the original signature or not, but that  
infrastructure could be built into Mailman 2.2/3.0.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRcnxCnEjvBPtnXfVAQKr0QQAmXahpxy7V6fRXJJb3rFaruS529hWHKeS
QliPVV1CBdNFqCfsYGVkDKGMV/vdUvOdoOHgougIrWEjYZdlWp82LRzoWbjR4MS+
H0hMkUENuZA2oO/iBQ8K7hBlGoRLhHc2x8odyR0YhcMWBbDrq6I8ICSYrd3kMTu7
sFEOCGBTpFA=
=7tCs
-----END PGP SIGNATURE-----