--On Saturday, November 23, 2019 21:19 -0500 Valdis Klētnieks
<valdis(_dot_)kletnieks(_at_)vt(_dot_)edu> wrote:
On Sat, 23 Nov 2019 07:35:00 -0500, John C Klensin said:
(4) Now, assume that you were confident you could really
gather community consensus that a change would be a good idea
for use in specific contexts. The way to do that would be to
define an SMTP extension for longer local parts in the kinds
of applications you cite, imposing whatever new restrictions
you thought appropriate. By contrast to (3), that would be
easy. No modification to 5321 would be needed and legacy
embedded applications would either not recognize the
extension mechanism or would not offer or request the
extension.
Figuring out what to do with an email that contains a 158
character username when you attempt delivery to a server that
doesn't support the extension is left as an exercise for the
reader. :)
(HInt: The proper action is probably different for sender and
recipient fields...)
Well, actually, if that were done as an SMTP extension, it is
quite clear... or better be if the extension proposal is going
to have any hope of getting IETF consensus. First, unless the
server advertises that it supports the extension, the language
of 5321 essentially says that the client is not allowed to send
those longer local-parts. If it did, I assume that the server
would respond with a 501 syntax error (although the way
821/2821/5321 are written and the robustness principle says it
doesn't have to). If the server announces support for the
extension, it is required to do whatever the extension says it
should do, presumably supporting the long local-part.
So I don't see much ambiguity or reader exercise there at all.
With regard to the difference between backward-pointing and
forward-pointing addresses (i.e., sender and recipient fields),
one thing I think we've learned from the SMTPUTF8 ("EAI", RFC
6530ff) efforts is that systems that are more permissive about
the first than the second eventually get themselves into
trouble, if only because of the potential to need to generate
response messages or, if those envelope addresses pass through
into the message body (e.g., by having the same address in the
"From:" header fields that appears in the address argument to
the MAIL command) or user-level replies.
There is another lesson from the SMTPUTF8 work that should
inform any proposal that is written. While the delivery MTA has
to know whether to advertise the extension or not, it generally
has no way to know what MUAs or other interfaces are going to be
used to retrieve and process messages from the mailstore. If
some of those are capable of handling the extended addresses
(extended in terms of characters present or extended in length
if this turns into a proposal) and others are not, the result is
a fairly complicated situation. For UTF-8 material, some of
the issues are addressed in RFCs 6533, 6855, and 6856 (and maybe
6857 and/or 6858) but any proposal to make a different exception
to the rules in 5831 would have to examine and address similar
issues.
I still think such an extension proposal would be easier, much
easier, to get through the system than one to simply remove the
64 octet limit on local-parts.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp