--On Monday, August 22, 2016 13:53 -0700 John Bucy
<jbucy(_at_)google(_dot_)com> wrote:
On Fri, Aug 19, 2016 at 3:30 PM, John R Levine
<johnl(_at_)taugh(_dot_)com> wrote:
Yes, although with SMTPUTF8 we made a fairly clear
distinction that
you're on the bus or you're off, and an entire mail site
either supports it or not.
<https://www.ietf.org/mailman/listinfo/ietf-smtp>
This is a little surprising to me. I understood 6531 to allow
c: MAIL FROM: <utf8 sender> SMTPUTF8
s: 250 OK
c: RCPT TO: <legacy_application>
s: 553 5.6.7 <legacy_application> does not accept utf8 messages
Ignoring the surplus (and invalid) spaces after the colons...
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.
Some cases similar to the above --particularly when the server
doesn't know but finds out later-- can also involve situations
that require accept-and-bounce.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp