[Top] [All Lists]

Re: [ietf-smtp] Error in RFC 5321 concerning SPF and DKIM

2014-07-20 12:30:56

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.

That said...

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 cases
   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 section 3.3:

   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:
Hi folks.

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.

Simply put:

      RFC 5321 has some text about SPF and DKIM that is
      simply wrong.

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

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

<Prev in Thread] Current Thread [Next in Thread>