>>NEW: If there are multiple query mechanisms listed, the choice of >>NEW: query mechanism MUST NOT change the interpretation of the >>NEW: signature. Animplementation MAY use recognized query mechanisms >>NEW: in any order.
>I think this is just opposite of my preference: > >NEW: An implementation MUST use the recognized query mechanisms in the >NEW: order presented. > >This would allow for upgraded behavior while preserving backward >compatability. Remember, senders can't force recipients to do anything, and the implicit assumption that the sender knows better than the recipient how to handle the queries seems to me utterly unwarranted. A recipient will know how to handle some set of mechanisms, and I expect that they will have an opinion about which ones they prefer because they're faster, cheaper, more informative, or whatever. If there's more than one mechanism available for a particular signature, a recipient will use the one it likes best, and even if a sender says "hey, use this other one, it's really great", there's no benefit for recipients to pay any attention, so they won't. The only rule that's going to get implemented is that receivers can use any mechanism that's available, and it's a waste of effort to attempt to mandate anything else. This will work fine for transitions since senders do have the control of which mechanisms they offer, so they can offer both for a while and eventually ditch the old one. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
