ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] smtp extension model

2016-08-26 15:00:51


--On Friday, August 26, 2016 12:29 -0700 John Bucy
<jbucy(_at_)google(_dot_)com> wrote:

On Mon, Aug 22, 2016 at 3:48 PM, John C Klensin
<john-ietf(_at_)jck(_dot_)com> wrote:
...
If I were the relay or host accepting that connection, I'd
generate the "does not accept..." reply the moment I saw
SMTPUTF8 and/or a non-ASCII address (i.e., in response to the
MAIL command in the example above) but, unless something snuck
into 6531 when I wasn't looking, that is a matter of taste
rather than an absolute requirement.  In particular, the last
paragraph of Section 3.6 explicitly allows the error response
after RCPT.  There would be no choice other than to do it then
or after DATA (see that paragraph) in either of the following
circumstances (there might be others):
...

It seems like the best time for this to happen would be during
submission where the mua is in a much better position to deal
with the failure than some other mta in the middle. How evil
would it be for the msa to remember which hosts it's talked to
recently that accept a given extension to propagate back to
its clients?

Yes, well...
First, a great many options about what should be done where were
extensively considered during the two stages of SMTPUTF8/ EAI
development.  What follows is a summary, probably a poor one, of
some of those discussions: if you or others need more
background, there is probably no substitute for the archives
which perhaps you could motivate getting back online.

That said, the MUA and MSA are the only entities in the system
that can really do something intelligent, particularly
determining and substituting ASCII-only addresses for ones that
are partially non-ASCII.  Those substitutions are obvious on the
backward-pointing (aka sender address) side if a user maintains
both types of addresses but, even on the forward-pointing side,
if the MUA or MSA can't figure it out, anything further
downstream can, at best, get a "you lose" message back to the
user (no matter how much information that message contains).

The MSA does need to be careful about caching for all of the
usual reasons, e.g., how to detect when something has changed.
But logic suggests that, one a site converts to and starts
advertising SMTPUTF8, it is unlikely to discontinue the service
so remembering where it was successfully accepted seems sensible
even if the code needs to be good enough to deal with a failure
to accept it later.

Some care is in order because, while I don't know anyone who has
done it yet, it would be perfectly reasonable for a delivery MTA
to keep a list of which addresses are UTF-8 capable down to the
webmail client or IMAP or POP server being used by that
particular user and to decline, at RCPT time, to accept SMTPUTF8
if the user couldn't or wouldn't read the messages.  So, if one
were being extra-careful, one would need to remember that
information on a per-recipient basis, not just a per destination
host one.

Similarly, it would be sensible for an originating MUA or MSA to
maintain an address book that contained all-ASCII alternative
addresses for users with addresses that require SMTPUTF8
capability so that, if it could be determined that extended
messages would not go through, the addresses could be rewritten.
It seems fairly obvious that users would like that more than
getting a bounce or error message that they then had to deal
with (including the delays).  However, implementing it well is
not as straightforward as one might guess at first glance.

best,
     john


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