[ietf-dkim] Concerns about DKIM and mailiing lists
leiba at watson.ibm.com
Wed Mar 15 11:12:24 PST 2006
>> One note here: the base spec COULD suggest that if the signature fails
>> to verify and the subject is signed and begins with "[", that the
>> verifier might retry after removing the "[xxx]" part. And then, much
>> as with that part of the message that comes after the signed length,
>> the verifier must decide what to do if the retry succeeds.
> Not only would that be building a heuristic into the validation portion
> of an otherwise precise security specification, it would be basing the
> heuristic on an undocumented convention that is far from universal,
> rather than on a a formal standard.
>> But in the worst case, the list has simply invalidated the signature,
>> and we say that this SHOULD be considered equivalent to no signature
>> at all. Absent SSP, this is no bad thing.
> I am inclined to agree. However the  behavior is rather common. So
> we probably should consider whether it is reasonable to have DKIM
> contain features that are intended to allow a signature survive mailing
> list transit, when we know that the final result will usually fail.
Dave, your two comments here seem contradictory: "We shouldn't try to
handle '', because it'd be heuristic, but we should try to handle ''
because it's rather common behaviour." Do you have any ideas for
handling it that don't throw us into heuristics?
I don't think there's a problem with verifiers applying some heuristics
to this, given that (1) the signature is making a weak statement, and is
not mean to be strong security and (2) this whole evaluation (the
verification) is feeding into heuristics anyway ("What do I do with the
message, given all the input I have about it?").
I appreciate Paul's comment, though, about spammers using that to their
advantages. Maybe it's part of the next-stage heuristics, where some
hypothetical verifier considers "[ietf-dkim]" to be OK, "[Buy-Viagra]"
to be <whatever>, and "[Come visit us at http://spam.example.com]" to be
junk, using whatever next-stage heuristics it chooses.
I'm just afraid that the "[listname]" custom is sufficiently common that
if we DON'T deal with it, we're throwing away too much opportunity to
play nicely with existing well-behaved mailing lists. So I'd LIKE to
try to come up with a recommendation that helps (not a requirement, and
Barry Leiba, Pervasive Computing Technology (leiba at watson.ibm.com)
More information about the ietf-dkim