On Apr 17, 2006, at 11:24 PM, Hallam-Baker, Phillip wrote:
Expiry is a reason for bouncing mail??????
Which document are you reading there? Expired sig equals unsigned
at worst.
Expired sig plus other factors might lead to bounce, for example. A
transport layer verifier that sees a three week old message.... But
a client app refusing access to an expired message is the type of
idiocy we are trying to get away from.
Indeed. A signing-domain may report all messages have a valid
signature. A verifier may 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.
As you suggested, there is the required message date, but purpose of
the date is _not_ to change the validity of the signature.
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
'---
Explain the purpose of the expiry x= parameter in the signature
header field.
If expiration is about the key, include this information within the
key. By having an expiry within the key, the key could remain
available for post SMTP verifications, while also curtailing SMTP
transport acceptance of "stale" messages. Unlike the x= parameter
within the signature, when the expiry is within the key, a continuous
stream of "just-about-to-expire" messages would be far more difficult
stage.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html