Re: [Emailcore] Delivered-To issues

[John C Klensin <[e-mail]>]

--On Friday, January 1, 2021 08:24 -0800 Dave Crocker
<[e-mail]> wrote:

> On 12/31/2020 1:09 PM, Dave Crocker wrote:
>> 3. ?
> 
> 
> Drat.  Just started to throw some basic text into a draft and
> I've already run into an issue that might or might not creates
> some challenges.
> 
> Rather than pursue this in terms of fine-grained details, I'll
> ask you all to first consider what information we would like a
> recipient's MUA to have access to.  Then we can worry about
> how to engineer the details.
> 
> In the simple case, the RCPT TO contains an address and,
> indeed, the recipient's MUA resides at that address.  The
> message has gone through a single SMTP posting/delivering
> sequence.
> 
> Mailing lists (including Aliases) and other post-processing
> facilities, make things more interesting.  They create
> multiple posting/delivery sequences.  The final recipient
> address is not what the author generated in the initial RCPT
> TO field.
> 
>       Should the recipient's MUA have access to the /sequence/
> of RCPT TO
>       addresses used to get to them?
> 
>       Should they have only the final one?
> 
>       Should they have only the original one?
> 
>       Should they...?
> 
> 
> Thoughts?

Dave,

Despite your comment about semantics of the "for" clause (with
which I agree - see note about navigating 5321bis), I think two
parts of the above are fairly clear for another reason: if the
message passes through an MTA and is either passed along or
altered an any way, the general expectation is that it will put
in a Received: header field.  And stripping or altering prior
Received: headers or header fields is generally considered bad
practice [1].   If either of those things are not clear enough
in 5321bis, I encourage you to post a specific comment about
that and encourage either Alexex to open a ticket and/or me to
make Appendix G longer [2].

First, one Received: header field, at most one FOR clause and,
if FOR is present, its value is one (see the syntax for FOR)
Mailbox (or, in principle, a PATH, but source routes are rather
strongly deprecated (see Section 3.3 and Appendix C).  So, if
one wanted to have multiple destination addresses, there would
be no place to put them. In addition, while 5321 does not appear
to make the issue explicit, the discussion in Section 3.3 about
exposure of addresses can be read as discouraging use of FOR
clauses in trace information entirely.

Beyond that, while, as you have pointed out, there is no
specification of semantic in 5321 (or 821 or anything in
between), there are common-sense limitations on what can go
there.  For unextended SMTP MTA in mail transport (not
submission server) use, the only places a Mailbox can cone from
are a MAIL command (makes no sense), RCPT command(s), and prior
"Received:" header fields (which it is prohibited from
inspecting).  A submission server (or other MTA communicating
directly with an originating MUA if there is such a thing) might
have additional or alternate information that could, in
principle, be put into the FOR clause, but that is it.  So, if
something is going to be copied into a Received-type trace
field, it has to come out of the RCPT commands to the SMTP
server inserting the trace field (again, possibly excepting the
first hop).

That doesn't answer any of your questions above, but it imposes
rather severe constraints on the information that might be
available.

best,
   john




[1] See the paragraph starting "As discussed in Section 6.4..."
in Section 3.6.3.   I now wonder whether that section should be
retitled or reorganized because it contains significant text
that is not limited to Message Submission at all.  Watch for a
separate message on parts of those two sections.

[2] Except for order and unless one of us gets it wrong, those
options are essentially equivalent.
> 
> 
> d/
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net