Re: delivered-to format (was: Re: Fwd: New Version Notification for draft-crocker-email-deliveredto-05.txt)

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