(3) In section 4.3:
the risk should be
minimized by the fact that the selection of submission servers are
presumably under the control of the sender's client and the selection
of potential intermediate relays is under the control of the
administration of the final delivery server.
[snip]
For situations in which a client encounters a server that does not
support UTF8SMTP, there are basically two possibilities:
o Reject the message or generate and send a non-delivery message,
[snip]
o Figure out a way to downgrade the envelope or message body in
I apologize if this has already been discussed, but in light of
the first quoted sentence, the two possible actions can be
augmented by another approach: try an alternate MX host and/or
requeue the message and try later. That is, because the mail path
is normally under administrative control of the end points or
their organizations, it may be reasonable to conclude that
UTF8SMTP is normally supported along this path, and if a system is
encountered which doesn't support it, this may be a temporary
failure. Obviously, if this is tried but persistently fails, one
of the other two methods must be used.
(This could also be mentioned in the smtpext document.)
