On Mon, Aug 09, 2021 at 09:35:00AM -0700, Dave Crocker wrote:
OK. The current draft does not actually declare details about the
semantics of the string, other than the very general:
"The header field contains information about the individual mailbox
that is used to determine the immediate location for that
transition."
It might be ok to leave this without more detail. Simpler and less
constraining.
If we add more detail, why would it be important to the use of the
specification?
The key unanswered question is what the "audience" for the header
content.
If it is just MTAs for loop detection or else diagnostic information for
a human reader, then the format need not be strictly specified, each MTA
records what it wants to record, and then deals with its format should
the message come back around.
The human reader can read the tea leaves as best he can.
If the draft's intent is to expose the header for MUA consumption, then
it would need to be more clearly specified, but this is not compatible
with existing practice, and that role is played by various other
headers, and perhaps specifying a common header to consolidate:
- X-Original-To: (Postfix)
- Envelope-To: (IIRC Exim)
- ...
would be a more useful exercise than trying to saddle Delivered-To
with a new purpose.
*WHY* are we talking about this draft??? What actual problem is it
trying to solve?
4. These internal forms appear to be a variant of the address that
was in the RCPT TO command
They are not "variants" they are derived from the input envelope
recipient address, but can be any combination of:
* A change in the domain part to effect a routing change.
* A change in the local part to map from a First.Last or
similar public identifier to a user account identifier, ...
* An individual recipient of an email addressed to a group
mailbox (a list alias).
* Replace the local part with some LDA-private loop-detection token
(I assume LDA means local delivery agent?)
Yes, a.k.a. MDA.
I left off the reference to a token because, so far, we have not seen an
example of such an arbitrary string, in spite of repeated references to them.
Even if not currently done, Postfix is under no obligation to record
the actual address rather than some obfuscated hash, ...
I left off the alias reference because, really, that's just an example
of mailing list behavior. (Yes, I understand that the implementation is
quite different, but especially for this topic, the external observables
are the same.)
The reason that list expansion came up, is that the original text
repeatedly mentioned Delivered-To recording the *input* envelope
recipient (via RCPT TO), but list expansion replaces an input
envelope recipient with multiple output envelope recipients, and
in some cases these are then the "Delivered-To:" addresses in
the various recipients' individual message copies.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp