Why would a verifyer refuse a message that had a value for x=?
"Verifiers MAY support checking of x= values or may refuse to
accept messages with the x= tag."
thanks,
Bill
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Douglas Otis
Sent: Wed 4/19/2006 6:01 PM
To: Stephen Farrell
Cc: ietf-dkim
Subject: Re: [ietf-dkim] Attempted text for x= with DSN considerations
Proposed:
x= Signature Expiration (plain-text, OPTIONAL, default is
no expiration). The format is the same as the "t=" tag,
represented as an absolute date, not as a time delta from the
signing timestamp.
Verifiers who support x= should consider a signature invalid
when the [received] time at the verifier is past the
expiration date. Verifiers that do not support x= and
forward messages, may refuse acceptance of messages
when the x= tag is present to avoid causing DSNs.
When a signature becomes invalid, and is not accepted by a
subsequent MTA, a mechanism to rate-limit initial senders
may be required to control the level of DSNs. If a signature
is initially found invalid for this reason, then normal rules
apply, so the signature SHOULD be treated the same as if
cryptographic checking had failed, or as if the public key
could not be retrieved.
Verifiers should not assume that there is any particular
relationship between the x= value and the life cycle of a
public key. Signers MAY include an x= value at their
discretion.
Verifiers MAY support checking of x= values or may refuse to
accept messages with the x= tag. The value is expressed as
an unsigned integer in decimal ASCII, with the same constraints
on the value in the "t=" tag. The value of the "x=" tag MUST
be greater than the value of the "t=" tag, if both are present.
INFORMATIVE NOTES:
1) Messages with invalid signatures or x= parameters
may be rejected by subsequent MTAs.
2) When the signer has no reason to include any
particular value, then this tag is better omitted.
3) There is no particular reason to include values far
into the future, e.g. if it expected that a verifier
might not see the message for a long time. In such
cases omitting x= will probably be better.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html