On Apr 7, 2006, at 1:53 PM, Stephen Farrell wrote:
So a signature expiry failure doesn't mean message rejection, same
as if the signature check failed because the message was mangled.
The bane of DSNs are minimized when MTAs follow consistent rule-sets,
as SMTP is a store and forward protocol. Bad actors are notorious
for exploiting MTAs changing rule-sets. The DKIM draft unfortunately
is lax in this respect, where this is especially true with respect
the implementation of policy. The DKIM draft has not ensured a
consistent basis for rejection. Just the opposite. The per message
per second timing of a message expiry appears to be a gift to the bad
actors, although this exploit could be accomplished employing trick
DNS servers tracking messages via their key-selectors and returning
no keys upon a subsequent query from a different address space.
DKIM is an excellent tool for identifying which domain has handled
the message. DKIM may also be an excellent tool for exploiting the
store and forward nature of email.
Delayed acceptance, reporting, and self-revocations causing deletions
are safer strategies.
--- Optional Reject
3.4.5 Body Length Limits
...
Note that verifiers MAY choose to reject or truncate messages that
have body content beyond that specified by the body length count.
--- Optional Reject
3.5 The DKIM-Signature header field
...
d= The domain of the signing entity (plain-text; REQUIRED). This
is the domain that will be queried for the public key. This
domain MUST be the same as or a parent domain of the "i=" tag.
When presented with a signature that does not meet this
requirement, verifiers MUST either ignore the signature or reject
the message.
--- What is the prime purpose for expiry? To act as a fuse?
x= Signature Expiration (plain-text; RECOMMENDED, default is no
expiration). Signature expiration in seconds-since-1970 format as
an absolute date, not as a time delta from the signing timestamp.
Signatures MUST NOT be considered valid if the current time at the
verifier is past the expiration date. The value is expressed as
an unsigned integer in decimal ASCII.
INFORMATIVE NOTE: The x= tag is not intended as an anti-replay
defense.
--- Treat invalid signatures with suspicion?
6.2 Extract the Signature from the Message
Since there can be multiple signatures in a message, a verifier
SHOULD ignore an invalid signature (regardless if caused by a
syntactic or semantic problem) and try other signatures. A verifier
MAY choose to treat a message with one or more invalid signatures
with more suspicion than a message with no signature at all.
--- Clearly an invalid signature is to be rejected.
6.6 Interpret Results/Apply Local Policy
...
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
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html