Subject: [EAI] Comments on draft--eai-utf8headers-00

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 30 Jun 2006 16:24:05 +0100

....  This document specifies the use of Unicode encoded in UTF-8,
    rather than ASCII, as the base form for Internet email header field
    bodies.  This form is permitted in transmission only if authorized by
    an SMTP extension, as specified in an associated specification.

Not quite. SMTP is not the only transport mechanism that exists (though it  
is by far the commonest). So messages using this draft could be permitted  
by any transport mechanism capable of supporting it. So please can we say  
"... only if authorized for use with the tramsmission  mechanism (e.g. by  
the SMTP extension specified in a companion document)". Or something along  
those lines, and also at other places where SMTP is mentioned.

1.  Introduction

1.1.  Role of this specification

Please can we have an extra bullet:

o The capability to use non-ASCII content in various other headers where  
it has not hitherto been permitted.

{I have in mind particularly <parameter>s in MIME headers and URLs in  
various List-* headers, but doubtless others will arise from time to time).

2.  Background and History

s/more the less/more or less/

    ... This protocol specifies UTF-8 as the encoding to
    represent email header body.

s/email header body/email header field bodies/
(RFC 2822 uses the term "header field body" for what I think you mean.)

    ... These changes affect SMTP clients, SMTP servers, and
    mail user agents (MUAs).

You can add "list expanders" and "gateways to other media" to the list.

s/Use this SMTP extension/Use of this SMTP extension/

    Those protocols will need to be changed ...

s/will/also/ (or s/will/will also/)

3.  Terminology

    s/the bodies of headers/the bodies of those headers/

4.  Pre-requirement

    The use of UTF-8 header fields is dependent on the use of an SMTP
    extension named "i-Email".

See remarks about SMTP earlier. Also s/i-Email/Utf8smtp/ {or whatever}

    That protocol is defined in [EAI-SMTP-extension].  If that extension
    is not supported, UTF-8 header fields MUST NOT be transmitted.

s/transmitted/transmitted by SMTP/

    Sending MUAs that follow this protocol MUST create all header fields
    encoded in UTF-8.  No other direct encodings are allowed.

I don't see why stuff encoded by RFC 2047 should not be allowed. Not  
particularly sensible if UTF8 is available, but you might, for example, be  
replying to a message which already had RFC 2047 in its Subject, and the  
easiest thing to do is just stick "Re:" on the front of it (or maybe not  
even that).

5.  Identification of internationalized email

    i-Email: 1.0

    [Note in draft: There should be more useful information can be place
    in the new header field. ]

Yes indeed. I have suggested the following syntax:

    header-content = "Header-Content:" [CFWS] content-code [CFWS]
                         *( ";" parameter ) CRLF
{point out that <parameter> brings some more [CFWS] with it)
    content-code = "Utf8smtp" / "ASCII" / "Downgraded"
which really needs to be followed by
       Header-Language = "Header-Language" ":" [CFWS] Language-List
       Language-List = Language-Tag [CFWS]
                          *("," [CFWS] Language-Tag [CFWS])
based in RFC 3282.

Of course, the following would need to be changed to suit. But there are  
also some other issues:

    o  The "i-Email" header field MUST be inserted by the originating
       MUA.
    o  The "i-Email" header field MUST be inserted, along with Return-
       path, by the final delivery MTA if not presented.

But how will the final delivery MTA know whether it is needed?

    o  The "i-Email" header field, if present, MUST be removed as part of
       any downgrading process that eliminates the UTF-8 header
       information.
    o  MTAs MAY check for duplicates of the "i-Email" header field and
       eliminate all but one of them.  However, if a receiving MUA
       encounters more than one of these headers, it SHOULD simply ignore
       any excess ones.

