Subject: [Emailcore] Issue #30 - Erratum 4055: Description of SPF and DKIM is wrong

From: Todd Herr <[email-masked]>
Date: Wed, 17 Mar 2021 16:27:44 -0400

The text of the subject ticket reads:

Dave Crocker wrote:

Section 3.6.2 says:

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.

It should say:

This specification does not deal with the verification of return
paths for use in delivery notifications.

Notes:

Neither SPF nor DKIM determine "validity" of an address. SPF determines
whether an IP Address is 'authorized' to send mail with a particular domain
name in the return address, but that does not validate the entire address,
nevermind validating any destination or author addresses. DKIM has nothing
at all to do with any existing address or domain name elsewhere in the
message.

So I suggest merely dropping the problematic sentence.

The full text of the paragraph at issue reads:

   This specification does not deal with the verification of return
   paths for use in delivery notifications.  Recent work, such as that
   on SPF [29 <https://tools.ietf.org/html/rfc5321#ref-29>] and DKIM
[30 <https://tools.ietf.org/html/rfc5321#ref-30>] [31
<https://tools.ietf.org/html/rfc5321#ref-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.

I second Dave's suggestion, and propose that the paragraph be edited to read:

   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.

I propose 31 March as the deadline for discussion on this ticket.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [email-masked]
*m:* 703.220.4153

`

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Mar 2021 13:52:59 -0700

On 3/17/2021 1:27 PM, Todd Herr wrote:
>     paths for use in delivery notifications. A server MAY attempt to verify the return

I think the intent, here, is reasonable, but the second sentence is 
problematic.  It uses normative language for a non-specification.

In terms of the scope of a specification, implementations are always 
free to do things that are outside that scope.  The specification has no 
business purporting to give permission.

That is, normative language needs to be restricted to text that 
specifies actual protocol or format details.

Similarly language like 'at this time' turns out not to have any real 
meaning in a specification produced by the IETF.  Statements implying 
possible future activity or changes really are meaningless.

So, perhaps a small tweak:

      This specification does not deal with the verification of return 
paths for use in delivery notifications. Server efforts to verify the 
return path using it is outside the scope of this specification.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Wed, 17 Mar 2021 20:02:20 -0400

--On Wednesday, March 17, 2021 13:52 -0700 Dave Crocker
<[email-masked]> wrote:

>       This specification does not deal with the verification
> of return paths for use in delivery notifications. Server
> efforts to verify the return path using it is outside the
> scope of this specification.

Dave,

I cannot attach a clear antecedent to "it" in the second
sentence and, of course, "Server efforts... _are_".  Did you
intend something closer to:

	Server efforts to verify a return path for that purpose
	are outside the scope of this specification.

(which more clearly points back to delivery notification) or

	Server efforts to verify return paths are outside the
	scope of this specification.

(those efforts are out of scope whether for delivery
notification or any other purpose) or even

	Mechanisms that might be used by servers to verify
	return paths are outside the scope of this specification.

(somewhat more extensive in coverage but perhaps closer to the
principle that verification issues are out of scope)

best,
   john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Mar 2021 17:23:43 -0700

>> scope of this specification.

To clarify and make more crisp:

        This specification does not deal with the verification of a 
return path. Server efforts to verify a return path are outside the 
scope of this specification.

d/

---

From: John C Klensin <[email-masked]>
Date: Thu, 18 Mar 2021 10:25:29 -0400

--On Wednesday, March 17, 2021 17:23 -0700 Dave Crocker
<[email-masked]> wrote:

> of a return path. Server efforts to verify a return path are
> outside the scope of this specification.

Dave, this is at least as reasonable as any of the suggestions I
made in the note pointing out the problem with your earlier
text.   Unless someone objects or has a yet-better suggestion,
I'll incorporate it into the working version of 5321bis.

My only concern is that there may be a substantive difference
between saying:

 * Out of scope and you are on your own
	   and
 * Servers MAY try to verify if they can find a way to do
	so that they consider appropriate

The latter, even without references, is a bit closer to
reflecting (or at least hinting at) with supposed current
practice and is closer to the intent of the paragraph we are
replacing.

I'm agnostic about that choice, but would like to understand WG
consensus on the topic rather than excluding the second option
because we have gotten hung up on worthsmithing the first one.

    john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Mar 2021 09:59:14 -0700

> 	so that they consider appropriate

There's a big difference.  The latter is normative bloat.

It is pretending to specify something when, in fact, it isn't specifying 
anything.

Validation isn't precisely defined -- and, yes, it can have different 
meanings -- and the procedure for it isn't defined.  Out of scope means 
out of scope.  Giving people 'permission' to do something out of scope 
is pretending it isn't out of scope.

> practice and is closer to the intent of the paragraph we are

If the goal is to specify current practice, then none of the candidate 
text does that. It needs to be explicitly within scope and it needs to 
be concretely specified.  (I'm not advocating for doing that.  Quite the 
opposite.)

Commenting on the range of practices that are outside the scope of the 
specification but are nonetheless interesting isn't the job of a 
protocol specification.  Whether it is in scope for a BCP is a separate 
discussion.

d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 19 Mar 2021 12:56:50 -0400

Dave,

--On Thursday, March 18, 2021 09:59 -0700 Dave Crocker
<[email-masked]> wrote:

> There's a big difference.  

If I didn't think there was a difference, I would not have said
anything.  
 
> The latter is normative bloat.

> It is pretending to specify something when, in fact, it isn't
> specifying anything.
> 
> Validation isn't precisely defined -- and, yes, it can have
> different meanings -- and the procedure for it isn't defined.
> Out of scope means out of scope.  Giving people 'permission'
> to do something out of scope is pretending it isn't out of
> scope.

See below.

> If the goal is to specify current practice, then none of the
> candidate text does that. It needs to be explicitly within
> scope and it needs to be concretely specified.  (I'm not
> advocating for doing that.  Quite the opposite.)
> 
> Commenting on the range of practices that are outside the
> scope of the specification but are nonetheless interesting
> isn't the job of a protocol specification.  Whether it is in
> scope for a BCP is a separate discussion.

Dave, I am a strong supporter of a narrow scope for any
modifications to 5321 and 5322 and have been taking that
position consistently since discussions of revising the
documents to create Internet Standards first started (IIR when
Alexey was still AD).  I proposed the idea of a supplemental
Applicability Statement [1] precisely as a way to provide a
place for range of practice (your words) discussions without
drawing them into the text of either of the base documents.  So
please don't lecture me on that subject.

However, the boundaries of what is, or is not, out of scope are
less exact than your statements above and on other matters would
seem to imply.  The boundary is, IMO, especially fuzzy when the
discussion is not about adding something new but about replacing
or removing text that came out of DEUMS and/or YAM --WGs that
had more broad participation than this one seems to and that
operated at a time when the IETF as a whole seemed much more
interested in the details of how core email protocols worked and
were defined that it appears (at least to me) to be today.  You
have your opinions, I have mine (and we might even agree -- my
presenting a possibility is not a position in its favor) but the
decision as to what is, or is not, out of scope is ultimately
the province of the WG Co-chairs and the WG itself, not your
beliefs or mine.  If you want to ask the Co-chairs for a
consensus call on whether some proposal is in scope or not, by
all means do so.  If you don't like the answer, by all means
appeal to the IESG (although I note that the number of times in
my memory that the IESG has pushed back on a specification that
had WG consensus just because it pushed the boundaries of the WG
charter have been few indeed).  To me at least, the argument
that discussions of this topic are out of scope are particularly
dubious given that the charter specifically calls out addressing
existing, pre-WG, errata as part of the WG's mission.

Again at least from my perspective, demeaning particular
suggestions (or their authors) by describing them as "normative
bloat" or "pretending to specify something when, in fact, it
isn't specifying anything", is not helpful either. Even though I
will defend your right to have those opinions and express them,
almost any use of MAY in almost any IETF specification could be
attacked on similar grounds.

But, otherwise, can we try to have discussions about substantive
matters, such as different possible ways to address a specific
and in-scope topic, rather than engaging in what appears (at
least to me) to be an effort to suppress such discussion by
claiming that any position with which you disagree is out of
scope.

thanks,
    john

[1] Whether that should be a BCP instead, or whether there
should be an A/S and a BCP are separate issues.  However, if you
want to focus on scope consistent the charter, I note that it
says "Applicability Statement" and indicates that any other
documents are out of scope until work on 5321bis, 5322bis, and
that A/S are completed.  If you believe that a narrow
interpretation of the charter is the best way to move the WG
forward, then suggesting something about a BCP is inconsistent
with that position.

---

From: Hector Santos <[email-masked]>
Date: Fri, 19 Mar 2021 13:05:37 -0400

> scope of this specification.

-1

Here is why:

For the record, since RFC2821 and now RFC5321,while described as 
beyond the scope of the document as to how validation can be done, it 
does describe the idea for a client/server protocol negotiation 
considerations for the acceptability of the the return path in 
section: 3.3:

https://tools.ietf.org/html/rfc5321#section-3.3

                                                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.

(Note: This will save at least X% of return-path validation when X% of 
the RCPT fails).

It has nothing to do with whether it is easily spoofed or not, the 
return path MUST be valid for the purposes of returns.  It can't be 
any "random" address per se.  It should be validated.  SPF allows one 
form of validation.  Call Back Verification (CBV), a concept employed 
since Caller-ID Modem days, has been applied to SMTP.  It has been the 
#1 rejection method for invalid return paths within our wcSMTP package 
since 2003.

Due to CBV overhead, I would never recommend it as a IETF standard. 
However, empirical data collected daily since 2003 has solidify the 
high payoff of a CBV operation.  It is a local policy option in our 
package.

That said:

I would not recommend editing SPF RFC4405 to remove its validation 
statement. Validation is the main purpose for using the SPF 
mechanism.  Why else would you use it?  Again, it has nothing to do 
whether it is can be spoofed or not, the return path MUST always be a 
valid address per RFC5321. If not, then, imto, it is easily 
classifiable as rejectable mail transport identity.

Thanks.

-- 
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Mar 2021 10:45:36 -0700

> If I didn't think there was a difference, I would not have said

Is it ok that we agreed?  Your comment seems to imply a problem.

> seem to imply.

Not sure what exactly you are claiming isn't exact, on this matter.

As I said in my note, if the item is in scope, then it needs substantive 
specification.

If it isn't, then there is no basis for making a normative statement 
that has no substance.

Based on the existing specification -- which provides no substance on 
this matter -- it is out of scope.  (And my own view is that it /should/ 
be out of scope.)

> The boundary is, IMO, especially fuzzy when the

Fuzzy specifications.  An interesting challenge to interoperability.

>     but the
> beliefs or mine. 

Your feeling the need to utter something this basic suggests that you 
think an individual's expressing their views constitutes a threat to the 
authority of the working group.  Why is that?

It might be more productive to engage in the substance of the topic, 
rather than have a lengthy note that invokes history, process, and the like.

> bloat" or "pretending to specify something when, in fact, it

What language would you find acceptable, John?  Let's make sure that we 
document what can be written without your taking exception.  We should 
probably spend a lot of time developing guidance for the community, 
about proper language when criticizing technical content.

Use of normative language that does not contain any technical 
specification is not meaningful.  It purports to be saying something 
substantial, but it isn't.

> matters

Excellent suggestions.

So, please re-read my note and try to respond to exactly the substance 
of it.  I didn't see it here.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Mar 2021 07:41:01 -0700

> I'll incorporate it into the working version of 5321bis.

John,

Given the exchange we had after in response to the above, it would be 
helpful for you to confirm that the draft will incorporate the above 
change, as you originally indicated.

d/

---

From: John C Klensin <[email-masked]>
Date: Thu, 25 Mar 2021 18:22:02 -0400

--On Thursday, March 25, 2021 07:41 -0700 Dave Crocker
<[email-masked]> wrote:

>>>          This specification does not deal with the
>>>          verification of a return path. Server efforts to
>>> verify a return path are outside the scope of this
>>> specification.
>  >
>> Dave, this is at least as reasonable as any of the
>> suggestions I made in the note pointing out the problem with
>> your earlier text.   Unless someone objects or has a
>> yet-better suggestion, I'll incorporate it into the working
>> version of 5321bis.
> 
> 
> John,
> 
> Given the exchange we had after in response to the above, it
> would be helpful for you to confirm that the draft will
> incorporate the above change, as you originally indicated.

Dave, 

TL;DR summary: Your inputs are being treated no differently than
anyone else's.

     -------------

Explanation:  As I belief I have said previously, I am very
concerned about the possibility of making changes to 5321 that
do not have fairly clear community consensus both about the
substance of the change and about the risk of inadvertent side
effects, including the risk of invalidating existing conforming
implementations.  That position builds on decisions made in
DRUMs, in YAM, and when this WG was chartered to avoid doing a
complete rewrite. On the one hand, such a rewrite would
undoubtedly improve the readability of the document.  On the
other, the risks of getting something wrong are considerable and
the decision that has been made three times now that the risks
outweigh the benefits.

In part because I, like many others on this list, have very
strong opinions on many of the issues, I have adopted a very
conservation approach to making document changes or edits.  I
will make changes based on editor's discretion only to make
editorial improvements (e.g., to improve bad sentences), to add
cross references, and to maintain the tracking sections (the
Note at the beginning and Appendices G and H).  

Beyond that, I will made changes I expect to make it through
into the IETF Last Call version iff the WG Chairs declare (at
least rough) consensus on particular text and either close the
relevant ticket(s) or indicate intent to do so as soon as the
changes are made.  Other changes will either be inserted into
the text but clearly identified as proposed changes or will be
held in the source version of the working drafts until a
consensus call is made (with that choice entirely at my
discretion until I get instructions from the WG Chairs).

As above, your proposed change has been reflected in the working
draft version.  And, in case you are wondering, your name has
been added to the list of acknowledgments associated with this
version. Unless I am instructed to the contrary by the WG or its
leadership, it remain there no matter what the WG decided to do
with your text because you clearly contributed to the discussion
that will lead to however the draft works out.  And I would
expect to resist such instructions if I received them.

best,
    john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Mar 2021 17:08:12 -0700

On 3/25/2021 3:22 PM, John C Klensin wrote:
> draft version.

Dandy.

d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 26 Mar 2021 00:14:11 -0400

Hector,

--On Friday, March 19, 2021 13:05 -0400 Hector Santos
<hsantos=[email-masked]> wrote:

>>>>        verification of return paths for use in delivery
>>>> notifications. Server efforts to verify the return path
>>>> using it is outside the scope of this specification.
>> 
>> 
>>        of a  return path. Server efforts to verify a return
>> path are outside the  scope of this specification.
>...

> -1
> 
> Here is why:
> 
> For the record, since RFC2821 and now RFC5321,while described
> as beyond the scope of the document as to how validation can
> be done, it does describe the idea for a client/server
> protocol negotiation considerations for the acceptability of
> the the return path in section: 3.3:
> 
> 
>...

More on this below but I, at least, find the reminder about that
section helpful if only because it appears (to me) to make it
clear that validation (whatever that means) of the reverse-path
is in scope for SMTP.  The only questions are what, and how
much, discussion of validation should occur.

>...
> (Note: This will save at least X% of return-path validation
> when X% of the RCPT fails).
> 
> It has nothing to do with whether it is easily spoofed or not,
> the return path MUST be valid for the purposes of returns.  It
> can't be any "random" address per se.  It should be validated.
> SPF allows one form of validation.  Call Back Verification
> (CBV), a concept employed since Caller-ID Modem days, has been
> applied to SMTP.  It has been the #1 rejection method for
> invalid return paths within our wcSMTP package since 2003.
> 
> Due to CBV overhead, I would never recommend it as a IETF
> standard. However, empirical data collected daily since 2003
> has solidify the high payoff of a CBV operation.  It is a
> local policy option in our package.

I agree with much of what you say above.   I don't have any
experience with CBV, but remember a proposal from very long ago
for doing something similar (and faster) by having the delivery
server send a VRFY to the presumed sending system using the
address in the MAIL command that delivery server received [1].
Both seem to me to have the same set of problems:

(1) They are, as you point out, expensive, especially if the
delivery server is trying to keep the connection over which the
message came open so it can use reply codes rather than bounce
messages.

(2) As far as I can tell, anything like this is going to work
badly or not at all in a situation involving multiple relay
steps, especially when the MX path back to the presumed sender
from the recipient system is different from the MX path from the
sender to the recipient system or when the originating and
receiving systems are not attached to the network at the same
time.

(3) From the perspective of avoiding "blowback" and similar
problems, one needs to know the the reverse-pointing address
(i.e., the MAIL command argument) is both a valid address for
which mail will be accepted (for which CBV is at least a partial
solution, modulo the issue above) _and_ the actual address to
which a bounce message can and should legitimately be sent.  It
seems to me that CBV provides no help, or almost no help, with
the latter.  How much help SPF provides against a determined
attacker is something we can debate another time, but it may
lead into a discussion of the appropriateness and utility of
methods that depend on attackers being either lazy or not very
smart... e.g., if they start succeeding well enough, do we give
the would-be attackers incentives to develop and use more
sophisticated techniques or, at Paul Vixie more or less put it
in another context some years ago, are we just making the bad
guys smarter?

But, right now, for 5321bis, we have a problem.  That problem,
at least as I see it it, is that the current text and its
handwaving, "Recent work", reference to SPF (and DKIM) needs to
be changed in some way.  I don't think I've seen any
disagreement about that.   One extreme, for which I do not
believe I have seen a proposal, would be to update the current
language to explain what we know about how effective those
approaches are.  A slightly less extreme version would be for
the WG to agree that a discussion of return-path validity and
how it might be determined (possibly along the lines of some of
the comments in your message)  belongs in the A/S with a
sentence or two in 5321bis as a forward pointer.  If I
understand him, Dave believes that either of those would be out
of scope.  A counterargument (again at least slightly extreme)
would be that, by definition, nothing that is discussed in 5321
can possibly be out of scope for the revision effort.  

You will also note, fwiw, that the current text in 5321 is
strictly about verification for use in delivery notifications.
Your comments above (and, actually, Dave's suggested text) do
not have that limitation.  

I don't have an opinion (yet) as to whether that is important or
not, even to debates about scope limitations.  On the other
hand, without that limitation to delivery notifications, there
may be a case for moving whatever we want to say about
reverse-path and their verification into Section 3.3 and reduce
Section 3.6.2 to its first paragraph and a cross-reference.
That would have the advantage of being more clear because there
are reasons to verify reverse-paths that have nothing to do with
either relays or the presence of MX records.

Coming back to the text Dave proposed and the comments above
leaves us in an odd place.  The original proposal in the erratum
was to simply drop the second and third sentences of the
paragraph which, in 5321 reads:

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

That suggestion, unlike Dave's, does not make a specific
statement about scope.  Both it and Dave's suggestion (if I have
correctly recorded it), drop the third sentence which does not
depend on SPF or DKIM and which, absent either the argument
about the WG's scope or one about handwaving, might reasonably
be retained. [2]

So, if you like one of the alternatives above (or a variation on
one) better than the one Dave suggested, please say so and
explain why.  Or, if you want to propose a different course of
action, please explain, either by sending suggested text or at
least explaining your position well enough that someone can take
a pass at it.  I don't see the above meeting that criterion; if
you disagree, please explain so I (and others) can understand
you better.

> That said:
> 
> I would not recommend editing SPF RFC4405 to remove its
> validation statement. Validation is the main purpose for using
> the SPF mechanism.  Why else would you use it?  Again, it has
> nothing to do whether it is can be spoofed or not, the return
> path MUST always be a valid address per RFC5321. If not, then,
> imto, it is easily classifiable as rejectable mail transport
> identity.

And I don't know where that takes us.  There has been no
proposal to modify RFC 4405 in the WG.  Such a proposal would
have nothing to do with 5321bis (or 5321), 5322bis (or 5322), or
any possible A/S and would hence be far outside the WG's charter
even if it had been made.  AFAICT, the only question relevant to
this particular issue/ticket is what should be done about the
SPF (and DKIM)-referencing text in 5321 as discussed above.

best,
   john

[1] I note that the Wikipedia article about CBV,
https://en.wikipedia.org/wiki/Callback_verification, mentions
the VRFY option.

[2] Dave's other argument (again, at least if I have correctly
understood it) may be a subset of the comment about handwaving
above.  If the only issue was that the sentence tried to make
something sound normative that was not, that issue could be
addressed, especially given RFC 8174, by changing "MAY" to lower
case.

---

From: Hector Santos <[email-masked]>
Date: Fri, 26 Mar 2021 08:57:40 -0400

John,  I hope the following clarifies my position and pov.  The 
specific paragraph in section 3.6.2.

This was triggered with discussions I helped initiate during the 
RFC2821bis work.

As I recall, I did not wish for specifics given that SPF was 
experimental and DKIM (and ADSP was part of DKIM) was still on the 
drawing board and we still had many IETF cogs on the fence with these 
then new ideas.  Both Crocker and Levine were dead set against SPF and 
ADSP at the time.  Their focus was DKIM + SIGNER TRUST modeling.

I was asking for a SMTP protocol model recognition for validation due 
to the fact there was active work and existence of dynamic validation 
methods working groups currently within the IETF.   So yes, I agree.  
We should remove SPF and DKIM mentioning in this section and simply 
generalize the modeling for a modern SMTP validation design where 
every entity, identity at each SMTP state can be validated.  Tomorrow 
someone can invent a new validation method for SMTP and we should 
continue to provide the protocol language and guidance to smoothly 
integrate any new invention.

For background ...

When we did RFC5321 (RFC2821bis) in circa 2008, I was one of the 
participants advocating recognition of the then new augmented 
deterministic technologies dealing with new filtering considerations 
at the SMTP level above and beyond just plain transport SMTP 
responsibilities.  We had three deterministic protocols at the time:

- SPF
- SenderID also known as SPF/2, the payload version of SPF.
- DKIM + ADSP

DKIM and ADSP were Proposed Standards working items in the DKIM WG and 
SPF/SenderID were already completed MARID WG results as established 
experimental proposals.  SPF was on its way to become a "standard" 
add-on SMTP feature for domains to have available. In other words, the 
SMTP developers needed to provide the shims and hooks at the various 
SMTP state machine point to call the SPF CheckHost()  function.

Overall, these new deterministic protocol policy modeling concepts 
helped raise the SMTP bar on the public port 25 SMTP operation.

With the discussion, you modified a few sections to indicate the 
existence and the recognition of new augmented methods that MAY play a 
role in the SMTP reply codes and the delivery of mail.

First, RFC2821 section 7.1 had this:

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against an ignorant user who is trying to fake mail.

I suggested a change to recognize it was no longer a small margin to 
consider.  The word "ignorant" was removed for RFC5321.

    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against a user who is trying to fake mail.

And then you added the section in question.

I believe a focus in the discussion was to keep as a reminder our 
responsibility and duty as mail transporters first and 2nd to 
recognize for the need for bounces when delivery can not be met. We 
did not want any new augmentations to alter the strong SMTP 
operational tenet for interoperability.

Today, I believe we are rehashing the same thing.  Nothing has changed 
other than SPF won over SenderID and is now a Standard Track item.  
SenderID/PRA/SUBMITTER were deprecated.  DKIM became an STD and we are 
still haggling over the DKIM POLICY model. DMARC replaced ADSP but it 
still has the same process design issues.

It was also indicated that we had two modes of operation:

1) Receivers that applied SPF at SMTP before DATA maybe at MAIL FROM 
or delayed until RCPT is known per the guidance in section 3.3.

2) Receivers that applied SPF within DATA in order to gain payload 
data information for full email recording of rejections.

The latter required the need to transfer the payload first which could 
be a high overhead when the payload is large (and today, my friends, 
10mb, 15mb, 25mb transfers are not uncommon, people don't always use 
links but embedded multi-media).

With DMARC in the picture now, it is now putting pressure of systems 
to delay the SPF check or delay the action taken until DATA is 
reached, the payload is transferred and DMARC is processed to yield an 
acceptance or rejection response. This is not an optimal mode for a 
protocol that still has a low payoff.    This was why the SUBMITTER 
protocol was invented which allowed SMTP to process the SenderID PRA 
(Purported Responsible Address) domain at MAIL FROM:

C: MAIL FROM:<return-path> [SUBMITTER=pra]

DMARC needs the same thing and since SENDERID/PRA/SUBMITTER was 
deprecated when SPF won, I have been proposing that we leverage 
PRA/SUBMITTER for DMARC purposes.

Anyway, none of this should be in RFC5821bis in my opinion.  My whole 
and only point, is not to have language about these specific protocols 
but to recognize verification/validation is increasingly a major part 
of every receiver today.   In other words, the old days where most 
receivers just use simple store and forward drop off points for later 
post-smtp processing is no longer a desirable way to operation given a 
huge burden of unsolicited junk and spam. Today, increasingly, 
receivers are feasibly dynamically processing validation concepts at 
SMTP before DATA is collection. But both modes of operations SHOULD be 
recognized.

That was all my point then and it remains the same today.

Thanks.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Mar 2021 12:50:47 +0200

> either relays or the presence of MX records.

I agree that mentioning DKIM in the context of return-path is wrong.  However, 
rather than moving that text into Section 3.3, I'd create a new section.  Then, 
reducing Section 3.6.2 to its first paragraph and a cross-reference is fine.

Please keep in mind that there is a paragraph in Section 4.1.4 that talks about 
verification.  It starts with:

    An SMTP server MAY verify that the domain name argument in the EHLO
    command actually corresponds to the IP address of the client.

There is a proposal to weaken the prohibition to base message refusals on the 
result of that verification (Ticket #47).  Since the EHLO argument is also 
covered by SPF, a cross-reference from 4.1.4 to the same new section I 
mentioned above may make sense.

The result of DKIM verification can only play after the end of data.  Yet, 
mentioning DKIM and DMARC in such new section may be worth, as another example 
of the often mentioned "policy reasons".

Best
Ale
--

---

From: Hector Santos <[email-masked]>
Date: Mon, 29 Mar 2021 12:24:26 -0400

On 3/29/2021 6:50 AM, Alessandro Vesely wrote:
> I agree that mentioning DKIM in the context of return-path is 
> wrong.  However, rather than moving that text into Section 3.3, I'd 
> create a new section.  Then, reducing Section 3.6.2 to its first 
> paragraph and a cross-reference is fine.
>
> Please keep in mind that there is a paragraph in Section 4.1.4 that 
> talks about verification.  It starts with:
>
> There is a proposal to weaken the prohibition to base message 
> refusals on the result of that verification (Ticket #47).  Since the 
> EHLO argument is also covered by SPF, a cross-reference from 4.1.4 
> to the same new section I mentioned above may make sense.
>
> The result of DKIM verification can only play after the end of 
> data.  Yet, mentioning DKIM and DMARC in such new section may be 
> worth, as another example of the often mentioned "policy reasons".

I like the idea of a new section dedicated to policy topics.

The IP Literal check against the connection IP is something our 
receiver performs.  As a client, it will also issue IP literals when 
there is no public host domain or a static value is defined. We 
discovered the ietf.org mail server is rejecting transactions based on 
the usage of IP literals.  They have deemed it a spammer, bad guy 
behavior attribute. How will be this resolved?

DKIM as a base protocol is a STD. DMARC is not.  I would like to 
suggest to mention DKIM and DKIM Policy protocols related to the 
association of 5322.From identity and possibly 5321.Mail From 
identity.  Lets keep it general.

Why?

I believe we are not quite done with DKIM Policy protocol solutions 
such as DMARC.  Remember, ADSP was abandoned and replaced with DMARC. 
But DMARC did not resolve the reason ADSP was abandoned and has caused 
or rather introduced a "disruption" with a borderline tampering 
Rewrite 5322.From concept.  High potential Last Call conflicts.  We 
don't want to get into mentioning Rewrite to suggest the 5322.From 
field is unstable.  I feel DMARC is protocol incomplete and its going 
to be a moving target before it is all said and done.