Subject: [spfbis] Error in RFC 5321 concerning SPF and DKIM

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Jul 2014 12:37:25 -0400

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!

(I've BCC'd the SPF and DKIM lists, to make sure that everyone there
sees this.  But please post any followups to the SMTP list.)

Thanks!

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stuart Gathman <[email-masked]>
Date: Mon, 21 Jul 2014 11:31:28 -0400

> better, please offer text!
Well, the obvious problem is that DKIM does not address RFC 5321 MAIL 
FROM at all!  (It can address the Return-Path header field.)

As far as SPF goes, what do they mean by "valid"?
1) capable of delivering a DSN (MAIL FROM <>)  - SPF does not address 
this at all
2) used in an ethical and constructive manner (see FUSSP) - SPF does not 
address this either
3) used by MTAs authorized by the domain in the domain part via DNS - 
this is what SPF actually does

Your comment was incorrect about not "validating" the entire address.  
SPF does, in fact, provide a way to "validate" (authorize) the localpart 
via macros (a feature protested vigorously by some).

Note, while DKIM is a way for the MTA to sign emails and selected header 
fields, by signing the From header field, this effectively "validates" 
the From address as being part of a message authorized/signed by an MTA 
that knows the private key of the public key published in DNS for the 
domain.  This is irrelevant for RFC 5321, however, which is concerned 
with the SMTP envelope.

As to "belongs to the person who actually sent the email", that is the 
province of end to end crypto (see PGP MIME).  No MTA protocol can 
address that.

> sees this.  But please post any followups to the SMTP list.)
I'm not currently on the SMTP list.

As to the acual text, I wouldn't delete it - you DO want to mention 
other standards attempting to address the problems implied by the word 
"valid address".  While DKIM does not address the SMTP envelope, it is 
still a good pointer.  The main thing is that RFC 5321 does not address 
the problem, and the existing text makes that clear.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Jul 2014 13:23:06 -0400

Please reply to the smtp list.

As I indicated, that is where the discussion on this is happening.

Thanks.

d/

> As far as SPF goes, what do they mean by "valid"?
...