At 8:44 PM +0100 1/17/07, Harald Alvestrand wrote:
(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.)
I haven't seen that possibility raised. I'm somewhat skeptical that
it would be an improvement (it makes the delay before error
reporting variable), but it's worth a discussion. WG?
If it is a temporary failure, and the message is sent successfully
after retrying, then it was a good thing to do. If there is always
an ASCII-only SMTP server in the path, then retrying only adds delay
to the failure. So: is it advisable for a system to be optimistic
that the message will be able to be sent? I think so, as the
document says:
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.
This makes the most sense when sending non-ASCII to non-ASCII, I
think. It also makes sense when sending ASCII to non-ASCII and the
sender's submission server is UT8SMTP compliant. I'd probably not do
it when sending non-ASCII to ASCII.
In any event, I think this is a quality-of-implementation thing: it
should be suggested by the documents but certainly not required for
compliance.
--
Randall Gellens
Opinions are personal; facts are suspect; I speak for myself only
-------------- Randomly-selected tag: ---------------
Arguments are to be avoided; they are always vulgar and often convincing. --Oscar Wilde
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf