ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll

2006-04-18 09:42:40

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