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

[Stuart Gathman <[e-mail]>]

On 07/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!
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.

> (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.)
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.