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

Dave,

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


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.
>
>       http://www.rfc-editor.org/errata_search.php?eid=4055
>
> 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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp