Re: [Emailcore] MDAs (was: Re: Delivered-To issues)

[Ned Freed <[e-mail]>]

> On Thu, 7 Jan 2021, John C Klensin wrote:
> > But, AFAICT, that brings things full circle to John L's point.
> > If there are some flavors of MDA that are really part of the MTA
> > function and some flavors that are not, then a crisp definition
> > of MDA that would fit well into 5321bis may not be possible
> > without splitting exactly those hairs.

> I took another look and I don't see anything to to change.  It says to add
> Return-Path at final delivery when "the message has left the SMTP
> environment."

Sounds correct to me.

> The details of when that happens are quite specific to different
> implementations.  For example, on some systems, when one address is
> aliased to another it just substitutes the envelope address within the
> MTA, in others (mine for example) it's delivered to a stub that reinjects
> the message, adding and then stripping the Return-Path.  I am not aware of
> the current language causing any trouble for implementers so I really
> think we should leave it alone.

That may be true for return-path, but what about success DSNs? You may be able
to undo the insertion of a return-path, but I doubt very much that anyone
implements NOTARY support using a "undo the DSN you just sent" mechanism to do
it.

There's also the relatied issue that AKAIK aliases operations don't reenter the
MTA through a submission operation. 

And this gets to my issues with intertwining aliasing with delivery, and the
suggestion that we can just drop the discussion of aliases versus mailing
lists.

If we do this then delivery becomes a meaningless abstraction with no
substance. And while I agree with Dave that we must not let implementation 
details define our model, I get very nervous when there's nothing whatsoever in
my implementation - or any of several other implementations I'm familiar with -
that corresponds to a major delineation in the model.

> > Certainly it would be desirable for a description of
> > Delivered-To: (or Envelope-To:) in some other spec to reference
> > such text if it appeared in 5321bis but, ...

> It is my impression that we agree that if it goes anywhere it'll be a
> separate draft.

Yep. And while I don't really mind discussing it on this list, if it's getting
confused with the revision or delaying it the delivered-to discussion needs to
be moved elsewhere.

				Ned