Joe Peterson wrote:
> Michael Thomas wrote:
>
> 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...
>
Yes, it is specific to sendmail's milter. My milter that we use doesn't
do that.
Actually, you should probably file a bug on that because the signer
shouldn't
be paying attention to signatures from other domains. My guess is that this
was an attempt to prevent multiple signatures from the same domain, but I
haven't looked at Murray's code to verify that.
> 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.
I don't see why that follows. As I've said, I've not seen anybody whose
actually doing that in the field, and given gmail and Y! signing with DK,
a pretty large percentage of the world's legitimate email is currently being
signed.
> 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.
>
This is really the receiver's business, if you ask me. Bad receivers are
going to do bad things regardless of dkim or anything else, but that's
really their own problem. People make similar mistakes by rejecting
via SPF instead of using it as a data point in a larger filtering decision.
There's really nothing we can do about this. In fact, I'd say there is
just as high a likelihood that receivers will find that mail from domains
that normally sign their mail will look _more_ suspicious to filters if
the signature is stripped. Consider what's happening to your Bayesian
filters right now: they're being trained on DKIM-signature headers from
Cisco as being ham (I hope!) rather than spam. The lack of the signature
means less things for it lock on to...
> 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).
>
Actually, of all things that could be stripped, the verification result is
actually what could/should be stripped since it's not cryptographically
verifiable. I'm pretty simple minded: I either trust the domain that sent
me the mail or I don't. It's mailman's problem, IMO, to determine whether
the original sender should be passed through the list or not.
> 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)?
Yes, absolutely you could do this. In fact, with the milter or other similar
pieces of software your MTA will already do those things for you. I don't
really see the point of inventing a new header to do what an invalid
DKIM-signature header will already do. Especially given that a lot of the
things that you thought were invalid actually weren't.
As for whether mailman itself should sign and/or verify... I suspect that
letting the MTA do that is more expedient and will save a lot of work.
I believe at this point many/most of the MTA vendors have DKIM or
are working on them, as well as the open software community as well.
On the other hand, _using_ dkim results within mailman as an anti
spoofing mechanism might be interesting, though I really have no idea
how much of a problem that is.
> 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.
>
In general, I doubt it's going to help to convey your filtering results
because
the trust model wrong. (for the same reason we wouldn't trust the results of
your AV engine... we'll check again, thankyouverymuch :) The same goes with
the signatures: the incoming side is going to re-check them (or not!)
and draw
its own inferences based on that. Part of that is that those checks are
going to
have to deal with inevitable damage that happens -- which is a larger
problem
than just mailing lists; as ought to be pretty apparent by now, any
one-dimensional
test to determine spaminess is likely to have really terrible false
positive rates,
so fixating on just one particular feature of a piece of mail as being
the make
or break of passing isn't a very good strategy in this day and age.
Mike
> 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
