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