[Top] [All Lists]

Re: SMTP and DKIM/POLICY Rejection Handling

2009-10-18 13:58:59

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 remailed.

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.