On Fri 13/Aug/2021 04:49:44 +0200 John Levine wrote:
> It appears that Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> said:
>> 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.
>
> As far as we know, all of the existing usage is for loop detection, so it
would
> be reasonable to say the contents of the header is a token or sequence of
tokens
> with semantics local to the MTA that adds the header. I suppose we could say
something
> like what we say with Message-ID, to use a local domain to avoid collisions.
>
> What is not reasonable is to overload this existing header with new,
incompatible
> semantics and no way to tell the difference.
Without formal overloading, there is no reason to exclude the
possibility that an MTA records (virtual) mailbox addresses in that
field. Local MTA scripts can use the values of Delivered-To: fields,
if they can be interpreted correctly. Also MUAs can take advantage of
any mailbox values found there, as a sponger. For example,
Thunderbird has a configuration item named catchAllHeaders which can
be set to a list such as "envelope-to, x-original-to, to, cc,
delivered-to".
How about:
"Delivered-To:" FWS addr-spec / opaque-tokens FWS CRLF
?
This makes no sense to me at all. Nothing prevents you from using address
syntax - specifically the local part - to encode a value that only you can make
sense of. (My only concern is the length limit, but nobody else has echoed this
sentiment.)
Indeed, the ability of the domain to signal that this is your token, rather
than someone elses that might be similar enough to fool you, is pretty useful.
After all, interoperability with MUAs and local operations is one of
the experimental goals.
IMO this is the opposite of interoperability, and given that no evidence
has been presented of anyone using this format, I see no reason to make
such a change.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp