ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Fwd: New Version Notification for draft-crocker-email-deliveredto-05.txt

2021-08-15 16:19:21
On 8/13/2021 12:04 PM, Viktor Dukhovni wrote:
On Fri, Aug 13, 2021 at 11:02:19AM -0700, Dave Crocker wrote:
The strings we have documentation for do not look nearly as abstract
as the term token implies.  Rather, they look like email addresses.

The above shows a profound unwillingness to look beyond the apparent
syntax to the semantics committed to by the MTAs that are using this
header.  The extant implementations of "Delivered-To" make no promise
to record anything recognisable to any party other than the MTA.

Documenting existing practice means documenting practice that actually exists.

Hypothesizing about what might sometime be done by someone somewhere, when there is no evidence it will be done -- nevermind that it has not yet been done -- is not documenting existing practice.

And by the way, the document is quite clear that loop detection is only one use it can be put to and that loop detection often involves a complex of methods.

So I don't really know what you mean about looking to the semantics, since the document supports the semantics of current practice.

Since you disagree, please be specific. What semantics are there, in current practice, that are not supported by the current draft?


At least in the case of Postfix, we specifically go to the trouble of
optionally prepending a separate "X-Original-To" header which records
the input address that led to the recipient, which in contrast to
"Delivered-To" is specifically intended for consumption by downstream
user agents.

The creation of other, independent header fields, has nothing to do with the technical details of this field.

Since you disagree, please be specific about the details of the current draft that need to be changed, to reflect current practice for THIS header field.

(If this sounds the same as the request, above, it's because it's the same request.)


It is not acceptable to violate the interface *contract* and saddle the

That's nicely forceful and legalistic language, but there isn't a contract. There is a goal of being compatible with existing practice, which this draft is.


"Delivered-To" header with new semantics, whereby the recorded address
is anything other than an opaque token.

Sorry but the existing practice is the syntax of an email address and, often, actually the email transport recipient address.

Claiming otherwise might satisfy one's sense of abstraction, but goes beyond existing practice.


No matter how many times you repeat that "Delivered-To" is in practice
observed to be some variant of an actual email address, Postfix will
retain the right to use some other semantics that, while conforming to
an "addr-spec", may hold something that only the generating MTA can
generate and recognise.

Implementors are always free to deviate from a specification.

Whether that defeats interoperability is a different matter.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

<Prev in Thread] Current Thread [Next in Thread>