Re: [ietf-dkim] Concerns about DKIM and mailiing lists

> > 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 
not perfection).
Barry

--
Barry Leiba, Pervasive Computing Technology  
(leiba(_at_)watson(_dot_)ibm(_dot_)com)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html