Re: Fwd: New Version Notification for draft-crocker-email-deliveredto-05.txt
Dave Crocker <[email protected]> Sun, 15 Aug 2021 14:18:46 -0700
| Newsgroups | gmane.ietf.smtp |
|---|---|
| Organization | Brandenburg InternetWorking |
| Message-ID | <[email protected]> |
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