Re: [ietf-smtp] Experimental (was: Re: homework, not an experiment, draf

--On Tuesday, August 17, 2021 10:52 -0400 Viktor Dukhovni
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:

> On Tue, Aug 17, 2021 at 10:10:25AM -0400, John C Klensin wrote:
>
> > A slightly different point of view.  While something called
> > "Delivered-to:" has been widely deployed, it appears from the
> > discussions of the last months that there is less than
> > complete agreement about semantics, intended purpose, and
> > perhaps (I'm not sure) even the syntax of the header field.
> The field is known to be implemented since the 90's in three
> widely used MTAs: Qmail, Postfix and Courier.  All three use
> it for loop detection, it is private data for use by the MDA
> that adds the header field, should the message circle back for
> repeated delivery.
>
> In that light, edge-cases with a variant syntax are also a
> private matter for the MDA that uses such syntax.  So long as
> the header field value does not collide with a value used in
> any other ADMD, there's no problem.
I think this is a reasonable position.  However, it then
suggests, as I think you have earlier as well as below, that
this is not an Experiment but a description of existing
_private_ practices, which would make it Informational.  If we
are defining syntax (and I note your argument elsewhere), it
also suggests that MDAs identify themselves somehow in the field
so that one private use can be distinguished from another [1].
Of course, if all or part of the field were encoded in a way
that only one MDA could understand -- i.e., that an attempt to
decode it into someone usable would fail if the MDA doing the
decoding were different from the one that put it there -- it
would accomplish that purpose (see Ned's comment on the 13th
[2]).

> > The draft acknowledges those differences and has become more
> > clear and specific as we have moved along (thanks, Dave).
> > However, making the definition and statement of intent has
> > inevitably moved it much closer to some implementations and
> > conceptual models and further from others.  
> The draft doggedly refuses to specify the *semantics* of the
> field as private data for use by the MDA.  No motivating
> use-case is provided that justifies any imputed new semantics.
>
> Thus instead of clarifying the field's use, the draft muddies
> the water by (perhaps implicitly) suggesting that a
> conforiming MDA is bound to record an address that is proper
> input for divining the message by a downstream MUA.  For that
> use-case, the long-standing deliberate practice is to use
> alternative headers and NOT "Delivered-To:".
I am not completely sure, but I think we agree on that subject.

> > With one qualification, it seems to me that it would be a
> > legitimate experiment, well within the intent of BCP 9, to
> > create a definition this, or more, precise and then see
> > whether existing implementations that use this field or ones
> > that appear (at least superficially) similar to it evolve to
> > conform.
> The experiment is dead on arrival.  While Postfix (the largest
> deployment of "Delivered-To" by number of MTAs, though perhaps
> not by user count when compared with Gmail) conforms to the
> syntax described in the draft, we disavow any external
> interpretation of the payload, and will not participate in any
> experiment that reinterprets the field value as public data.
> For that we have "X-Original-To", but if someone wants to
> standardise "Envelope-To" or some other similar field, we'd be
> open to using a more widely interoperable header.
>
> > The qualification is that, while it would be interesting to
> > find out if this were the exception, we have considerable
> > experience that, if a feature is implemented and used by
> > implementations with particular syntax and semantics, the
> > odds of those implementations making changes that might
> > disrupt existing uses and operations and introduce confusion
> > as to whether the "old" or "new" definitions were in use is
> > vanishingly small.
> No changes to accommodate any new semantics will happen in
> Postfix.  If the entire scope of the "experiment" is to see
> whether a common syntax would be widely adopted, the
> "experiment" is already over, the common syntax proposed is
> already widely adopted.
> If the "experiment" aims to see whether MDAs will conform to
> semantics that enable downstream determination of the
> recipient by MUAs, then the "experiment" is also already over,
> at least as far as Postfix is concerned.  No change in the
> semantics making the value non-private data will implemented.
With the understanding that my "vanishingly small" is probably
the same in practice as your "over", that just reinforces my
point so, again, I think we agree.

> > Nonetheless, it would be a real experiment and it is not
> > clear to me whether the document needs additional work to
> > explain that.
> The document skirts the key question of why it is needed at
> this time. If the field payload is MDA-private, it hardly
> needs a specification, what is the purpose of a specification
> at this time, especially one that refuses to specify the key
> semantic property (private use).
>
> An informational document specifying how the field is actually
> used (to avoid any confusion) would make considerably more
> sense.
I'm becoming increasingly convinced of that.  I think that, if
there is to be an Experiment, it needs to start with a new
header field name and then either define both syntax and
semantics in a way that would make interoperability possible
-or- define a private-use field in which there was a clear and
interoperable way for one private instance to distinguish itself
from others.

best,
  john

[1] I am deliberately not making a distinction between "MDA" as
a particular implementation (like Postfix) or a particular
operational instance and configuration.  I don't think it makes
a difference to this discussion but it would obviously need to
be clear in any specification.

[2]
https://mailarchive.ietf.org/arch/msg/ietf-smtp/InmwN2cNEpTDPAn6cHfHmmwcwM8


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp