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.
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:".
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.
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.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp