ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Mailing lists and s/mime & dkim signatures - mua considerations

2010-08-25 11:21:29
  On 8/25/10 5:32 AM, Hector Santos wrote:
Sonneveld, Rolf wrote:
Let's keep it clear: a broken signature is to be ignored
(base DKIM spec). But removing signatures without a good reason
is wrong.
A good reason is to lower the confusion of an unknown assessment
world, especially when the LAST SIGNER is taking responsibility and is
the presumably the only "vounch-able" entity but the unknown
non-standard reputation filtering engines (RFE) advocates.
Agreed.  When a mailing list manager (MLM) flattens messages, modifies 
subject lines, and appends unsubscribe information, the mailing list 
manager and _not_ the author should be considered to represent the 
entity introducing the message into the mail stream.  As such, broken 
signatures represent an unnecessary consumption of resources.

Mike Thomas advocated use of the -l body length option with header 
copies to recover most, but not all, signatures using various unknown 
heuristics.  Unfortunately, the -l option can lead to an exploitable 
situation when a message is accepted because it was signed, but 
recipients remain unaware of unsigned portions.  Since not all 
signatures can be recovered, this either exposes recipients to possible 
exploitation, or it creates support issues when messages or portions 
thereof are dropped when recovery fails.  It also seems unrealistic to 
expect adoption of a message display convention to highlight which 
portion of the message body was signed by various signatures.  Use of 
the -l parameter should be considered a bad practice that should be 
deprecated, and too much to ask of MUAs to properly support.
What is your reason for keeping a broken signature?  Do you have an
RFE that can utilize this information?
None that I can imagine, beyond the practice advocated by Mike Thomas.

-Doug

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html