Re: [Emailcore] Navigating 5321bis (and predecessors)

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

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

> On 1/1/2021 12:18 PM, John C Klensin wrote:
>> (1) How much reorganizing and rewriting do we want to do and
>> what are our stopping rules?
> 
> None of the first and as little as is reasonable of the
> latter.  The purpose of the current effort is to expedite
> elevation to full Standard.   Any effort that is 'substantial'
> puts that at risk.

Speaking personally, agreed.  However, I note that we have
already moved one paragraph and that counts as "reorganizing",
at least as I used that term.  I would summarize the principle
as "don't open cans of worms", but that interpretation of your
comment has some interesting implications.

> In the case of the particular issue I raised about 'FOR', it
> makes sense to add some text that defines its semantics.  It
> doesn't make sense to make a major effort of -- or resulting
> from -- that.

An interesting example because, as soon as we try to pin down
the semantics, we probably should address the question of
whether, in today's privacy-sensitive world, supplying that
clause at all is a good idea [1].   It may be relevant to a
discussion of that topic that, while hop-by-hop transport
encryption would hide that information on the wire, message
headers (including trace fields) need to be in cleartext for
SMTP trace fields/ time stamps to function properly.

To make the situation a little more entertaining, RFC 6409 is
not explicit as to whether the submission server is required to
insert a time-stamp field although the requirement in the third
paragraph of Section 8 certainly implies that.  Because a
submission server is explicitly allowed to resolve local aliases
(important for SMTPUTF8 and I have no idea what people on this
list call others in the privacy of their local environments),
exposing one of those aliases in a FOR field might be a bad idea
even if it had the syntax of a Mailbox name.

In other words, while I would favor putting in some words about
the semantics of the FOR clause (and any other clauses of a
time-stamp field whose semantics are missing or vague), we need
to understand that even something that seemingly trivial might
open one of those cans of worms.

    john


[1] Note that aspect of the FOR clause is already addressed,
albeit with a bit of handwaving, in Section 7.6 _and_ I don't
even know exactly what the last sentence of that section means
given that a given Received: field can only accommodate at most
one FOR clause with exactly one Mailbox (now noted in -02).