Re: [ietf-smtp] Error in RFC 5321 concerning SPF and DKIM
Its hard to determine how much one is ignored. I know you tend to
ignore my input and thus unfortunately you fall victim of missing
these discussions during the 2821-BIS process. If you did archive
search and you say you don't see them, well, that means you
intentionally skipped over my comments.
During 2821BIS, I was among the hard core SMTP level verification
advocates as an early explorer of all the new LMAP ideas (DMP, CEP,
SPF, SUBMITTER) and new PAYLOAD ideas (DomainKeys, DKIM, SenderID).
During 2821BIS, I was asking for more recognition of the pending new
email security work going on which included SPF, DKIM and also ADSP.
I had pointed out some basic realities and mail processing evolutions:
First, changing Hardware, processing allows for more greater dynamic,
online SMTP level processing. It was no longer always an always ACCEPT
mode of operation which increased bounce requirement pressures.
Second, increasing SMTP level scrutiny (checking) requirement at each
SMTP state (connection, EHLO/HELO, MAIL, RCPT and DATA) was being done
with better SMTP level scripting callouts, shims, etc. It wasn't
always C/C++ built-in, but power was given to the admin, to explore
these new SMTP level options, and
Third, there were pending IETF "authorized" legitimate reasons for
DISCARDING mail to help avoid the accept/bounce attacks.
ADSP had a lot to do with the new section 6.2 regarding Unwanted,
Unsolicited and Attack messages and the discarding of such mail to
avoid bounces. This was the first time we provided a reason for
discarding mail and justification for not doing a bounce. Of course,
we did not want to directly reference ADSP but this where the
justification came from when stating:
So silent dropping of messages should be considered only in those
where there is very high confidence that the messages are seriously
fraudulent or otherwise inappropriate.
In other words, if you have an IETF endorsed, protocol reason, to drop
the mail, you can. At the time this was written, ADSP was still going
strong as an Proposed Standard in the DKIM-WG.
Finally, I pointed out the already existing 2821/5321 statement in
3.3 Mail Transactions
Despite the apparent scope of this requirement, there are
circumstances in which the acceptability of the reverse-path may
not be determined until one or more forward-paths (in RCPT
commands) can be examined. In those cases, the server MAY
reasonably accept the reverse-path (with a 250 reply) and then
report problems after the forward-paths are received and
examined. Normally, failures produce 550 or 553 replies.
which provides the design semantics for applying a Return Path
verification logic at the RCPT TO level first. This helps reduced
verification overhead by delaying the verification until the RCPT is
locally known. If its a remote RCPT address, then relay authorization
is required which generally negates all verification overhead.
Looking at your errata, you basically want to remove the specific SPF,
DKIM sentences and reference as examples for doing the verification.
I would agree that we don't need specifics so I agree with your errata
to remove the specifics.
However, SPF is more directly related to the Return Path verification
so its more appropriate to reference. DKIM has nothing to do with
Return Path Verification until DMARC is part of the picture.
On 7/20/2014 12:37 PM, Dave Crocker wrote:
I submitted an Errata on RFC 5321 that was rejected due to logic that is
proving a bit challenging to understand.
So I thought I'd check with the SMTP, SPF and DKIM communities to get
some broader review for the substantive issue, before considering
alternative process paths.
RFC 5321 has some text about SPF and DKIM that is
Given the continuing community confusion about what
SPF and DKIM do and do not do, I think that having
the SMTP document perpetuate erroneous views is
I've checked the archive of around the time the text was introduced.
Other that a brief exchange about the 'nature' of DKIM, I don't see any
messages on this topic.
I'd appreciate comments on the factual issues here. I don't want to
discuss the Errata process. Just the technical issues.
If folks think my characterization of the error is either correct or
incorrect, please say so and explain. If you think it can be documented
better, please offer text!
ietf-smtp mailing list