Subject: [ietf-smtp] 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: Scott Kitterman <[email-masked]>
Date: Sun, 20 Jul 2014 13:12:06 -0400

> better, please offer text!

I think your characterization of SPF is almost correct.  It generally concerns 
itself with only the domain part of the message, but it can be used to check 
authorization of the local part as well (via macros).  If you add a caveat 
before validate in "does not validate the entire address" such as (perhaps) 
typically or usually, then I think it would be correct.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Sun, 20 Jul 2014 13:30:28 -0400

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

---

From: Kurt Andersen <[email-masked]>
Date: Sun, 20 Jul 2014 10:51:15 -0700

> better, please offer text!

Aside from removing the term "elsewhere" in the penultimate sentence of
your note, which could be confusing, I think that your note is accurate.
Perhaps if you changed the last sentence to say, ". . .dropping the
erroneous sentence", the errata status would be seen more clearly.

--Kurt Andersen

---

From: John C Klensin <[email-masked]>
Date: Sun, 20 Jul 2014 14:43:40 -0400

--On Sunday, 20 July, 2014 13:12 -0400 Scott Kitterman
<[email-masked]> wrote:

>...
> I think your characterization of SPF is almost correct.  It
> generally concerns  itself with only the domain part of the
> message, but it can be used to check  authorization of the
> local part as well (via macros).  If you add a caveat  before
> validate in "does not validate the entire address" such as
> (perhaps)  typically or usually, then I think it would be
> correct.

Hi.

Speaking as editor of the hypothetical/ promised 5321bis, I
appreciate Dave's bringing the issue here, at least separating
it from what is or is not a valid erratum.   

FWIW, my editing notes on the pre-5321 I-Ds indicate that the
current text was not of my invention.   I think we should
concentrate on the substantive issue rather than casting blame,
so the person who offered the text on which people agreed
(perhaps by not paying enough attention), will, at least insofar
as it is within my power, remain anonymous for this discussion.

However, I note that Dave suggested that people send text.  I
want to reinforce that.  I was convinced, and remain convinced
that the spec if better with pointers to DKIM and/or SPF (and,
when it is updated, to anything else that may be relevant).  I
believe the consensus when 5321 was being developed was
consistent with that conviction.  So, while I will obvious do
whatever the group agrees on, my preference is to replace the
bad sentence(s) with correct ones rather than dropping them.

Especially if we have gotten this wrong once, I would really
appreciate very specific text and discussion of that text.
Statements like the above are, IMO, useful in clarifying the
issues but not really actionable where the text is concerned --
I don't want to guess, either about what text should be written
or about whether people have or have not agreed text as well as
ideas.   So, please, send text that others can comment on and
that I can eventually just past into the draft.

thanks,
   john   (presumed continuing editor of RFC2821, 5321, and
5321bis)

---

From: [email-masked]
Date: Sun, 20 Jul 2014 14:46:16 -0400

>      significantly problematic.

You are correct, neither of the methods cited in the offending sentence
in the RFC actually *validate* the return address as a usable destination
for a bounce message.  They may make assertions about "that source is
authorized to send mail with that purported address", or "that mail in fact
came from us", but those are subtly different than "Return-Path: is valid and
may be used as a destination".  And out in real life, there are actual spammers
taking widespread advantage of the salami-slicing possible between the
subtle distinction.

As such, yes, the entire sentence should be heaved over the side.

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 20 Jul 2014 14:53:15 -0400

> that I can eventually just past into the draft.

I think any reference to DKIM better belongs to a hypothetical 5322bis.  
Whatever it does, it's not related to the envelope.

I'd be glad to help with this aspect of 5321bis where I agree some reference 
to SPF would make sense (for the purposes of Dave's erratum though I think 
removing the sentence in question is the best solution).

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Jul 2014 15:13:26 -0400

On 7/20/2014 2:43 PM, John C Klensin wrote:
> current text was not of my invention.   
...
>     I was convinced, and remain convinced
> consistent with that conviction. 

Subject duly modifed, since what follows has nothing to do with
technical substance...

