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

[Dave Crocker <[e-mail]>]

On 1/7/2021 3:31 PM, Ned Freed wrote:
> 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.

Consider:

2.3.11.  Mailbox and Address
...
    standard mailbox naming convention is defined to be
    "local-part@domain"; contemporary usage permits a much broader set of
    applications than simple "user names".  Consequently, and due to a
    long history of problems when intermediate hosts have attempted to
    optimize transport by modifying them, the local-part MUST be
    interpreted and assigned semantics only by the host specified in the
    domain part of the address.


Interpretation of Local-part is inappropriate for an MTA. Having the 
Local-part be globally opaque is an important feature of Internet Mail. 
  (It has enabled quite a bit of easy extensibility of the decades.)

That makes interpretation of local-part an MDA function.

While, yes, aliasing typically goes through completely different code 
paths than normal 'delivery' and 'submission', we should focus, instead, 
on scope and responsibility, rather than code.

Either aliasing is in (or after) MDA functionality, or we need to define 
aliasing as an integrated part of MTA functionality, which means 
local-part is /not/ opaque.

Or we need to define multiple types of MTAs.  But I thought that was the 
point behind defining MSA and MDA architectural components.


>> > 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.
Where should it be discussed?  I understand the charter issue, but 
really, this is the currently-active venue for email focus in the IETF. 
  (And with my typical naivety, or at least optimism, I'm hoping that 
dealing with Deliver-To goes quickly.  I expect to circulate an I-D next 
week.  Maybe this weekend.)


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net