Michael Thomas wrote:
> But let's turn this around: why do you think practice is helpful? I really
> don't understand the motivation at all. Destroying information -- especially
> when you're charged with forensic exercises like spam filters are -- is
> *rarely* the right thing to do. It seems to me that the burden of proof
> should be on why removing them is the right thing, not the other way
> around.
Hi Mike,
The original rationale for removing the signature lines were the
following (at least from my point of view):
1) It was believed that Mailman would almost certainly cause the
signature to break, since it [often] adds info at the end of the
message, among other possible changes. You have since told us that
there are ways around this, but I wonder if there is a sure way for
Mailman to know if the "modes" used in signing are compatible with its
transformations (see my idea below for having Mailman re-check the sig
after transformation and reporting this fact).
2) The outgoing MTA (sendmail) milter seemed to only want to sign emails
that did *not* already have a signature. Therefore, Mailman enabled
them to re-sign by removing the old (presumably invalid anyway)
signature. At least this way *some* valid signature, even a Sender one,
could be placed on the message. This "restriction" may not apply
anymore or may be milter-specific...
And there is one more thing that, at least in my mind, made leaving the
"known bad" sig in there a bad thing: if it is destined to be invalid,
especially if there is almost no way to keep it valid, it seemed best to
remove the "doomed" signature. Even though DKIM states that bad sigs
should be treated like "no sigs", it just seemed wrong to leave known
bad sigs to potentially make the receiver think there is something awry.
Instead, having the new message signed with a new good signature that
makes the MLM responsible certainly seemed OK and better. Also, the
results of the DKIM validation by the MTA (before it gets to Mailman)
are *not* removed by Mailman, so there is a trace of the fact that (if
the MLM host's MTA did DKIM checks) the original signature passed the
test before the message was transformed, so there is a chain of trust
(i.e. the reciever trusts the MLM, and the MLM host's MTA verifies the
original sender and reports that in the header).
Now, after saying all of this, it still may be best to leave the sigs in
there. I am not convinced either way yet. I can see your point about
the forensic value. Is there a way, somehow, that Mailman could verify
the message before transformation (or the MTA could have done this) and
then again after transformation - and then indicate in the header if the
original signature has now been rendered invalid (through an as-yet
undefined header line) - and then re-sign the message again (or maybe
the MTA would re-sign it on the way out)? This could perhaps be a way
for Mailman to indicate to the receiver that an invalid From signature
is to be expected, and no alarm bells would then go off (the receiver
could then rely on the chain of trust). But if the From signature
proves to be still valid after transformation, the receiver would know
this is expected and could check this again and be even more confident,
relying on not only the chain of trust but also on the primary
signature. This would probably require adding to the DKIM spec, but it
might help to make the whole MLM situation more deterministic.
Hope that was clear...? It's hard to tell from re-reading it, since
this stuff is a bit mind-bending.
-Joe
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy:
http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
