On Mon, Aug 22, 2016 at 3:48 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
Yes, it does. That is the entire mail site associated with
<utf8 sender> supporting it and the mail site associated with
<legacy_application> not doing so, so I think it is consistent
with John L.'s comment.
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):
(i) The server supports SMTPUTF8 but, in spite of
<legacy_application> being a local address, the server knows it
cannot accept messages with non-ASCII addresses or headers.
(ii) The server supports SMTPUTF8 but <legacy_application> is
not a local address or is a local address associated with an
alias that points to another host, so the server is acting as
relay or forwarding the message and knows that the remote server
doesn't support SMTPUTF8.
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?
ietf-smtp mailing list