Re: [EAI] New draft for allowing UTF-8 inSMTP responses

Martin Duerst wrote:

> TR9 is an Unicode Standards Annex (UAX), which means it is
> part of the Standard. In many ways, at the very moment you
> say UTF-8, you include it.

You could take UTF-8 as "ASCII plus opaque garbage" in various
protocols, and then other parts of [Unicode] are not relevant.

Nobody's forced to use say Unicode collation or hyphenation
only because (s)he uses UTF-8 referencing STD 63,  Another
example would be 3066bis, it references ISO 3166.  Nobody
using language tags is now forced to use also 3166-3 codes,
they can still make up their own stuff, use CLDR or what else.

> as most of us know and Harald has shown again, the situation
> with SMTP error message consistency is much worse than with
> any other, comparable protocol.

The RFC 4408 folks made sure that URIs work, indirectly that
arrives as whatever e.g. http offers.  A scenario for RFC 4408
is a user trying to send on a route not permitted by the sender
policy of his domain.

What really happens:  User submits mail to the "wrong" MSA, and 
this MSA doesnt't enforce submission rights (RFC 4409 6.1), it
tries to forward the mail towards the recipient.  The MX checks
the sender policy (RFC 4408) by querying a nameserver of the
domain in the Return-Path.

That policy says "FAIL" and offers an explanation in the form
of an URI (optional of course).  The MX "encodes" this as 5.7.1
error response (RFC 2034) - oops, the 2034-reference was still
correct in draft 00, odd, maybe the missing 2034 was my bad -
while talking with the "wrong" MSA (or its mailout).  Of course
the MX is not forced to add the explanation of this third party
to its 5.7.1, but it can, let's assume that it did.

The MSA had accepted the mail for forward or delivery, and that
didn't work, therefore it MUST (RFC 821/2821) generate a non-
delivery message (aka "bounce", not the definition in 2821).
It will probably copy the 5.7.1 error message verbatim into
its non-delivery message.  

It then puts the error message in the mailbox of the user of
this domain.  Or forwards it if the user arranged it this way.

Later the user finds the bounce, that quotes the 5.7.1 (maybe),
and the 5.7.1 quotes the FAIL-explanation (maybe), that is an
URI, and now the user can contact that URI (maybe), and if it
is HTTP depending on the server, the browser, LTRU, matching,
and some other details the user can read the explanation of
an admin in his domain in their preferred language, why this
mail didn't make it on the wrong route.

That's in a nutshell the reason why there are no explicit I18N
considerations in RFC 4408:  It would never do to tunnel some
non-ASCII text from DNS through a 5.7.1 and a bounce, besides
it would be pointless, the domain can have many users with many
different languages.

Frank

_______________________________________________
IMA mailing list
IMA@ietf.org
https://www1.ietf.org/mailman/listinfo/ima