The SPF/DKIM text was added to the -03 version of rfc2821bis, on 25
April 2007.

In searching the SMTP mailing list archives, I am not finding any
discussion that is on point.  A brief exchange about SPF and IPv6 and
another about DKIM basic, but nothing about this text.

And the text's dealings with DKIM differ markedly from what was
discussed on the list.

So your reference to "consensus [being] consistent with that conviction"
prompts a query to what venue and discussion you are referring to?

d/

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 20 Jul 2014 23:10:03 +0200

RFCs aren't people, but if they were, I think both the SPF and DKIM RFCs 
would look strangely at your erratum and say something like "Validity? What 
does that mean, exactly? Isn't it just a pretty Latin term for what I 
define?", each in a different tone of voice.

Maybe they'd afterwards fight about whose definition of validity is better 
and what valid means. SPF would fight hard for its power to determine 
validity while occasionally pausing to exclaim dramatically that it doesn't 
even want that power.

Arnt

---

From: Franck Martin <[email-masked]>
Date: Sun, 20 Jul 2014 16:50:17 -0500 (CDT)

Yes Dave is correct in saying this is erroneous, therefore an errata.

If you want to keep the SPF and DKIM reference, you could state:

This specification does not deal with the verification of return paths for use in delivery notifications. Recent work, such as that on SPF [29] and DKIM [30] [31], has been done to provide ways to improve traceability of the message.

Printed on recycled paper!

> On Jul 20, 2014, at 9:39, Dave Crocker <[email-masked]> wrote:
> 
> Hi folks.
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: Dotzero <[email-masked]>
Date: Sun, 20 Jul 2014 16:28:57 -0400

>From a technical perspective you are correct.

Mike

On Sun, Jul 20, 2014 at 12:37 PM, Dave Crocker <[email-masked]> wrote:
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis

---

From: Dave Crocker <[email-masked]>
Date: Sun, 20 Jul 2014 19:34:49 -0400

On 7/20/2014 5:50 PM, Franck Martin wrote:
> This specification does not deal with the verification of return
>    paths for use in delivery notifications.  Recent work, such as that
>    on SPF [29] and DKIM [30] [31], has been done to provide ways to improve traceability of the message.

While they do do that, the sentence seems to me a non-sequitor and in
particular has nothing to do with the return address, per se.

So my question is how it helps the SMTP specification reader to have a
sentence like that and to have it there?

d/

---

From: [email-masked] (Wietse Venema)
Date: Sun, 20 Jul 2014 19:58:53 -0400 (EDT)

> sentence like that and to have it there?

The text, if correct, would say "SMTP does not do X, but DKIM and
SPF do Y", where X and Y are different things with some overlap.

Such text is not helpful. Let the RFC say what SMTP does not do,
and drop the reference to DKIM and SPF.

	Wietse

---

From: Franck Martin <[email-masked]>
Date: Sun, 20 Jul 2014 21:42:14 -0500 (CDT)

Toute connaissance est une réponse à une question.

> On Jul 20, 2014, at 16:36, Dave Crocker <[email-masked]> wrote:
> 

I had the feeling that by removing the last sentence you were making too much of a change therefore the rejection of the errata

Correcting the incorrect sentence may be acceptable for an errata

How is it helpful? By pointing people in a direction for further reading

---

From: Paul Smith <[email-masked]>
Date: Mon, 21 Jul 2014 09:02:22 +0100

> sentence like that and to have it there?
I think there should be something there about SPF and DKIM. There is a 
problem with SMTP to do with trustability, and SPF & DKIM both aim to 
alleviate that problem somewhat, in different ways. (Whether they're 
successful or not is a different matter, they're the best we have at the 
moment to solve their respective problems).

You, as an existing expert in email, knows all about SPF and DKIM 
already, so it's pointless for a reference to those to be in the SMTP 
standard. However, someone coming fresh to the field will find it very 
helpful if the standard essentially says "this standard has a little 
flaw, but you may want to look here or here for something which tries to 
minimise it". They may never have heard of SPF or DKIM before.

In a rewrite it may be better in an appendix or something, but in an 
errata, I think I'd change the wording to something more accurate,

