Subject: [Emailcore] Scope of submission/delivery and address alteration

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Dec 2021 13:43:07 -0800

Folks,

 From today's session...

There is a pure point of debate about the boundary that defines 
delivery.  I'd like to see whether we can get any convergence on it.

My simplistic view is that when the SMTP sequence is no longer 
processing the address in a RCPT-TO, then either the message has been 
delivered or it has been subject to a delivery failure.

Assuming my understanding is correct, the other side of this debate sees 
some modifications to the RCPT-TO as being before delivery.

I don't understand the logic behind that, other than based on particular 
implementation choices, which strikes me as pretty arbitrary.

Thoughts?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 9 Dec 2021 22:00:07 -0500

>implementation choices, which strikes me as pretty arbitrary.

Well, we're supposed to be doing engineering, balancing theory and practice
to see what actually works.

I think that when a secondary MX forwards a message to a primary without
changing the envelope or changing the message other than adding trace
headers, that's a relay, and the intermediate step is not a delivery.

If a message passes through a mailing list that adds a tag to the
subject line and a footer to the body, replaces the envelope bounce
address, and sends the message to a whole bunch of people, that was
a delivery and resubmission.

In between, it gets kind of grey. My inclination is to say that if the
only change is to change the recipient address and maybe to add a few
trace headers (like received and authentication-results, that's a
relay, more than that is a delivery.

Someone said "what if it only adds a List-ID"?  I don't see that as
a very interesting question since in reality anything that adds a
List-ID is likely to do a lot more than that, at least to some of
the messages it handles.  

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Dec 2021 22:13:54 -0500

--On Thursday, December 9, 2021 22:00 -0500 John Levine
<[email-masked]> wrote:

>> Assuming my understanding is correct, the other side of this
>> debate sees  some modifications to the RCPT-TO as being
>> before delivery.
>> 
>> I don't understand the logic behind that, other than based on
>> particular  implementation choices, which strikes me as
>> pretty arbitrary.
> 
> Well, we're supposed to be doing engineering, balancing theory
> and practice to see what actually works.
> 
> I think that when a secondary MX forwards a message to a
> primary without changing the envelope or changing the message
> other than adding trace headers, that's a relay, and the
> intermediate step is not a delivery.
> 
> If a message passes through a mailing list that adds a tag to
> the subject line and a footer to the body, replaces the
> envelope bounce address, and sends the message to a whole
> bunch of people, that was a delivery and resubmission.
> 
> In between, it gets kind of grey. My inclination is to say
> that if the only change is to change the recipient address and
> maybe to add a few trace headers (like received and
> authentication-results, that's a relay, more than that is a
> delivery.
> 
> Someone said "what if it only adds a List-ID"?  I don't see
> that as a very interesting question since in reality anything
> that adds a List-ID is likely to do a lot more than that, at
> least to some of the messages it handles.  

FWIW, your analysis is consistent with what I (and probably
"we", because this was discussed) thought we were saying when
5321 was written.  If, either because I blew it or because our
ways of looking at things have evolved, that isn't clear, we
should certainly try to fix it.  But I'm at least mildly
resistant to trying to develop or apply an alternate theory that
would collapse the situations together ... if only because I
have doubts that we'd get it right, especially with a reasonable
level of time and effort.

The only area where the spec may (I'd have to go back and study
it) disagree with your "only change" in the gray area is that I
think (again without checking) that the text allows, and may
encourage, changing the backward-pointing address too.

    john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Dec 2021 19:42:48 -0800

> relay, more than that is a delivery.

So, this defines a choice, based on some actions.  I think it's 
consistent with the 'alias is different from mailing list' view being 
espoused.

But my question was about the /logic/ for this choice.  In functional 
and/or architectural terms, what makes that good to include in the SMTP 
layer, versus some things deemed outside of that layer, such as mailing 
lists?  Is it just arbitrary, based on some historical implementation 
choices, or is there an architectural basis?

By way of seeding this a bit, please note that the view I'm pushing is 
quite simple:  when the SMTP layer is done processing the address in 
RCPT-TO, then it is delivered (or failed).

Though it is outside the scope of this narrow topic, it might be worth 
at least noting that the higher-level 'end to end' email activity, 
between author and recipient, which goes through mailing lists and is 
viewed as having multiple submissions and deliveries, has a higher-level 
version of submission/delivery, but we don't have distinctive language 
for that, other than sometimes say 'final' delivery.  Still, I think 
there is a shared -- if implicit -- view of it.

It is easy to say "relaying is movement until processing of the address 
in RCPT-To is complete and the act of completion has either delivery of 
failure.

Revising that simple model to include address transformation of RCPT-TO 
is at least odd, given that we still need the upper-level model for 
mailing lists, which also must deal with that 'transformation'.

d/

---

From: "John Levine" <[email-masked]>
Date: 9 Dec 2021 23:10:48 -0500

It appears that Dave Crocker  <[email-masked]> said:
>But my question was about the /logic/ for this choice. 

It reflects reality.  If we could rewind back to 1980 and redo this
from scratch, there's all sorts of stuff we'd do differently.

>RCPT-TO, then it is delivered (or failed).

Yes, I understand that is the proposal.  But I don't think it matches
the way that mail systems work.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Dec 2021 23:36:40 -0500

--On Thursday, December 9, 2021 19:42 -0800 Dave Crocker
<[email-masked]> wrote:

>> that if the only change is to change the recipient address
>> and maybe to add a few trace headers (like received and
> So, this defines a choice, based on some actions.  I think
> it's consistent with the 'alias is different from mailing
> list' view being espoused.
>...

Hi.

An observation, editor's hat firmly in place and with the
current discussion only as an example (there are other examples)
....

Due to decisions made in DRUMS (pre-2821) and not altered
significant in YAM (pre-5321), 5321 is a rather complex
document, containing a good deal of text that is interconnected
and sometimes even redundant.  As a handy example, the seemingly
simple tasks of cleaning source routes out of the body of the
text, including figuring out just what that meant in practice,
has taken two iterations of the I-D already and will take at
least one more.   Even if we had comprehensive agreement on a
principle like "as soon as an RCPT field is changed, it isn't
SMTP any more" (and I don't think that has been proposed),
correcting all of the text that would be affected would be a
significant piece of work.  That work would necessarily include
(as was pointed out on the call), figuring out how to sort out
the rewriting implied by the 251 ("forwarding to...") reply code
and implications for the VRFY and EXPN commands).

So, without judging the answer for this case or any of the
others that might  arise, I hope we can regularly ask ourselves,
and that the co-chairs will insist that we ask, whether any
particular change to what is presented and/or how it is
presented are important enough to be worth the effort.  That
question is not just about the editorial effort.  It is also the
effort to review what has been changed and what has not to be
sure we haven't left loose ends or created ambiguity or
uncertainty.  In that context, "important enough" may include
questions of WG energy and commitment levels, schedules, etc.,
as well as evaluations of more substantive questions.    It
might not be that way in a more perfect world, but we need to
face the reality and need to make pragmatic decisions in this
one.

Again, that is not a comment on the particular thread that
inspired this note and I have not reached a personal conclusion
about my preferences about what we should change if anything
(independent of what I've already said about substance in my
personal capacity).  But I do think it is important to get the
question in front of us.

best,
   john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 9 Dec 2021 21:05:44 -0800

On 12/9/2021 8:10 PM, John Levine wrote:
> It reflects reality. 

It reflects an implementation reality -- and not one that is required. 
Which is why it's not the same thing as a networking architectural 
reality.

Note that there is nothing from choosing to implement these bits of 
functionality is very different places.  Ned noted they can/do put 
mailing lists into the SMTP functionality.

> the way that mail systems work.

Is it really that difficult to distinguish between email abstractions 
and common -- but not inherent -- email implementation?

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 10 Dec 2021 06:10:52 -0800

On 12/9/2021 8:36 PM, John C Klensin wrote:
> As a handy example, the seemingly

Gosh.  I thought it had.

> and implications for the VRFY and EXPN commands).

While there is an obvious and reasonable basis for considering the 
'forwarding' text to be related to the 'alias' text, the document in 
fact makes no connection.

So no, the work would not necessarily include dealing with forwarding.

'alias' is a term used with some frequency in the document, but I 
believe it never has normative effect.

d/

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Dec 2021 10:18:41 -0500

>> SMTP any more" (and I don't think that has been proposed),

If that was what you intended, it was not sufficiently clear to
me.  I therefore opted to make a more general comment rather
than attributing to you and getting flamed for being wrong
because you were suggesting something more subtle.

In any event, I think the more substantive part of the message
is more important.

    john

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Dec 2021 15:37:43 -0500

> On 9 Dec 2021, at 10:42 pm, Dave Crocker <[email-masked]> wrote:
> 
> It is easy to say "relaying is movement until processing of the address in RCPT-To is complete and the act of completion has either delivery of failure.
> 
> Revising that simple model to include address transformation of RCPT-TO is at least odd, given that we still need the upper-level model for mailing lists, which also must deal with that 'transformation'.

Many real-world email systems present a public abstraction of
the recipient mailbox as:

	[email-masked]

where that address is transformed at edge to something along
the lines of:

	[email-masked]

and sent there via SMTP or LMTP for delivery.  The message
is still *inbound* and not being relayed from a recipient
managed by the receiving organisation to some other organisation
or other recipient.  Rather, all that's happening is a NAT-like
translation to an internal representation of the same recipient's
address.

In this not uncommon scenario, the operator view is that the
receiving edge system is not performing "delivery", though it
may in some cases be the authoritative place where "@admd.example"
addresses are processed and disposed of, with subsequent internal
hops seeing only the internal address.

In some cases the transformation to "canonicalise" the localpart
to the preferred address of a recipient whose mailbox is associated
with multiple addresses, and the canonical address is then forwarded
via SMTP (or sometimes LMTP) to the mailstore.

What constitutes delivery to the originally requested recipient and
what constitutes redirection to someone else or resubmission is not
an easy distinction to make. :-(

For purposes of adding or not adding "Delivered-To" loop-breaker
header, Postfix assumes that handoff to the "local" delivery agent
is "delivery" and by default handoff to an "smtp" transport is not.
But the administrator can override this on a transport-by-transport
basis, labelling some instances of "smtp" as representing "delivery".
We don't know in advance, and the choice is left to the operator.

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Dec 2021 12:04:58 -0800

On 12/10/2021 12:37 PM, Viktor Dukhovni wrote:
>> It is easy to say "relaying is movement until processing of the
>> address in RCPT-To is complete and the act of completion has either
>> delivery of failure.
>> Revising that simple model to include address transformation of
>> RCPT-TO is at least odd, given that we still need the upper-level model
>> for mailing lists, which also must deal with that 'transformation'.
> 
> Many real-world email systems present a public abstraction of the
> recipient mailbox as:
> 	[email-masked]
> 

In other words, it reaches the specified address, and local processing 
decides to continue things with a fresh address.

That description isn't any different than for a mailing list.

> an easy distinction to make. :-(

On the other hand, it's quite simple to note that, in terms of abstract 
architecture, they are exactly the same.

The problem is trying to treat what is really the same functionality as 
different because we think of the two as serving different purpose or 
because we commonly make implementation choices that are different, 
though that isn't required.

> is "delivery" and by default handoff to an "smtp" transport is not.

Yet adding a Delivered-To in both cases is entirely reasonable, privacy 
concerns notwithstanding.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Dec 2021 16:07:17 -0500

On Sat, Dec 11, 2021 at 12:04:58PM -0800, Dave Crocker wrote:

> > The message is still *inbound* and not being relayed from a
> > recipient managed by the receiving organisation to some other
> > organisation or other recipient.  Rather, all that's happening is a
> > NAT-like translation to an internal representation of the same
> > recipient's address.
> 

That's one take, another take is that the message is continuing on its
way to the originally requested recipient's mailbox, but to reach that
mailbox a local representation of its SMTP address is substituted.

> That description isn't any different than for a mailing list.

Well, mailing lists, such as this one, are in fact rather different, in
that they replace the envelope sender, add "Sender" and "List-" headers,
...  But sure, much simpler historical 1-to-many forwarding via Sendmail
aliases for redirecting mail to someone else has an implementation that
is essentially identical to rewriting a recipient's address to an
internal form, but I'd argue that semantically they're not the same.

> architecture, they are exactly the same.

We strive to make things as simple as possible, but no simpler.

> though that isn't required.

The operator's view is rather different.  If the edge system supports
"recipient extensions" ([email-masked]), but the mailstore
does not, one might at the edge drop the extension from the envelope
recipient address (while preserving it in headers):

    [email-masked] -> [email-masked]

and then relay the truncated localpart the mailstore.  You'd argue this
constitutes a delivery, and, yes, there's some mathematical elegance to
this strictly logical viewpoint, but I don't it is a fair reflection of
operational reality.

> concerns notwithstanding.

Well, for that we'd need to also have the envelope split to one
recipient per transaction, as otherwise we'd leak "Bcc" addresses.  The
local delivery agent does exactly that, always delivers one recipient at
a time, but SMTP keeps groups of recipients with the same nexthop
bundled together (up to the destination recipient limit).

To add "Delivered-To" to SMTP one needs to conjure up an SMTP transport
with the recipient limit set to 1, and set the flags to signal that this
transport is performing "delivery".

Anyway, the question at hand really has no right answer, we're looking
at it from incompatible perspectives, each leads to a different
conclusion.  The perspectives aren't right or wrong, they just "are".

-- 
    Viktor.

---

From: "John Levine" <[email-masked]>
Date: 11 Dec 2021 17:56:32 -0500

>internal form, but I'd argue that semantically they're not the same.

It seems to me that the way people use mail has changed from 20 or 30
years ago and it would be a good idea to make our definitions try to
match the practice.

Back in the olden days, long haul networks were slow and expensive,
so people went to considerable effort to avoid sending multiple
copies of messages.  A site would often have an exploder that
took one copy of an incoming list message and passed it along to
the local users who subscribed.  LISTSERV had a fancy sublist
feature to manage those remotely.

But these days, mail uses such a small part of network bandwidth that
nobody cares and it common for a list to send each recipient a
separate lightly customized copy of a message. Even for lists that
don't, nobody cares whether they are sent individually or the MTA
consolidates copies to a recipient MX.

I see a handful of remaining uses for local exploders.  The main
use seems to be role accounts so postmaster@foo goes to mary,
or sales@foo goes to beth, jane, and fred.  There is definitely
the local rewriting tht Viktor described.

There may be some technical similarities between the local rewriting
and mailing lists, but the semantics are quite different and I don't
think we'd do anyone a favor by continuting to conflate them.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Dec 2021 18:34:00 -0500

--On Saturday, December 11, 2021 17:56 -0500 John Levine
<[email-masked]> wrote:

>> Well, mailing lists, such as this one, are in fact rather
>> different, in that they replace the envelope sender, add
>> "Sender" and "List-" headers, ...  But sure, much simpler
>> historical 1-to-many forwarding via Sendmail aliases for
>> redirecting mail to someone else has an implementation that
>> is essentially identical to rewriting a recipient's address
>> to an internal form, but I'd argue that semantically they're
>> not the same.
> 
> It seems to me that the way people use mail has changed from
> 20 or 30 years ago and it would be a good idea to make our
> definitions try to match the practice.
> 
> Back in the olden days, long haul networks were slow and
> expensive, so people went to considerable effort to avoid
> sending multiple copies of messages.  A site would often have
> an exploder that took one copy of an incoming list message and
> passed it along to the local users who subscribed.  LISTSERV
> had a fancy sublist feature to manage those remotely.
> 
> But these days, mail uses such a small part of network
> bandwidth that nobody cares and it common for a list to send
> each recipient a separate lightly customized copy of a
> message. Even for lists that don't, nobody cares whether they
> are sent individually or the MTA consolidates copies to a
> recipient MX.
> 
> I see a handful of remaining uses for local exploders.  The
> main use seems to be role accounts so postmaster@foo goes to
> mary, or sales@foo goes to beth, jane, and fred.  There is
> definitely the local rewriting tht Viktor described.
> 
> There may be some technical similarities between the local
> rewriting and mailing lists, but the semantics are quite
> different and I don't think we'd do anyone a favor by
> continuting to conflate them.

John,

I think I agree, with two qualifications/ thoughts:

(1) Whether it has done so well or poorly, the SMTP specs have
tried to keep what I think are those two approaches separate
from many years (back at least to 2821 and probably longer).
Are you suggesting changing anything at this point and, if so,
would be be substantive or, e.g., better explanation and better
examples?

(2) Very similar arguments about the evolution of the network
can be used to suggest that relays, MX records, etc., are much
less important then they were in, e.g., early 1976 when RFC 974
was published.  If one ignores transitions between private
networks or networks not running TCP/IP and the public Internet
and possibly does a bit of handwaving around what X.400 called
ADMDs, we are doing far less relaying now than was the case 30
or 35 years ago.  Concentrating only on connections between
endpoints, removing all of those inconvenient relay stuff from
5321 and putting it into a "rare cases" appendix or separate
document, would simplify the core SMTP specification
considerably.

Now, AFAICT, no one has proposed going that far (and I certainly
would not).  But a little thought about where we would draw the
line if we start taking things out because they are obsolete or
less important than they were 20 or 30 years ago might help
clarify some recent discussions.

best,
   john

---

From: "John R Levine" <[email-masked]>
Date: 11 Dec 2021 21:17:14 -0500

> would be be substantive or, e.g., better explanation and better

I think just the latter.  In 5321 section 3.9, I would shorten the 
discussion and say that aliases that just change the envelope are 
typically used for address management, such as sending mail addressed to 
role accounts to the individuals who handle it, to rewrite addresses when 
a mail system's internal address structure is different from the 
externally visible structure.  I'd take out "exploders".

For mailing lists, I'd shorten it a lot and say that most lists make 
enough changes to the mail they process that they are in practice MUAs 
that rewrite and remail the messages.

> was published.

I suppose, but large mail systems still use multiple MXes, e.g.

$ host -t mx gmail.com
gmail.com mail is handled by 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 20 alt2.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail is handled by 5 gmail-smtp-in.l.google.com.
gmail.com mail is handled by 30 alt3.gmail-smtp-in.l.google.com.

$ host -t mx yahoo.com
yahoo.com mail is handled by 1 mta7.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta6.am0.yahoodns.net.
yahoo.com mail is handled by 1 mta5.am0.yahoodns.net.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Sat, 11 Dec 2021 21:52:39 -0500

--On Saturday, December 11, 2021 21:17 -0500 John R Levine
<[email-masked]> wrote:

>> would be be substantive or, e.g., better explanation and
>> better examples?
> 
> I think just the latter.  In 5321 section 3.9, I would shorten
> the discussion and say that aliases that just change the
> envelope are typically used for address management, such as
> sending mail addressed to role accounts to the individuals who
> handle it, to rewrite addresses when a mail system's internal
> address structure is different from the externally visible
> structure.  I'd take out "exploders".
> 
> For mailing lists, I'd shorten it a lot and say that most
> lists make enough changes to the mail they process that they
> are in practice MUAs that rewrite and remail the messages.

If there is general agreement (aka "rough consensus") for this,
it works for me and would, I think, make things quite a bit more
clear to a contemporary reader.
 
>> less important then they were in, e.g., early 1976 when RFC
>> 974 was published.
> 

Good counterexample.  Thanks.
   john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Dec 2021 09:03:41 -0800

> mailbox a local representation of its SMTP address is substituted.

Viktor,

Thanks for responding on this key issue.  It's likely your view is 
shared by others, though it would be good to hear from them too.

In an effort to distinguish 'architecture' from 'implementation', there 
should be abstract, functional differences that distinguish 
architectural modules, where those differences are independent of 
implementation choices.  That is, 'this is the way we've been running 
it' is implementation.  Whereas "there is a natural functional split 
here" is more architectural, especially when alternative implementation 
choices are reasonable.

A useful reference for this kind of thinking is the classic:

     Tussle in Cyberspace: Deﬁning Tomorrow's Internet
     http://conferences.sigcomm.org/sigcomm/2002/papers/tussle.pdf

Here are some issues with the view you've offered, where the challenge 
should be to reconcile these issues thoughtfully, rather than just 
dismiss them:

      1. The author specifies a particular address.  The only 
information the email service has, about the author's 'intent', is that 
address.

A protocol specification that attempts to claim and use deeper 
'knowledge' about an author's intent has wandered into metaphysics, 
since it is relying on information that is not in the message or its 
envelope.

When a receiving system changes that address, it is known to represent 
the 'intent' of the receiving system, not of the author.

At the least, the view you offer requires quite a different and 
more-detailed, and possibly more nuanced definition of 'delivery' than 
we've been using for about 50 years.

Note that simply saying something like "until the message has reached 
the address specified in RCTP-TO" is far simpler, far easier to 
understand, technically reasonable and functionally sufficient.

      2. The description you give also seems to match the behavior of 
email transiting a mailing list.

In fact it is arguably more suited to act of sending to a mailing list 
than to an individual address, since it is a lot more likely -- but only 
likely, not certain -- that the author knows they are sending to a 
mailing list and, therefore, that they are expecting the message to 
continue on, beyond the specified address.  In contrast it is unlikely 
the author knows that the address they are using will get changed.

If the claim is that mailing lists are different, what is the technical 
specification of that difference and what are the architectural features 
that justify that choice of distinguishing features?

(Hint:  "We've implemented this way" is a statement about 
implementation, not network architecture.)

      3.  Given the equivalence between alias and mailing list, is the 
intent, here, to also include mailing list processing into the 
architectural definition of an MTA?

That would mean that any MTA along the path can replace the value of the 
RCPT-TO if it feels like it, since we offer no technical specification 
for these behaviors.

Pretty much the same dilemma applies if the feature is allowed to any MDA.

      4. An underlying point seems to be the view that changing only 
RCTP-TO is architecturally different than making changes to the message 
header or body.

The obvious question is why and how?

d/

---

From: "John Levine" <[email-masked]>
Date: 15 Dec 2021 14:03:51 -0500

It appears that Dave Crocker  <[email-masked]> said:
>the 'intent' of the receiving system, not of the author. ...

>the address specified in RCPT-TO" is far simpler, far easier to 

Every mail system I've ever used treats upper and lower case equivalently.
So if you send a message to [email-masked], it goes into the mailbox for
[email-masked].  How many deliveries is that?

Many mail systems allow subadddresses, so mail for bob+ext or bob-ext usually
goes into the mailbox for bob.  How many deliveries is that?

Some systems, notably Gmail, ignore dots in the mailbox so mail to joeblow123,
joe.blow.123, and j.o.e.b.l.o.w.1.2.3 all go into the same mailbox.  How many
deliveries is each of those?

R's,
John

---

From: Pete Resnick <[email-masked]>
Date: Wed, 15 Dec 2021 16:54:04 -0600

> deliveries is each of those?

I think the reference to the 251 response you made in reply to John is 
also an interesting example: If you take a look at RFC 821, section 3.2 
on forwarding, it seems that the intention was that returning 251 and 
rewriting the RCPT-TO was clearly part of the SMTP architecture and not 
itself an act of delivery. If the entity that is returning SMTP 
responses can in protocol tell the other end of the SMTP transaction 
that it is changing the RCPT-TO and what it is being changed to, that 
sounds like its part of the SMTP architecture.

I agree with Dave that it is certainly a simpler architecture to have 
the message reaching the RCPT-TO be the point of delivery (I might even 
go further and say that the message reaching a server that peeks at the 
left-hand-side and acts on it is the point of delivery), and it might 
even be the best architecture. However, I'm not convinced that's the 
architecture we've been using since 821. There seems to be a distinction 
at an architectural level between "really truly delivered and resent" 
and "simply redirected within the SMTP process". I know user-level 
"Resend a message that has been delivered to my Inbox" is clearly the 
former, though even putting it that way probably begs the question. I'm 
pretty sure that mailing lists that muck with the DATA portion of the 
message beyond trace fields are also the former. I'm pretty sure that 
actions worthy of a 251 response (what might be implemented as a 
system-level alias file) are the latter. I'm not at all sure what to 
call user-level redirects to other addresses (e.g., .forward files). But 
this does seem to be an issue of a not-perfectly-clean architecture, not 
just implementation choices.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Dec 2021 19:41:04 -0500

--On Wednesday, December 15, 2021 16:54 -0600 Pete Resnick
<resnick=[email-masked]> wrote:

>>> Note that simply saying something like "until the message
>>> has reached the address specified in RCPT-TO" is far
>>> simpler, far easier to understand, technically reasonable
>>> and functionally sufficient.
>> 
> I think the reference to the 251 response you made in reply to
> John is also an interesting example: If you take a look at RFC
> 821, section 3.2 on forwarding, it seems that the intention
> was that returning 251 and rewriting the RCPT-TO was clearly
> part of the SMTP architecture and not itself an act of
> delivery. If the entity that is returning SMTP responses can
> in protocol tell the other end of the SMTP transaction that it
> is changing the RCPT-TO and what it is being changed to, that
> I agree with Dave that it is certainly a simpler architecture
> to have the message reaching the RCPT-TO be the point of
> delivery (I might even go further and say that the message
> reaching a server that peeks at the left-hand-side and acts on
> it is the point of delivery), and it might even be the best
> architecture. However, I'm not convinced that's the
> architecture we've been using since 821. There seems to be a
> distinction at an architectural level between "really truly
> delivered and resent" and "simply redirected within the SMTP
> process". I know user-level "Resend a message that has been
> delivered to my Inbox" is clearly the former, though even
> putting it that way probably begs the question. I'm pretty
> sure that mailing lists that muck with the DATA portion of the
> message beyond trace fields are also the former. I'm pretty
> sure that actions worthy of a 251 response (what might be
> implemented as a system-level alias file) are the latter. I'm
> not at all sure what to call user-level redirects to other
> addresses (e.g., .forward files). But this does seem to be an
> issue of a not-perfectly-clean architecture, not just
> implementation choices.

Without, at the moment, taking more of a position on this than I
already have, let me make a procedural observation that builds
on Pete's comment.  There is an SMTP architecture and
fundamental protocol design that goes back to 821.  There have
only been two significant changes made to it since 1992: the
introduction of MX-based mail routing with RFC 975 and the
extension model (including the replacement of HELO by EHLO) with
RFC 1425.  No amount of wishing it were different,
second-guessing decisions made nearly 40 years ago, or
publication of descriptions that do not explicitly change SMTP
(e.g., by standards track updating of 2821 or 5321) changes
that.  If there are features that never worked or interoperated
as intended, we can remove them.  If others have not stood the
test of time, we can denounce them and/or recommend against
their use -- that is what applicability statements are about,
whether in a separate document or inline in 5321bis.  

However -- and I believe RFC 6410 and 2026 are clear about this
-- if we are going to start adding or changing features or
redefining the model, it is back to Proposed Standard and I
thought we had general agreement we were not going to make (or
even consider) changes that would require that.

If I'm wrong about that, I hope we can address that topic rather
than picking at issues that would push that boundary.

best,
   john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Dec 2021 11:23:06 -0800

> deliveries is each of those?

Presumably, you think that the act of handing the message to a localo 
process that changes the address does not represent delivery.

1. Please explain very carefully, especially in terms that relate to the 
global email service.

2. Assuming my 'presumably' is correct, it isn't clear how you would 
characterize these examples.  Possibly 'aliasing'?  So aliasing is now 
an MTA function?  Again, please explain.

d/

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Dec 2021 13:13:35 -0800

On 12/15/2021 4:41 PM, John C Klensin wrote:
> There is an SMTP architecture and

Perhaps you can point to the second-guessing or wishing?  It isn't clear 
what you are referring to.

In any event, there is quite a bit of functional -- and, arguably, 
architectural -- enhancement buried in SMTP extensions.

I'm also surprised at discounting the MSA/MDA enhancement that is 
well-adopted within Internet Mail, including the use of SMTP for the 
independent function -- ie, as a different service -- of submission.

For reference, the UA/MTA model was developed at around the same time as 
SMTP and 822.  I was active in IFIP WG 6.5, where is was produced and so 
we were well aware of its emergence.  It was based on the emergence of 
MTA-like architectural splits at Xerox Park, DEC, Berkeley's Delivermail 
and UDel's MMDF.

It's not mentioned in 821 or 822, but it arguably didn't need to be.

In any event, there are many changes that have been done, over time.  So 
references that seem to suggest a kind of historical rigidity are both 
odd and wrong.

Specific concerns for WG charter and for barriers to full standard are 
an entirely different, and far more pragmatic -- and specific -- matter. 
  Of course.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 17 Dec 2021 19:01:27 +0100

>>> the 'intent' of the receiving system, not of the author. ...

Considering the author's intention is a sharp discriminant.  However, I'd argue 
that the intent of the author was to reach a real person (or function) rather 
than a syntactically defined mailbox.

Mailing lists are neatly different.  When I write to a ML I intend to reach a 
community.  The MLM provides both the community cohesive definition as well as 
the logistics.  It's role is missing in snail mail, unless you consider 
newspapers and magazines which used to publish readers' comments, and possibly 
related replies.

> Presumably, you think that the act of handing the message to a local process 
> that changes the address does not represent delivery.

That's right, it doesn't.  It has to, otherwise neither changing address nor 
functional addresses would be possible.  If we admit email address portability, 
even dot-forward files and similar rewriting are to be considered part of the 
protocol.  I'd tend to distinguish internal from foreign aliasing though, 
because of all the authentication/ reputation issues that concern the latter.

Best
Ale
--