[Mailman-Developers] dkim-signature headers

[Michael Thomas]

Mark Sapiro wrote:
> Michael Thomas wrote:
>   
>> Yes, there's no question that mailman as well as lots of other software
>> can destroy signatures. In practice as people seem to actually use them,
>> it is more theoretical than real. We've been running DKIM signers/verifiers
>> for going on a year now and the 99% I quoted is across a 25000 user
>> population which probably uses mailing lists far more than most similarly
>> sized companies.
>>     
>
>
> I'm sure your statistics are valid for your environment, but I'm not
> sure that they are universally applicable. Consider what I think is a
> fairly typical situation exemplified by mailman-users at python.org. I
> don't know what fraction of incoming posts to this list are
> multipart/alternative with text/plain and text/html alternative parts,
> but I see many just from people who Cc: me directly.
>   
Just to be clear, there are hacks that we do with the length such that 
mailing
lists that insert trailers into mime structured posts still verify. This 
is done
by not signing the trailing -- and/or </body></html>. This works pretty
well. Obviously any wholesale conversions like 8->7bit or other suchlike
are going to be a problem, but at least from our vantagepoint of being a
pretty big company with a lot of mailing list use, it seems to be pretty
rare.
> It would be a fairly simple matter to go through the .mbox archive for
> any list that has one and count the number of X-Content-Filtered-By:
> Mailman/MimeDel and compare that to the number of messages. in fact, I
> just did that for a cycling club discussion list I managed, and just
> over 20% of the messages had content removed. Since the most common
> result of this is to throw away a text/html part and collapse the
> message to a single part, I submit that this will break a significant
> number of signatures.
>   

Yes, that certainly would.
> No if the only result of this were that the recipient's MTA/MUAs
> considered these messages to be unsigned, that would be OK, but my
> understanding is that in some cases at least, these messages are
> either discarded or flagged as having invalid signatures. Either of
> these alternatives is not good. The former discards wanted messages,
> and the latter trains recipients to ignore the fact that signatures
> are invalid.
>   

We haven't seen anybody doing that, and I'd certainly hope that people
don't use DKIM as the _sole_ indication of whether the message should
be rejected; the false positive rate would be far too high. In any case, the
follow on work from DKIM is the sender signing practices (SSP) work which
in a nutshell allows a signer to publish whether they sign all of their mail
or not. From the SSP standpoint, it makes no difference at all whether you
strip the broken signature or not as both count as "no valid signature". I
get the sense that people here think no signature would be better than a
broken one, but I doubt that's how things will play out, especially with
SSP.
> That said, it would be a simple matter to make the removal of these
> signature headers a site option (or even a list option, but I think a
> site option is more appropriate).
>   

I could live with that, especially if the default is to leave the signatures
alone.
> It would be better still to be able to make Mailman play better with
> DKIM so that we wouldn't have to break or remove signatures.
>   

Right... what would be good here I think is to define a "dkim friendly" 
profile
for the signing domain, mailing list configuration, as well as the 
receiver and
where this kind of profile is appropriate. It would be nice if the 
default thing
that mailman did was dkim friendly (which it mostly was until this change).

       Mike
> I note that Joe is one of the people who first identified the need to
> remove these headers. Perhaps together, we can find a better way.
>
> See
> <http://sourceforge.net/tracker/index.php?func=detail&aid=1287546&group_id=103&atid=300103>
> for some discussion.
>
>