On 26 May 2011, at 14:40, John R. Levine wrote:
So this tells me that existing mail software doesn't try very hard to
recover signatures from modified messages, even for simple changes that
don't need any guessing or heuristics to undo.
My client found the signature, otherwise it would not have commented on its
validity. It just wasn't able to verify it.
Hmmn. How does it like the copy of this message sent to you directly? The
signature was definitely good on the way out.
I think the long term solution would be for mailing list software to stop
mucking around with the message body, and for MUAs to work better at
exposing meta data added by lists (like the list-unsubscribe header).
Actually, I think the long term solution is for people to stop pretending
there is a problem. Can you describe the operational problems you're
experiencing here? "Broken signatures" is a fact, not a problem. Mailing
lists have worked quite well for 40 years with no signatures at all, making
all sorts of random changes to the mail, so it has to be something more than
that.
Also, if you're suggesting changes to list software, please explain why they
would have greater benefits than the obvious and simple one to have lists add
their own signature on the way out.
Oh, and actually, I'm not proposing changes to list software. The software that
I use for lists is quite capable of passing unaltered bodies and subject lines.
However, list operators don't like to do that because they have no other way of
adding meta-data in a way that's visible to users.
What I'm suggesting is that MUAs should be modified to expose List-* headers in
a way that's useful to end users. At that point, most of the motivation for
mucking around with messages would disappear. Also, done well, the utility of
the meta-data could be improved. Increased safe passage of DKIM signatures
might be regarded as a positive benefit with respect to motivating DKIM
deployment.
--
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html