Re: SMTP and DKIM/POLICY Rejection Handling
Hector Santos wrote:
[...] and section 4.2.1
All mail from the domain is signed with an
Author Domain Signature. Furthermore, if a
message arrives without a valid Author Domain
Signature due to modification in transit,
submission via a path without access to a
signing key, or any other reason, the domain
encourages the recipient(s) to discard it.
Failed DKIM validation is to be treated as if no signature is present.
which violates RFC 5617 DKIM=DISCARDABLE policy which would justify a
SMTP level rejection or POST SMTP message acception silent discard.
Actually doesn't. Broken signatures tantamount missing ones, which
avoids the problem of checking whether a message had actually been
Can you elaborate?
The snippet quoted above from sec. 4.2.1 identifies three cases, one
of which is remailing, but suggest to treat all of them the same way.
Therefore no violation can result from that.
That still leaves the remailer's problem. Say Alice runs a mailing
list that requires specific subject-prefix and footer, and Bob posts a
contribute that contains neither of them. Now, if the contribute comes
from a bank that signed the subject and omitted the l= tag for the
body length, and the bank's ADSP RR is "dkim=discardable", what should
Alice do? Her choices are to either pass it, possibly removing the
broken signature, or reject the contribute, requiring that Bob adds
the subject-prefix and the footer himself. In facts, after verifying
the signature, Alice can safely send a bounce to Bob, and explain the
issue in full detail. As for possibly discarding broken signatures
--which would seem to just save the recipients some CPU cycles, since
the effect is the same-- RFC 4871 sec. 4.2 says
Signers SHOULD NOT remove any DKIM-Signature header fields from
messages they are signing, even if they know that the signatures
cannot be verified.
Does that mean Alice may remove the broken signature only if she does
not in turn sign the message --i.e. she is not a signer? Hm...
Alas, "dkim=rejectable" is not provided for: this is
consistent with the current trend of undermining SMTP's reliability.
So you suggest a specific "dkim=rejectable" would apply for SMTP rejects
and "dkim=discardable" for post message acceptance silent discards?
Rejection is probably safer in most cases; rejecting after receiving
the body should never be misinterpreted as a non-existing recipient,
by a mailing list agent.
I don't think domains declaring a "actionable" ADSP policy such as a
DKIM=DISCARDABLE|REJECTABLE really care how a SMTP verifier deals with
ADSP policy violation other than to suggest "get rid it, don't accept
it" - they don't want to claim any responsibility for the broken
DKIM/ADSP message and is providing explicit receiver handling suggestions.
That sounds reasonable. (RFC 5016 just talks about "great suspicion".)
Do you mean they used "discardable" for "either droppable or rejectable"?
But I agree that the RFC should correctly apply for both SMTP message
handling implementation methods.
The "drop" method is described in RFC 5321, sections 6.1, 6.2, 7.8,
and 7.9, using a somewhat intricate set of inner references. That way
RFC 5321 manages the tradeoff between reliability and safety. However,
formal references to that handling method are not straightforward.
[moved from above]
IMHO, we need an SMTP extension that explicitly binds anti-spam
checks with the appropriate SMTP behavior.
I am not sure we need an SMTP extension for this, IMO, codifying new
5321/5322 related standard track specifications could also resolve
conflictive guidance for implementators.
The advantage of an extension is to mention a handful of existing
anti-spam checks directly, allowing future changes either via further
extensions or rewritings of the same spec. The new SMTP spec will be a
Full Standard, not expected to change any time soon.