On Apr 19, 2006, at 3:54 PM, <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
<Bill(_dot_)Oxley(_at_)cox(_dot_)com> wrote:
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."
Some MTAs are known to forward email. Stringent examination is
required based upon the principle a sewer pipe must never become
smaller. The changed expiry text makes the x= parameter optional,
but then excludes concerns regarding subsequent message rejection on
that basis.
There was another minor change that used [received] time rather than
[current] time to better define rules for various transports. This
was also to introduce the concept that there is a time interval
between the received time and when the message may be forwarded. An
MTA can not continuously evaluate these message expiries. When an
MTA does not have a rate-limiting mechanism to handle in-hand expiry,
the only safe practice would be to refuse messages that require such.
base-01:
,---
| It is beyond the scope of this specification to describe what actions
| a verifier system should make...
|
| If the verifying MTA is capable of verifying the public key of the
| signer and check the signature on the message synchronously with the
| SMTP session and such signature is missing or does not verify the MTA
| MAY reject the message with an error such as:
|
| 550 5.7.1 Unsigned messages not accepted
|
| 550 5.7.5 Message signature incorrect
'---
An effort subsequent to completion of the base draft is aimed
specifically at providing a mechanism for the signing-domain to
report that all messages have a valid signature. A verifier can act
upon that information and reject all messages purported to be from
_that_ domain without a valid signature. An expired signature is
defined as _not_ being valid.
A safer practice would be to allow the receiver to evaluate the time
the message was posted or signed. There is a significant risk
changing the validity of a signature on a per second basis, largely
due to policy issues and foul play. A slew of DSNs could be harmful
to the reputation of the MTA.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html