-

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

---

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

On 7/21/2014 4:02 AM, Paul Smith wrote:
> problem with SMTP to do with trustability,

Fair point.

However "3.6.2. Mail eXchange Records and Relaying" seems an odd place
for background material on authentication and trust.

On reflection, I'm wondering whether that entire paragraph belongs
elsewhere, and with a different reference to spf and dkim?

d/

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Jul 2014 06:13:24 -0400

Dave,

Let me try again.   Assume, if it makes you happy, that I
maliciously inserted those sentences as an evil, malicious,
swipe at the two protocols.  If they went in for -03 (I'll take
your word for it - I didn't check), then the community had circa
seven versions of the document in which the problem, however
significant or insignificant, could have been caught (my
recollection --I don't have the time to go back and check right
now-- is that it went into Last Call around -10).  The issue
wasn't caught, or at least wasn't raised.  And, if the text was,
as I think you are saying, unchanged after -03, certainly I
didn't somehow sneak it in as a private deal with the RFC Editor
after IESG approval.  

So, there is, IMO, a choice.   We can have a discussion about
what it means that the community consensus process didn't catch
and fix this (a discussion that would almost certainly affect
other individual submission standards track documents, even
updates of long-term specs).  Or we can focus on figuring out
what the right wording should be so that I can get it into the
editing copy for 5321bis.    I prefer the latter.  YMMD.

    john

--On Sunday, 20 July, 2014 15:13 -0400 Dave Crocker
<[email-masked]> wrote:

> The SPF/DKIM text was added to the -03 version of rfc2821bis,
> on 25 April 2007.
> 
> In searching the SMTP mailing list archives, I am not finding
> any discussion that is on point.  A brief exchange about SPF
> and IPv6 and another about DKIM basic, but nothing about this
> text.
> 
> So your reference to "consensus [being] consistent with that
> conviction" prompts a query to what venue and discussion you
> are referring to?
> 
> d/

---

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

John,

You chose to introduce an assertion of community consensus about the text.

I was merely asking for its basis, since I did spent the effort to
search, but couldn't find any record of it.

d/

---

From: Paul Smith <[email-masked]>
Date: Mon, 21 Jul 2014 11:33:45 +0100

> elsewhere, and with a different reference to spf and dkim?
Absolutely. As I said - in a rewrite, I'd put it somewhere totally 
different (possibly an appendix along with other 'issues' with SMTP), 
but this is an errata, so the options may be more limited (I don't know 
- I'm not an expert on the RFC editing system)

-

---

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

On 7/21/2014 6:33 AM, Paul Smith wrote:
>>> I think there should be something there about SPF and DKIM. There
>>> is a problem with SMTP to do with trustability,
>> 
>> Fair point.
>> 
>> However "3.6.2. Mail eXchange Records and Relaying" seems an odd
>> place for background material on authentication and trust.
>> 
> different (possibly an appendix along with other 'issues' with
> SMTP), but this is an errata, so the options may be more limited (I
> don't know - I'm not an expert on the RFC editing system)

Mumble. Well, when I wrote the Errata, I couldn't think of anything that
made sense to me in that context.

Perhaps some sort of very generic language?

From:

> on SPF [29] and DKIM [30] [31], has been done to provide ways to 
> ascertain that an address is valid or belongs to the person who 
> actually sent the message.  A server MAY attempt to verify the
> return path before using its address for delivery notifications, but
> methods of doing so are not defined here nor is any particular
> method recommended at this time.

To:

    This specification does not deal with the verification of return
    paths for use in delivery notifications. A server MAY attempt to
    verify the return path before using its address for delivery
    notifications, but methods of doing so are not defined here nor is
    any particular method recommended at this time.

    Various mechanisms exist for verifying identities of different
    actors involved with the handling a message, including TLS[], SPF
    [29] and DKIM [30] [31], OpenPGP, S/MIME.

and no, I'm not in love with the wording...

d/

---

From: S Moonesamy <[email-masked]>
Date: Mon, 21 Jul 2014 06:44:08 -0700

Hi John,
>didn't somehow sneak it in as a private deal with the RFC Editor

I took a quick look to understand the history.  The sentence was 
likely added following a discussion unrelated to DKIM.  The context 
of the mail-related discussions at that time would help the reader 
understand what the issue was about.  I think that it is better to do 
nothing about the sentence.  I'll note that there was a 
pre-evaluation of RFC 5321 and the sentence was not considered as an issue.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Jul 2014 09:59:05 -0400

On 7/21/2014 9:44 AM, S Moonesamy wrote:
> I think that it is better to do nothing about the sentence. 

SM,

Really???

The sentence is factually incorrect, about basic matters of SPF and
DKIM, and these matters are commonly misrepresented and understood.

In other words, the fact that an IETF standards track document is
mischaracterizing important bits of technology is problematic to a
meaningful level.

d/

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 21 Jul 2014 14:14:57 +0000

> -----Original Message-----
> From: ietf-smtp [mailto:[email-masked]] On Behalf Of Dave
> Crocker
> Sent: Monday, July 21, 2014 6:43 AM
> To: Paul Smith
> Cc: [email-masked]
> Subject: Re: [ietf-smtp] Error in RFC 5321 concerning SPF and DKIM
> 
> >>> I think there should be something there about SPF and DKIM. There is
> >>> a problem with SMTP to do with trustability,
> >>
> >> Fair point.
> >>
> > but this is an errata, so the options may be more limited (I don't
> > know - I'm not an expert on the RFC editing system)
> 
> 
> > This specification does not deal with the verification of return paths
> > for use in delivery notifications.  Recent work, such as that on SPF
> > [29] and DKIM [30] [31], has been done to provide ways to ascertain
> > that an address is valid or belongs to the person who actually sent
> > the message.  A server MAY attempt to verify the return path before
> > using its address for delivery notifications, but methods of doing so
> > are not defined here nor is any particular method recommended at this
> > time.
> 
> To:
> 

I'm not in love with the wording but this is the best proposal I've seen so far. The original text regarding ReturnPath and SPF/DKIM is incorrect and would be misleading to someone not familiar with SPF/DKIM - and confusing to someone who does have familiarity.

Mike

---

From: "Alex van den Bogaerdt" <[email-masked]>
Date: Mon, 21 Jul 2014 16:17:51 +0200

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>
To: "Paul Smith" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, July 21, 2014 12:09 PM
Subject: Re: [ietf-smtp] Error in RFC 5321 concerning SPF and DKIM

> for background material on authentication and trust.

In case of SPF it's authorization, not authentication.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Jul 2014 10:18:58 -0400

> In case of SPF it's authorization, not authentication.

it's both.

the act of indicating that use of the client-side IP Address also serves
to authenticate the domain name portion of the return-path address.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Jul 2014 10:28:01 -0400

>and no, I'm not in love with the wording...

Since this is 5321 and not 5322, shouldn't the discussion confine itself to the envelope and message transport? It seems to me that DKIM, OpenPGP, and S/MIME are off topic. 

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Jul 2014 10:34:28 -0400

> Since this is 5321 and not 5322, shouldn't the discussion confine itself to the envelope and message transport? It seems to me that DKIM, OpenPGP, and S/MIME are off topic. 

Interesting point.  I think the choice depends on the purpose of the
sentence.

My own thinking is that the purpose is quite generic, to broadly
indicate that there is a wide range of mechanisms relevant to email.

Limiting to just the mechanisms at the SMTP-level produces a more
constrained perspective on the realm of email 'security' than is
helpful, IMO.  That is, if the reader doesn't already know about the
topic, giving them a smaller list to reference will not help them in the
way that is most helpful.

d/

---

From: S Moonesamy <[email-masked]>
Date: Mon, 21 Jul 2014 07:44:51 -0700

Hi Dave,
>Really???

Yes.

>mischaracterizing important bits of technology is problematic to a

It is one sentence and it starts with "Recent work" and provides two 
Informative references.  There were significant issues with those 
bits of technologies.  RFC 5321 does not say anything about that.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2014 17:51:22 -0000

>     http://www.rfc-editor.org/errata_search.php?eid=4055

I agree, we screwed up, the current text is wrong. We should have
caught it at the time, but we didn't.

I also agree that the corrected text should still refer to SPF and
DKIM, but not imply they can do more than they can.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Jul 2014 14:33:46 -0400

On Jul 21, 2014, at 10:44 AM, S Moonesamy <[email-masked]> wrote:

> It is one sentence and it starts with "Recent work" and provides two Informative references.  There were significant issues with those bits of technologies.  RFC 5321 does not say anything about that.
,--
Recent work, such as that on SPF [29] and DKIM [30] [31] has been done to provide ways to ascertain that an address is valid or belongs to the person who actually sent the message.
'---

This statement needs to be read where 'address' only means email-address (local-part@domain). In normal practice however, validation only assesses the domain component.  Local-part validation should be deprecated, especially where privacy is concerned.  We should be ultra-sensitive about making ownership assertions.

,==
Recent work, such as that on SPF [29] and DKIM [30] [31] was done to provide ways to ascertain whether an associated domain validate specific message elements.
'==

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Mon, 21 Jul 2014 14:49:23 -0400

> elsewhere, and with a different reference to spf and dkim?

+1

Whatever the reasons for it falling through the crack, a new section 
was needed to lump all this.

However Dave, with all due respect, it is very important to note at 
the time circa 2007, you were 100% against SPF and DKIM was your pet 
project as the preferred "Path Independent" solution. You and others 
such as Levine, would not have endorsed any SPF related discussion or 
promotion for return path validation. So what we got was probably good 
enough. If anything, it might have started a new paragraph.

-- 
HLS

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Jul 2014 15:51:11 -0400

On 7/21/2014 10:44 AM, S Moonesamy wrote:
> Informative references.  There were significant issues with those bits
> of technologies.  RFC 5321 does not say anything about that.

SM,

Sorry, but I'm confused again.

While yes, the references are informative, the sentence that uses them
is fundamentally incorrect, and ways that matter.  As for 'issues with
those bits of technologies', I'm not sure what you mean or how it is
relevant here.

The question is whether to retain the current language, replace it, or
drop it.

Given the problems with the existing text, I am not understanding your
basis for suggesting its retention.

d/

---

From: Ned Freed <[email-masked]>
Date: Mon, 21 Jul 2014 14:16:46 -0700 (PDT)

> those bits of technologies', I'm not sure what you mean or how it is

I agree with Dave about this. This text is in the context of return paths. DKIM
signs message content; it has no way to cover return paths or any other part of
the envelope, which is what RFC 5321 describes. Anyone reading this is likely
to be confused and start looking for DKIM capabilities that aren't actually
there.

The situation surrounding SPF is different. The text mischaracterizes what SPF
does, but at least SPF has something to do with return paths. Some wordsmthing
would be nice, but at least someone who goes looking for the connection between
SPF and return paths will be able to find something.

> basis for suggesting its retention.

I've yet to see any merit-based argument made for retaining the text about
DKIM.

				Ned

---

From: S Moonesamy <[email-masked]>
Date: Mon, 21 Jul 2014 14:35:40 -0700

Hi Dave,
>those bits of technologies', I'm not sure what you mean or how it is

I'll skip commenting about this to get back to the issue at hand.

>basis for suggesting its retention.

The only way I can think of to determine what to do about the current 
language is through an erratum.  The Application Area Director 
rejected Erratum #4405 because "this is a change request, not an 
errata report".

I reviewed what was published as RFC 5321 twice.  The mailing list 
archive will show that I was wrong about that sentence and that I did 
not raise an issue about it.  The YAM mailing archive will show that 
I had another opportunity to raise an issue but I did not do so.  If 
I recall correctly I did not consider the inclusion of that sentence 
as a significant issue.

I could have suggested dropping the sentence.  It did not seem 
worthwhile to argue about the sentence given that the erratum was rejected.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Tue, 22 Jul 2014 03:04:33 -0700

Hi Ned,
>SPF and return paths will be able to find something.

I am not disagreeing with Dave or you.

A look at the history of that text shows that Hector Santos flagged 
the issue as a small nit.  Tony Hansen probably didn't think that it 
was a significant issue.  I agreed with Frank Ellermann that DKIM 
doesn't look at return paths.  After taking all that into 
consideration I would not say that there wasn't consensus about that text.

The issues identified in RFC 5321 are documented at 
http://tools.ietf.org/html/draft-ietf-yam-5321bis-smtp-pre-evaluation-05 
Barry and Stephen were the DKIM WG Chairs.  They did not flag that 
sentence as an issue.  John Klensin, Alexey, Dave and Pete were aware 
of the pre-evaluation.  As John Levine mentioned, we should have 
caught this stuff.

I took a look at the Errata process.  I don't know how to fit such a 
change in there. :-(

Regards,
S. Moonesamy

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 22 Jul 2014 16:06:51 +0200

On Mon 21/Jul/2014 16:14:57 +0200 MH Michael Hammer (5304) wrote:
>> From: ietf-smtp On Behalf Of Dave Crocker
>> 
> [...] this is the best proposal I've seen so far.

+1, for the sake of inter-domain notifications.

Ale

---

From: Ned Freed <[email-masked]>
Date: Tue, 22 Jul 2014 08:18:53 -0700 (PDT)

> of the pre-evaluation.  As John Levine mentioned, we should have

All this shows is that people weren't paying sufficient attention. Far more
egregious errors that have made it past far more rigorous reviews.

> I took a look at the Errata process.  I don't know how to fit such a

Well, since it now appears that Aquinas-level scholastics are required to
understand and negotiate the errata process, I neither agree nor disagree.

What I would suggest, however, is more focus on results, less on process. To
this end, I will again point out that I've yet to hear a justification for why
we should be talking about issues solely related to message content in RFC
5321. Especially when this separation - rightly, IMO - has been used in the
past to keep issues with RFC 5322 and MIME from creeping in.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Tue, 22 Jul 2014 12:21:36 -0400

> past to keep issues with RFC 5322 and MIME from creeping in.

Because the SMTP model has evolved to a dual mode operation from one that was an always accept and process later to one that offered feasible, high scale, dynamic, online SMTP processing and that included RFC5322 (payload) processing at the DATA state. 

In fact, this evolution has extended to DMARC work expected to be done at the SMTP DATA state. Same with the new proposed RRVS header work.   Even more AVS processing is done at DATA.

So in the regard, it is all part of the 5321 process. There were a few of us during 2821bis that highlighted this SMTP evolving point that also included issues related to session delays and timeouts, i.e. make sure any any shims processing does not hang or slow down clients, 10 mins is the theoretical residence time for all scripts run at DATA, 5 mins in all other states.  We even discussed ideas related to "keep-alive" to keep clients connected that may have shorter timeouts.  In fact, as an optimizer, this is why the payload SenderID protocol has the ESMTP SUBMITTER extension that passes the payload PRA (purported responsible address) value via a 5321 return path modifier.   There were also an I-D ESMTP extension called HEAD that would allow you to pass the 5322 header block with the idea of doing more future 5322 protocols at the 5321 level before DATA is reached.

SMTP Service Extension for Command HEAD
http://www.isdg.net/public/ietf/drafts/draft-santos-smtphead-00.html

--
Hector Santos
http://www.santronics.com

---

From: Tony Hansen <[email-masked]>
Date: Fri, 25 Jul 2014 14:41:51 -0400

> I've yet to see any merit-based argument made for retaining the text about

My perspective:

When i= was considered important in DKIM, many people considered it a 
valid way to verify the identity of the sender of a message, given that

     *) it was actually used
     *) it really did map into the name used with the From: header

So the text about "belongs to the person who actually sent the message" 
could be considered a reference to the use of i=.

However, subsequent work with DKIM showed that i= was unreliable for 
that purpose, and instead should be treated as an opaque value.

At least one of the proposals floating around would have let let a 
policy supplier to declare if i= could be used in a more constrained 
fashion, such as tying i= directly back to the From: value.

So when 5321bis was being discussed, it's entire possible that some of 
the people reading it at that time really did think that DKIM COULD be 
used to help determine if the message belonged to the person who 
actually sent the message. And so, would NOT have flagged that text as 
problematic.

If I were to change the text in any fashion, it would be to change the 
words "provide ways to ascertain" to something like "provide tools that 
could help ascertain".

     Tony Hansen

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Jul 2014 15:46:10 -0400

> could be considered a reference to the use of i=.

1. While yes, some folk generating i= had that basis for it, it was
never in the spec for that.  That is, the original DKIM never
standardized anything like this at all, and the revision removed the
confusion entirely (I hope).

2. The sentence in RFC5321 could be considered all manner of possible
references, but let's try to keep things as simple as possible: the
language that is there is was incorrect when written and is incorrect now.

> that purpose, and instead should be treated as an opaque value.

Not just unreliable; the spec really wasn't document to that use.

> actually sent the message. And so, would NOT have flagged that text as

That was certainly possible. The whole d=/i= wars was due to widespread
confusion about such things, including folk who thought it was fine to
have a protocol spec be ambiguous about such things...

> words "provide ways to ascertain" to something like "provide tools that

Uh, no.  The semantics of SPF and DKIM don't really do that.  Any use in
that direction goes far, far outside of the specs.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 26 Jul 2014 10:14:18 +0200

Yes.

> that direction goes far, far outside of the specs.

That can be understood as a request for a next-layer spec.  Consider
some kind of machine-readable statement by a DKIM signer or SPF domain
owner, such that an MTA can quickly decide whether it's worth to send
a (positive or negative) DSN to an address in a foreign domain, based
on it.

To avoid backscatter, some MTAs skip sending DSNs unless they refer to
submissions --that is, they are bound for internal users.  Some other
MTA send bounces, and when I receive one I'm often tempted to ask them
why they sent it.  We need a statement that could be cited in the
footer of the readable part of a DSN, explaining why it's worth to
send such stuff to such kind of address in the given circumstances.

Ale

---

From: "John Levine" <[email-masked]>
Date: 26 Jul 2014 15:16:36 -0000

>could be considered a reference to the use of i=.

Well, yes, and no.  In retrospect, that was always a failure of
communication.  The i= bit came from people in corporate environments
where the mail system is locked down, and you can't put anyone's
return address but your own on your mail.  But, of course, there are a
lot of mail systems, and only some of them are like that.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sat, 26 Jul 2014 12:22:06 -0400

The proverbial baby out (non-list operations) was thrown out and never appropriately dealt with. If we need a "DKIM change" (errata), this would be a good one -- relax the signer domain alignment of the AUID "Agent/User Identity" as so many people wanted. Another errata would be to add the official recognition for the ADID "Author Domain Identity" which got us into this mess now by trying to dismiss its importance.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 28 Jul 2014 14:04:43 -0400

Tony Hansen

---

From: Douglas Otis <[email-masked]>
Date: Mon, 28 Jul 2014 14:11:03 -0700

Dear Tony,

See comments inline:
On Jul 28, 2014, at 11:04 AM, Tony Hansen <[email-masked]> wrote:

>> However, subsequent work with DKIM showed that i= was unreliable for that purpose, and instead should be treated as an opaque value.

Agreed.

At the time DKIM was being proposed, I suggested it should have provisions for opaque tokens for abuse feedback reporting.  Although the 'i=' tag had to be within the signing domain; it evolved into being defined as an opaque reference.  This  definition, however, could prove problematic if in conflict with processes expecting its prior definition.  It seems a safer approach would have been to deprecate the 'i=' and define a new opaque tracking tag.   Is there a survey showing this tag can be safely used as an opaque reference?

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Wed, 30 Jul 2014 11:16:36 -0400

It still can be "opaque" on the left hand side and it can still be aligned with then first party and/or third party.  The problem was the lack of a policy system, rules to verify the expectation declared by policy.  That was what made it "opaque" and quite frankly, DKIM itself is "opaque"without policy protocol.

> On Jul 28, 2014, at 5:11 PM, Douglas Otis <[email-masked]> wrote:
> 
> Dear Tony,
> 
> See comments inline: