Re: SMTP and DKIM/POLICY Rejection Handling

Hector Santos wrote:
> [...] and section 4.2.1
>
>   discardable
>
>      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.