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.
+1
But should ALICE even bother to check Bob's ADSP record (ignore ADSP)
and just forward it?
PRO:
- keep mail following, bank mail original
signature stripped, resigned and forwarded
CON:
- 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
EHLO example.com
250-....
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.
--
Sincerely
Hector Santos
http://www.santronics.com