I think it is usually a bad idea for intermediate MTAs to try to "correct"  
perceived mistakes in messages passing through them. If the mistake is bad  
enough to break the system, then bounce it; othersise pass it on.  
Experience with News suggested that systems which tried to "correct"  
errors usually introduced more errors than they removed :-( .

6.  Changes on Message Header Fields

    For those tokens not referred in this section remains as the original
    definition in RFC 2822.

s/tokens/rules/

6.1.  UTF8 Syntax

    The use of UTF8 characters are defined as following.

s/following/follows/

6.2.  Syntax extend from RFC 2822

It's nice to see you adopted the syntax I suggested. Unfortunately, I have  
spotted some problems :-( .

    unstructured =  1*( [FWS] utext ) [FWS]

Yes, that is the rule as it would be for Netnews. For email, it can be  
empty. So:

    unstructured =  *( [FWS] utext ) [FWS]

    atext        =  ALPHA / DIGIT /
                    "!" / "#" /     ; Any character except
                    "$" / "%" /     ; controls, SP, and specials.
                    "&" / "'" /     ; Used for atoms
                    "*" / "+" /
                    "-" / "/" /
                    "=" / "?" /
                    "^" / "_" /
                    "`" / "{" /
                    "|" / "}" /
                    "~" /
                    UTF8-xtra-char

Here we have a problem, because that introduces Utf8 in atoms and  
dot-atoms, which is fine for addrs-specs (where we waant it), but also  
allows them in Message-ID and Received headers (where we most certainly  
don't want it).

There are two ways out of this:
1. use <strict-atom> etc for Message-ID and Received.
2. define a special <utf8-atom> etc for addr-spec.

I leave it to you which to do, but I can see some benefit in using  
approach #2, since we are going to tinker with the syntax of addr-spec  
anyway, in order to include <alt-address> and "atomic".

You also need to decide how much, if any, of the obs-syntax needs to be  
changed. Probably none of it since, because you MUST NOT generate it, a  
piece of obs-syntax with Utf8 in it should just never happen.

    stct-addr           =   stct-local-part "@" stct-domain

please s/stct/strict/ throughout ("stct" is just not an obvious  
abbreviation for "strict").

    alt-separator  =  [FWS] "," [FWS]

candidates for this are ",". ":" and "|", where "|" would require a  
special syntax in place of <addr-spec> within <angle-addr> (though it wold  
be OK within <alt-address>). I preter "|" over ":" and ":" over "," (there  
are already too many other uses of "," within address-lists and mailbox  
lists).

       DISPLAY NAME <IEMAIL@IDNA>
          ; i-Email but no ALT-ADDRESS nor ATOMIC option provided,
          ; message will bounce if i-Email extension is not supported

s/IDNA/UTF8/ (It won't be IDNA until it gets downgraded, if ever)

       DISPLAY NAME <IEMAIL@IDNA , ATOMIC>
          ; i-Email with ATOMIC option provided
          ; message is good for downgrade

s/IDNA/UTF8/
s/for downgrade/for downgrade by ACE/

7.  Additional issue

I think you need to deal with the MIME headers here. In particular,  
<value> (as used in <parameter>s) needs to allow Utf8 within it (with RFC  
2231 as the downgrade mechanism). <Token>s (being identifiers) ahould, of  
course, remain in ASCII.

7.1.  Mailing list header fields

    All mailing list and mail redistribution related header fields may
    need further investigation.

I agree. RFC 2369 and RFC 2919 are the relevants specs. RFC 2369 uses URIs  
for everything, and these would naturally become IRIs (RFC 3987), which  
already have a well-defined downgrade to URIs. I see that RFC 2919 makes  
use of <phrase> and <dot-atom-tsxt> (so we need to decide which kind of  
<dot-atom-text> that would be).

8.  Security Considerations

    If a user has a non-ASCII mailbox address and a all-ASCII mailbox ...

s/a all/an all/

    Because UTF-8 often requires several octets to encode a single
    character, internationalized local parts may cause mail addresses to
    become longer.  Then may possibly make it harder to keep lines in a
    header under 78 octets.  Lines that are longer than 78 octets (which
    is a SHOULD specification, not a MUST specification, in RFC 2822)
    could possibly cause mail user agents to fail in ways that affect
    security.

I think you want to make it clear that the '78' limit is to be expressed  
in characters, not in octets, since its purpose is to make the text fit  
within the commonly used 80-character-wide windows. OTOH, the '998' limit  
is definitely in octets, since it is related to the size of buffers that  
implementors need to provide.

There is a further security consideration which can arise if the utf8- and  
alt- addresses point to totally different people. I am not sure what sort  
of scam could make use of that, but spammers are, in general, most skilled  
at exploiting any possible loophole, so I think it needs to be mentioned.

9.  IANA considerations

All new headers that you invent need to be registered with IANA, in  
accordance with RFC 3864. And any headers that you modify need to have  
their registrations modified, so as to refer to your specification in  
addition to their current definitions.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima