On Apr 7, 2006, at 12:52 PM, Paul Hoffman wrote:
At 12:01 PM -0700 4/7/06, Michael Thomas wrote:
Paul Hoffman wrote:
If what the WG wants is signatures whose life is the time of
transit, we should say that in the protocol definition, not
optionally in each message.
The alternative is to just put normative guidance in the document
to the effect that x= MUST be greater than t=+2weeks, and less
than t=+2 months or something, and that it SHOULD be set to t=+4
weeks.
That is an alternative, but I would ask "why use that alternative".
Unless x= is compelling, and compelling enough to overcome its
faults, why even put it in with these suggested knob-settings? I
claim that it is not compelling, particularly if the document says
what the purpose of DKIM signatures are.
Those interested in assuring acceptance of their messages will allow
an adequate delivery time. There should be no need to make
recommendations for the delivery period.
The x= parameter becomes problematic when it allows less than a
nominal processing time for possible downstream systems, for whatever
valid reason. If an MTA is forwarding messages, and these forwarding
agents are known, then bad actors sending messages to forwarded
accounts may be delighted to find their messages are subsequently
rejected due to an expired signature by some down stream MTA. : (
Bounced messages due to an expiry might create a problem worse than a
replay issue, as the bounce sources would otherwise be considered
reputable. : (
One protective strategy for the forwarding agent would be to not
accept messages with less than some period of time remaining. Of
course, the downstream system might be doing the same thing,
thwarting this strategy for avoiding down stream rejections. The
converse of not rejecting until some period after the expiration
suffers the same syndrome. There does not seem to be a safe
solution. Is there a strategy that would be safe?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html