On Jun 2, 2009, at 4:04 AM, John Levine wrote:
My suggestion is to ask some implementers. If they think it made
implementing DKIM hard, or they see value to removing it, then do so.
The biggest problem with x= is that it mainly exists to support the
false belief that senders can tell recipients what to do.
The expiry is determined at the point of delivery. When expiry
represents a fairly short interval, this would indicate a short
delivery latency should be expected.
If I sign a message with x= set to three years in the future, what's
a recipient supposed to do? How about three months? Three weeks?
Three days? Three minutes? I don't understand what is right thing
for a receiver to do with x= and I don't think anyone else does
either.
This feature is likely to become increasingly important once DKIM
plays a larger role on acceptance. This is likely to occur when IPv6
email becomes more common. At that point (not now), DKIM replay
abuse might need to be mitigated through the use of expiry feature.
Without this feature, rapid key roll-overs would create havoc whenever
these results are analyzed at some point beyond delivery, as is often
the case.
A reasonable verifier can completely ignore x= and still get the
right result in all non-silly cases, which tells me that x= should go.
This would be the wrong conclusion to draw, because this is based upon
current usage which places little reliance upon DKIM, and as such,
this means there is also less motivation to abuse this protocol.
The x= and the l= are both features aimed at improving DKIM robustness
in the presence of less than ideal handling.
These features should remain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html