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

[Ned Freed <[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.

There's just one problem with this text: This isn't true. It has never been
true, and no amount of repetition, compliance language, or anything else will
make it true.

The obvious example, which I have pointed out many times, is when mailing lists
have to decide whether or not a subscribe/unsubscribe request is a match to an
address on the list. This means choosing whether or not other people's
local-parts are case-sensitive. (There's also the issue of things like
unnecessary quoting, which in the interests of my own sanity I'm going to
ignore.)

The decision is almost always that they aren't case-sensitive, because if you
assume they are, the doofus who keeps losing track of his subscriptions and
likes writing his or her name in various combinations of mixed caps starts
complaining about getting multiple copies. But either way this is absolutely a
case where the list is interpreting the local-part.

Similar tests for address equality are made by filtering systems for various
reasons. These tests may go so far as to assume specific formats for
subaddressing.

UTF-8 local-parts make this even messier. Right now I expect that
i;ascii-casemap is being used, but if UTF-8 local-parts ever do see significant
deployment worldwide, this may change, because I expect that people aren't any
more consistent about the case of the accented characters they use than they
are with the unaccented ones.

Another example: Secondary MXes may use forward-caching schemes. In some cases
they make educated guesses about the validity of local-parts of the domains
they forward to. Sometimes they do this with knowledge about the actual host.
And sometimes they just do it.

More generally, delegation of authority to interpret the local-part of address
happens pretty regularly. Customer requests to implement partial authority over
local-parts bother me, but... the customer is always yada yada yada.

And then there's SRS, which if you do the full bit involves interpreting the
first four characters of a local-part specially if they happen to be "SRS0" or
"SRS1".

Of course it's tempting to yell, "Bad Puppy!" and get out the rolled-up
newspaper to deal with some of these, but when Office 365 implements SRS...
good luck.

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

The actual requirement that has been successful in practice is "interpret only
when absolutely necessary, and only with consent". (Joining a mailing list
means consenting to that list's rules as to how it interprets your address.)
And yes, this has worked very well. But it's not the hard-and-fast rule we've
documented.

> That makes interpretation of local-part an MDA function.

Well, if you want to define the function of an MDA and thus "delivery" as
"interpret the local part and nothing else", and leave "final delivery" for
adding return-path, generating DSNs, etc., that's close to being workable. You
still have the problem that there needs to be a path from the MDA back to the
MTA that doesn't involve the MSA or message submission, but that's doable.

I don't think that's how most people interpret the word "delivery" though.

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

FWIW it doesn't, at least not in our server.

And while it's coding thing, I think some mention needs to be made of milter,
if only in passing since I don't think there's anything we can do about it.

Most MTAs have a well defined and well structured way of determine address
locality, one that matches up to the email architecture. And since this tends
to either be fully hardcoded or implemented in a base configuration that's
rarely changed, it's a significant contributer to why email hasn't had that
many problems with people messing around with addresses when they shouldn't.

Milter changes this. Since it operates at the MTA level, and includes add and
delete recipient that don't respect address ownership, it lets any yahoo who is
capable of filling in the blanks in a generic milter server template do really
bad things.

Again, I don't think there's anything we can do about it other than to continue
to hold the line on not mangling other people's addresses. But whether this and
other threats justifies ignoring the complex cases in favor of delivering a
simple message (sic) is the part of the decision we need to make here.

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

Translucent, maybe?

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

I see the main point behind the MDA and MSA as being the places where final
delivery and submission occur. This approach is also far from perfect: Among
other things it makes a mess of the placement of sieve, since the sieve
specification is clear that sieve can happen anywhere from right after the
determination an address is local to long after final delivery. (And subsequent
specifications have extended sieve to operate on message motions inside the
mesage store, including messages which may never have touched the transport 
infrastructure, which while useful is something of an architectural disaster.)

But we already have to accept that the block diagrams don't align with
implementations; we may also have to accept that they oversimplify actual flows
between components. (We have multiple customers who use MTAs queues to
implement a backup facility for their message store. I wish I was making this
up, but I'm not.)

				Ned