ietf-smtp
[Top] [All Lists]

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

2021-08-12 14:02:25
On 8/9/2021 8:29 AM, Ned Freed wrote:
>> On Sun, Aug 08, 2021 at 07:02:02PM +0200, Alessandro Vesely wrote:
>> Nobody puts unstructured phrases into "Delivered-To".  There are no
>> display names in this context, because the payload is derived
>> exclusively from an envelope address.  The "phrase" bits are redundant
>> and incompatible with current practice.
>
> Unfortunately this is not the case. Here's one example, from last year:
>
>    Delivered-to: mailing list toyota-prius(_at_)yahoogroups(_dot_)com

ahh, thanks.  That's an example of what I thought I'd seen but couldn't
find this morning.

> In any case, the real question, I think, is not whether or not examples can be
> found of incompatible use of this field - they can - but whether we want to
> require implementation to support what is best a rare usage. Speaking for
> myself, I think the answer should be "no".

Different semantics, within the framework of the same, email-address
syntax, seems a relatively minor point to me, and is arguably covered
adequately by the generic prose already in the draft, about the nature
of the string.

I'm talking about syntax. Not semantics. Requiring that implementations parse
what is effectively a new string format - AFAIK there is no  other place in any
of our specifications where

  FWS *phrase Mailbox *phrase

is used - may not be a significant burden to folks who spend a lot of time
dealing with email syntax, but to people who just want to hack something
together using some random email routine library, it's an issue. Having looked
at a lot of code written this way, the likely outcome is that they will call
something that's "close", which will probably handle  the case without the
phrases but will fail or produce bogus output when they are.

And as far as semantics are concerned, your syntax assumes that the the prefix and suffix parts are not, in fact, part of the mailbox. That
may or may not be correct.

On the other hand, the difference between allowing arbitrary text
(phrase) in the field's payload seems a big deal to me.  As noted, it
messes with parsing, given the absence of the usual delimiters.

Having the spec formally exclude an existing practice is obviously a big
deal.

When formalizing things we often exclude rare practices that greatly
complicate things, especially when those practices are semantically
ambiguous.

                                Ned

_______________________________________________
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>