On Sun, Aug 15, 2021 at 02:18:46PM -0700, Dave Crocker wrote:
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.
When documenting *interfaces*, we do not document implementation
artefacts of what the interface happens to be doing. We document
the interface contract, i.e. what the interface is *expected* to do.
When I say that "Delivered-To" is an opaque token private to the MTA,
this is not an empirical statement. It is a statement of fact about the
contract between Postfix and the rest of the world.
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.
There is no hypothesis. See above.
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.
Other than loop detection, and forensic evidence trails, what else
motivates the draft?
So I don't really know what you mean about looking to the semantics,
since the document supports the semantics of current practice.
What is the nature experiment? If you're documenting current practice,
how can the draft be "Experimental"?
Since you disagree, please be specific. What semantics are there, in
current practice, that are not supported by the current draft?
What is the motivation for producting the draft? What problem are you
actually tryign to solve?
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.
Only if you're able to respond with a cogent reason for the draft to
exist, I haven't seen one yet, and no the listing of a few plausible
uses in the draft is not such a reason.
There needs to be a higher layer reason for defining the header at this
time, and clarity around whether any semantics are being imputed, or
we're just documenting existing syntax.
If the goal is to clarify existing syntax, then:
* Change the "Experimental" status, to "Informational".
* Make it clear that the value is opaque, and user agents
can make no assumption about the payload.
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.
If it binds the MTA to produce tokens that an MUA will be able to
parse and act on, then it is NOT compatible with existing practice.
"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.
No existing practice is the interface supported by the MTA, and the
MTA's freedom to make any and all changes that don't violate that
interface contract.
Claiming otherwise might satisfy one's sense of abstraction, but goes
beyond existing practice.
Surprisingly, you're conflating implementation with specification.
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.
No, specifications of existing practice can't ignore the interface
contracts of existing implementations, or else they're not documenting
existing practice.
In any case, the payload of the produced strings is sufficiently
variable given the various kinds of rewriting in play, that even without
the tokens going as opaque as say hex-encoded HMAC values the MUA cannot
treat the value as an identifier from which to extract a usable
recipient address.
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp