[Top] [All Lists]

Re: SMTP and DKIM/POLICY Rejection Handling

2009-10-20 10:36:27

Alessandro Vesely wrote:

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?

Good Question. :)

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.


But should ALICE even bother to check Bob's ADSP record (ignore ADSP) and just forward it?


  - keep mail following, bank mail original
    signature stripped, resigned and forwarded


  - Bank is a spoofed domain submission

  - membership with ADSP receivers can reject

  - memberships can get subscription removal due
    to exhausted retries.

If we assume all ADSP receivers will always follow a silent discard rather than reject, then the CON reduces to the unprotected spoof domain submission risk.

I think the bank should not be using a ADSP "discardable" if it knows it is going to submit mail to a DKIM ready remailer not supporting ADSP. So this is the bank's problem to fix.

But I think its probably better to just filter it and maybe notify the bank it has a "configuration" problem. That might help reduce the problem of ADSP compliant SMTP receivers rejecting mail.

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

I believe the above means that the 5322 headers the DKIM signature bound in the hash defined with the h= tag, i.e. h=From:SubjectTo:Date etc should not be removed from the 5322 headers when the 5322.DKIM-Signature header itself is stripped.

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.

Yes, +1.

But maybe not when the reason is a remailer breaking/forwarding ADSP protected domain messages.

Maybe we do need a specific temp rejection code here that says

    453 4.5.3 ADSP rejection

to avoid issuing a 250 message acceptance. 453 might tell the remailer that what it did should probably be address short of not sending subscription removal notifications to members.

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"?

Well, the reality is that both type of SMTP systems exist and increasingly so with faster machined, better scaled and dynamic processing, do perform DATA analysis rather than wait to after the message is accepted. This helps mitigate the accept/bounce attack problem.

So it should be expected that lacking specific handling guidelines, you will find a growing amount of SMTP implementators like David Macquigg perform this task at the DATA state.

Your dkim=rejectable idea is good, but do we really need to have both?

Of course, RFC5617 should be covering this better :)

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.

Not in my life time.:)

I think ideally I could see a rejection code that maybe tells the client "No Need to Forward" a bounce. I believe that is the motive of ADSP discard - to reduce backscattering.

Maybe a SMTP extension can do that, call it a NoBounce

  250 NOBOUNCE xyz

where xyz is the optional code used to instruct the client it should not create a DSN for an xyz rejection.

This will assist new augmented 5322 DATA processing technology to create a NoBounce rejection without the need to do a message acceptance.

I like this better than to perpetuate ideas like discarding of mail after message acceptance.


Hector Santos