On 8/9/2021 8:37 AM, Viktor Dukhovni wrote:
On Mon, Aug 09, 2021 at 07:45:34AM -0700, Dave Crocker wrote:
What I've observed from this latest review is:
1. In all cases, the Delivered-To field contains a string that is
in the form of an email address; that is: Mailbox (from RFC
5321)
* The message might never have been transfered via SMTP in the first place.
* The address in question is placed in a message header, rather than used
in an SMTP command.
Therefore, Postfix uses an RFC*22 encoding, addr-spec per:
https://datatracker.ietf.org/doc/html/rfc5322#section-3.4.1
but, IIRC Jeremy reported that when misconfigured by the operator,
Exim can emit an address-list per:
https://datatracker.ietf.org/doc/html/rfc5322#section-3.4
Interesting point. Not surprisingly, I'd be quite happy to have RFC5322
be the baseline reference, rather than RFC5321.
It does achieve independence of the transfer mechanism, which is useful,
per your example. There doesn't seem to be any inherent need to be
anchored to SMTP, especially given some existing practice of 'internal'
transformations, which occur after SMTP has left the scene (assuming it
was ever present.)
Anyone object to this change, making the syntax use RFC 5322 addr-spec?
2. The strings regularly appeared to be the same as was in the
SMTP RCPT TO command
This is rather site-dependent. For some systems this is always the
case, for others never the case, and there also cases where this depends
on the particular recipient.
Well, #2 was phrased essentially as a statistical observation, which
means it isn't intended to cover all cases.
So I think your comment moves us to #3, below...
3. Sometimes they had an alternative semantic, per the references
to an 'internal' form
This is not a different semantic, the address in Delivered-To is always
the output envelope recipient to which the message is delivered, rather
than the input envelope recipient that triggered the delivery.
In many (though perhaps not most) cases the address conveyed by the MTA
to the LDA is not equal to the input SMTP "RCPT TO" (or, more generally
the input envelope recipient address, when SMTP was not how the message
came in).
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?
Perhaps it would be helpful to add something non-normative, like:
The information can be the address specified by the message author
or by a later mapping to an Internet address by an intermediary, or
it can be an internal reference to the mailbox, made by the system
effecting final delivery.
Thoughts?
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?)
Continuing the idea of adding non-normative description, perhaps adding
further, to the above "Perhaps" candidate text:
The internal reference can be produced according to whatever rules
the local system imposes. Examples include: using a different
domain name due to further internal routing, or mapping the local
part to a user account identifier.
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. (Note that the text does not prohibit random tokens, within the
syntax of an email address, but without an example of current use, it is
too theoretical to include in the list of examples.)
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.)
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp