On 8/12/2021 11:36 AM, Ned Freed wrote:
>> On 8/9/2021 8:29 AM, Ned Freed wrote:
>>> 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.
I would very much prefer the syntax to just be Mailbox. But what with
the excited concern for covering established practice, this alternative
syntax seemed necessary.
Something I managed to find one or two occurences of by looking through tens of
thousands of old messages is rather different than the behavior implemented
several of the most widely used MTAs.
It's also different in that the use of the field in those MTAs is strictly for
loop detection, which makes the format a local matter. The draft aims for a
different - and in some cases disjoint - logging usage, which really calls for
a common syntax.
This does not make me particularly happy, BTW. Our MTA doesn't currently
support this particular type of loop detection, but if I were to add it the way
I'd prefer to do it would produce a result that's a bit too big to put in a
mailbox. I'd end up having to use a different field. A looser syntax would
be handy.
There's an alternate way to do the loop detection that's much simpler and would
fit in a mailbox (!), but I haven't managed to convince myself that it never
expose something that shouldn't be exposed.
However, given your enthusiastic prompting -- which I will take as
support -- I'll revert the syntax, but add some text noting the issue.
Anyone objecting strongly is encouraged to comment with explanations for
why just having the field contain a string in the form of an email
address is not sufficient.
For logging purposes it's a restriction you want to have. For loop detection
it's a restriction you don't need, but if you're going to use the same
field name for both the need for legible logging has to take precedence.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp