Subject: [EAI] Preparation for Last Call, -smtp and -utf8headers documents

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 22 Mar 2007 15:24:03 +0100

After the discussion in Prague, the WG chairs concluded that the -smtext-04 
and -utf8headers-04 documents are technically ready for Last Call, but need 
at least one round of updates to deal with wording issues.

Therefore, we would like to ask all WG contributors to read these two 
documents carefully, and send messages (either to the authors or the 
mailing list) detailing ALL issues, large or small, language or technical, 
pertaining to these documents, that they believe should be addressed before 
the WG Last Call.

This comment gathering will last until *April 1*, at which time we will ask 
the editors to prepare a revised pair of documents that are ready for WG 
Last Call, in preparation for forwarding to the IESG for publication as 
Experimental.

                Harald, for the chairs

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

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 07:53:47 +0200

This chapter need addition (ALTERNATIVE 1: 'no HDR=UTF8SMTP parameter'):

    To discover which messages are UTF8SMTP, SMTP server needs
    parse all message header fields (including header fields from 
    MIME body parts). There is no ESMTP parameter which tell
    that message is UTF8SMTP message.

( If ALTERNATIVE 2: 'HDR=UTF8SMTP parameter' is selected then additions 
  are different. )

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 08:17:45 +0200

(7) the maximum length of a MAIL FROM and RCPT TO command line is 
     increased by 268 characters by the possible addition of the 
     ALT-ADDRESS keyword and value

/ Kari Hurtta

( RFC 2821  requires:

|   The IANA maintains a registry of SMTP service extensions.  A
|   corresponding EHLO keyword value is associated with each extension.
|   Each service extension registered with the IANA must be defined in a
|   formal standards-track or IESG-approved experimental protocol
|   document.  The definition must include:
|
|   -  the textual name of the SMTP service extension;
|
|   -  the EHLO keyword value associated with the extension;
|
|   -  the syntax and possible values of parameters associated with the
|      EHLO keyword value;
|
|   -  any additional SMTP verbs associated with the extension
|      (additional verbs will usually be, but are not required to be, the
|      same as the EHLO keyword value);
| 
|    -  any new parameters the extension associates with the MAIL or RCPT
|       verbs;
| 
|    -  a description of how support for the extension affects the
|       behavior of a server and client SMTP; and,
| 
|    -  the increment by which the extension is increasing the maximum
|       length of the commands MAIL and/or RCPT, over that specified in
|       this standard.

)

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 08:32:39 +0200

Perhaps another addition to this chapter:

    Paramater BODY=7BIT implies that message is not UTF8SMTP because mail
    data can not include 8-bit characters. On that case parsing of
    all message header fields (including header fields from MIME body parts)
    is not required.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 08:42:30 +0200

That chapter needs addition:

   If a server SMTP does not support the UTF8SMTP extension,
   then the client SMTP must not, under any circumstances, attempt
   to send UTF8SMTP message to server or attempt to use UTF-8 strings
   on MAIL FROM or RCPT TO commands.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 08:51:56 +0200

Another addition to this chapter
   (8) The reverse-path and forward-path on MAIL-FROM and RCPT TO
       commands are extended to include UTF-8 characters.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 09:04:43 +0200

And catch-all bullet to this chapter:

   (9) mail data is extended on compliance with [EAI-utf8header],
       the next chapters specifies how support for the extension
       affects the behavior of a server and client SMTP.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 09:19:15 +0200

I think that following text should be removed (it perhaps refers
to ATOMIC):

                           However, we can raise the knowledge level by
   supplying additional information.  Many human users' email addresses
   do not have any embedded structure processed by the final delivery
   MTA.  In that case, the sender can specify that these email addresses
   are safe to be converted in the predefined way.  The final delivery
   SMTP server can revert the addresses even though they are as in all
   ASCII form.  Unless the MUA or the submission server clearly knows
   that the non-ASCII address can be safely transformed into the all-
   ASCII address, the non-ASCII address should not be transformed
   because transformed email address may cause some potential problems.

/ Kari Hurtta

---

From: "Yao Jiankang" <[email-masked]>
Date: Sat, 24 Mar 2007 15:27:34 +0800

I will consider to remove it.
Thanks.

YAO Jiankang
CNNIC
----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 3:19 PM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#7): 2.5. The Suggestion 
ofthe Value of the ALT-ADDRESS parameter

---

From: "Yao Jiankang" <[email-masked]>
Date: Sat, 24 Mar 2007 15:36:20 +0800

yes, should mention it as many members has already said.

YAO Jiankang
CNNIC
----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 2:42 PM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#4): 2.7. Additional 
ESMTPChanges and Clarifications

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 09:35:46 +0200

Addition:

2.7.7. final delivery MTA

  The final delivery MTA must take care that it does not pass UTF8SMTP
  messages to Mail Delivery Agent (MDA) or message store (MS) which do
  not support UTF8SMTP. How this is arranged is outside the scope of this
  document.  

  This document suggests that the final delivery MTA does not announce
  UTF8SMTP support on EHLO reponse if MDA or MS does not support 
  UTF8SMTP.

And therefore change on chapter 1.3.  Terminology

                                                         The terms
   "ASCII address", "internationalized email address", "non-ASCII
   address", "i18mail address", "UTF8SMTP", "message" and "mailing list"
   are used with the definitions from the EAI overview document.

=>

                                                         The terms
   "ASCII address", "internationalized email address", "non-ASCII
   address", "i18mail address", "UTF8SMTP", "message", "mailing list"
   and "final delivery MTA" are used with the definitions from the 
   EAI overview document.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 09:49:15 +0200

Perhaps change:

  The internationalized email address protocols will impact on many
  email related RFC documents such as Message Submission [RFC4409].

=>

  The internationalized email address protocols will impact on many
  email related RFC documents such as Message Submission [RFC4409]
  and Local Mail Transfer Protocol [RFC2033].

Then chapter "9.2.  Informative References" needs addition:

  [RFC2033]  Myers, C., "Local Mail Transfer Protocol", RFC 2033,
             October 1996.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 11:22:56 +0200

HDR=UTF8SMTP  idea may require several changes:

To chapter "2.1.  Framework for the Internationalization Extension":

  4.1  An optional parameter is added to the SMTP MAIL  command.
       The parameter is named as HDR. The value "UTF8SMTP" indicates
       that message uses UTF8 header fields or includes another
       UTF8SMTP message on some mime parts.

  7.1  the maximum length of a MAIL FROM command line is 
       increased by 280 characters by the possible addition of the 
       ALT-ADDRESS and HDR keywords and values.

  7.2  the maximum length of a RCPT TO command line is 
       increased by 268 characters by the possible addition of the 
       ALT-ADDRESS keyword and value

(renumbering is required)

To chapter "2.6.  Body Parts and SMTP Extensions "

    Combination DATA=7BIT and HDR=UTF8SMTP is not possible, because
    BODY=7BIT implies mail data can not include 8-bit characters.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 12:58:22 +0200

Addition to end of chapter is perhaps needed:  

  When the recipient address is non-ASCII and delivery
  fails because lack of support of UTF8SMTP on recipient 
  MXes and downgrade is selected, mail is tried to deliver
  to address given on ALT-ADDRESS paramater (if given) on
  RCPT TO paramater.

( That is already mentioned on "2.2.  The Address 
  Internationalization Service Extension". )

/ Kari Hurtta

---

From: "Kari Hurtta" <[email-masked]>
Date: 24 Mar 2007 13:02:22 +0200

> yes, should mention it as many members has already said.

I did not noticed that this actually was already spelled out 
on chapter "2.2.  The Address Internationalization Service Extension"

Sorry.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 13:09:35 +0200

|  If it is replaced, the replacement MUST be the ASCII-only address
|  specified with the ALT-ADDRESS parameter.[EAI-downgrading].

That [EAI-downgrading] is little strange. Is there missing some text?
It needs sentence.

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 12:30:28 +0100

>      UTF8SMTP message on some mime parts.

| 4.1  An optional parameter is added to the SMTP MAIL command.
|      The parameter is named as HDR. The value "UTF8SMTP" indicates
|      that the DATA is a message/utf-8 using UTF-8 in header fields.

+1 to your other proposals, but somewhere we need a rationale
for this beast.  It needs its own section, and its own reply
code "missing HDR=UTF8SMTP, some receivers do not support it".

Quick shot:

 HDR=UTF8SMTP indicates that the DATA is a message/utf-8 with
 UTF-8 in the header.  Clients SHOULD NOT announce HDR=UTF8SMTP
 if the DATA is a traditional message/rfc822, or if only the
 envelope uses UTF-8 addresses. 
[Bad enough for MUST NOT ?]

 Clients SHOULD announce HDR=UTF8SMTP when sending a message/utf-8
 with more than one RCPT TO.  Servers can then reject the message
 selectively for mailboxes not supporting message/utf-8.
[Do we have a reply code for this?]

 Clients MAY announce HDR=UTF8SMTP also when sending mail only
 to one (or no) RCPT TO. 

 Servers SHOULD check that DATA sent without using HFR=UTF8SMTP
 really is no message/utf8 (treating garbage as message/rfc822).
 Otherwise they SHOULD reject the message with reply code "5xx -
 missing HDR=UTF8SMTP" after DATA if at least one RCPT TO is
 known to not support message/utf-8.
[incomplete, only relevant without downgrading] 

 Servers accepting a message/rfc822 (without HDR=UTF8SMTP) might
 add header fields using UTF-8 like a 'from' claus in a timestamp
 line.  This implicitly transforms the prior message/rfc822 (with
 an all-ASCII header) into a message/utf-8.

What's missing ?  DSN status code ?  

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 12:55:13 +0100

>   and Local Mail Transfer Protocol [RFC2033].

+1  

<alert lang="en-DE">  Should that be
    ..."will have an impact on many email related RFCs such as"...
? </>

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 13:06:48 +0100

>   not support UTF8SMTP. How this is arranged is outside the scope of this

I think "MDA" is more commonly used as synonym for "final delivery MTA",
treating that as unit ingoring all details.  It's okay if you split it
in your messagestore I-D because that I-D discusses these details, but
here I'd prefer to stick to the simple terms:

| The final delivery MTA must take care that it does not accept any
| message/utf8 for mailboxes not supporting message/utf8.  One way how
| this can be arranged is discussed in [I-D.hurtta-eai-messagestore].

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 13:15:53 +0100

>>   on MAIL FROM or RCPT TO commands.

s/must not, under any circumstances,/MUST NOT/

s/to server or/to this server, or/

s/UTF-8 strings/any UTF8SMTP extension like internationalized addresses/
[it also can't use HDR= or ALT-ADDRESS= parameters]

s/on/of the/ (if "extension of the" is better than "extension on")

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 13:30:18 +0100

> at least one round of updates to deal with wording issues.

Several rounds and more frequent drafts, please.  I don't
think that it's very near to a "last call" yet, more like
end of June than start of April.  

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 14:49:28 +0200

> here I'd prefer to stick to the simple terms:

I have interpreted MDA to be for example that thing what sendmail calls
for delivery to local mailbox. That think that "final delivery MTA" is
synonym of Mail Delivery Agent (MDA) is new to me. Because these terms
are not really not defined, that usage is possible (although unexpected :-))

( On http://en.wikipedia.org/wiki/Mail_Delivery_Agent there is one 
  usage. )

Anyway draft-crocker-email-arch-06.txt gives picture, what is 
somewhat similar and consistent my usage on messagestore I-D:

                  +------+                                   +---------+
      ............+ oMUA |...................................|  Disp   |
      .           +--+-+-+                                   +---------+
      . ******* imap}| |                                          ^
      . * oMS *<-----+ | {smtp,submission                         |
      . *******local}  |                                          |
      .                |     *****************                    |
      .         +------V-----*------------+  *MHS                 |
      .         | +------+   *   +------+ |  *      +---------+   |
      .         | | oMSA +---O-->| hMSA | |..*......| Bounces |   |
      .         | +------+   *   +--+---+ |  *      +---------+   |
      .         +------------*------+-----+  *           ^        |
      .          MSA         *      V {smtp  *           |        |
/+==========+\               *   +------+    *      /+===+===+\   |
|| MESSAGE  ||               *   | MTA  |    *      ||  dsn  ||   |
||----------||               *   +--+---+    *      \+=======+/   |
|| Envelope ||               *      . {smtp  *         ^   ^      |
||  SMTP    ||               *      V        *         |   |      |
||  RFC2822 ||               *   +------+    *         |   |  /+==+==+\
|| Content  ||               *   | MTA  +----*---------+   |  || mdn ||
||  RFC2822 ||               *   +--+---+    *             |  \+=====+/
||  MIME    ||               * smtp}| {local *             |      |
\+==========+/   MDA         *      | {lmtp  *             |      |
      .         +------------+------V-----+  *             |      |
      .         | +------+   *   +------+ |  *             |      |
      .         | |      |   *   |      | +--*-------------+      |
      .         | | rMDA |<--O---+ hMDA | |  *                    |
      .         | |      |   *   |      | |<-*-----------+        |
      .         | +-+----+   *   +------+ |  *           |        |
      .         +---+--+-----*------------+  *           |        |
      .             |  |     *****************           |        |
      .     pop} +--+  +-+                               |        |
      .    imap} |       | {local                        |        |
      .  ****************V*******                        |        |
      .  *       |   +------+   *rMS                /+===+===+\   |
      .  *       |   | srMS |   *                   || sieve ||   |
      .  *       V   +----+-+   *                   \+=======+/   |
      .  *  +------+  pop}| |   *                        ^        |
      .  *  | urMS |<-----+ |   *                        |        |
      .  *  +--+---+ imap}  |   *                        |        |
      .  ************************                        |        |
      .        |            |                            |        |
      . local} |            | {pop,                      |        |
      .        |  +------+  | {imap                      |        |
      .        +->|      |<-+                            |        |
      ...........>| rMUA +-------------------------------+        |
                  |      +----------------------------------------+
                  +------+

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 13:49:36 +0100

>        commands are extended to include UTF-8 characters.

s/on/of the/ (?)

Maybe s/include/allow/ and add "in the specified Mailbox address"
because we pulled it from the optional source routing part.

Why not simply "mailbox address" instead of mentioning "the real
SMTP" (tm) with its reverse-path:

| (8) The MAIL-FROM and RCPT TO commands are extended to allow
|     UTF-8 characters in a mailbox address.

Do we need a note somewhere that servers MAY (or SHOULD) reject
right hand sides not permitted for IDNA ?  Rejecting nonsense as
soon as possible makes sense.

Frank
-- 
"in any case, the SMTP adds its own identifier to the reverse-path"
[RFC 821, line 897]

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 14:45:29 +0100

>| Paramater BODY=7BIT implies that message is not UTF8SMTP because
>| mail data can not include 8-bit characters. On that case parsing
>| of all message header fields (including header fields from MIME
>| body parts) is not required.

Is that a correct interpretation of RFC 1652 ?  It says "content
body" (sic!), is that the complete message/rfc822 or only its body ?

There's a typo in 2.6:

| Assuming that the server advertises UTF8SMTP and 8BITMIME, and at
| least one non-ASCII address, with or without ALT-ADDRESS, the
| precise interpretation of these parameters on the MAIL command is:

The server advertises UTF8SMTP and 8BITMIME, but doesn't "advertise"
at least one non-ASCII address, the client might do this.  Proposal:

| Assuming that the server advertises UTF8SMTP and 8BITMIME, and
| the client sends at least one non-ASCII envelope address, with
| or without ALT-ADDRESS, the precise interpretation of the BODY
| parameters on the MAIL command is:
.............of (?)

I think "these parameters" actually means the BODY= values "7BIT",
"8BITMIME", and "BINARY".  That should be noted in the following
enumeration:

-  1.  Headers are in UTF-8, body parts are in ASCII.
+  1.  "7BIT", header may contain UTF-8, body parts are in ASCII.
-  2.  Headers are in UTF-8, some or all body parts contain 8-bit
-      line-oriented data.
+  2.  "8BITMIME", header may contain UTF-8, some or all body parts
+      contain 8-bit line-oriented data (not limited to UTF-8).
-  3.  Headers are in UTF-8, some or all body parts contain binary
-      data without restriction as to line lengths or delimiters.
+  3.  "BINARYMIME", header may contain UTF-8, some or all body
+      parts contain binary data as specified in [elsewhere].

With that interpretation your proposed addition belongs to (1).
and I think it might be wrong:

The assumption was "at least one non-ASCII address".  Let's say
one non-ASCII RCPT TO.  With another pure 2821 RCPT TO, a pure
2821 MAIL FROM, and pure 7bit message/rfc822 DATA.

Then the pure ASCII receiver might take a 7BIT route in this
scenario (no downgrading or other tricks needed, if the header
really doesn't contain UTF-8 or any 8bit garbage).  

For the non-ASCII RCPT TO adding a for8-clause (somewhere I said
from-clause where it should be for8, sorry) or similar would be
interesting, will that be BODY=7BIT plus HDR=UTF8SMTP ?

Actually there's a case "0", no BODY parameter at all.  Or do we
somewhere say that clients wishing to use UTF8SMTP *_MUST_* also
use the RFC 1652 BODY parameter ?

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 15:52:52 +0200

>   UTF8SMTP support on EHLO reponse if MDA or MS does not support 

 ALTERNATIVE 2:   'HDR=UTF8SMTP parameter' addition to this new chapter:

  The final delivery MTA is recommended to reject RCPT -command, if
  given mailbox does not accept UTF8SMTP messages and HDR=UTF8SMTP 
  parameter was given on MAIL -command.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 16:04:29 +0200

Frank Ellermann <[email-masked]> writes

> body" (sic!), is that the complete message/rfc822 or only its body ?

Hmm. Maybe I made wrong interpretation. 

So because interpretation of BODY=7BIT is not clear, I cancel
this addition.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 16:09:05 +0200

>     BODY=7BIT implies mail data can not include 8-bit characters.

I cancel that addition. I quite likely made wrong interpretation
for  DATA=7BIT.

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 15:55:47 +0100

>      ALT-ADDRESS keyword and value
 
Is that length("ALT-ADDRESS=")+256=268 based on the path length limit
256 in 2821 ?  How about using 64+1+255=320 for local part 64, domain
255 + "@", resulting in 12+320=332 ?  [[ I lost that argument already
in USEFOR wrt the <msg-id-core> size... thinking... okay, we're not
interested in additional wild and wonderful ways how downgrading can
fail ]]  But IMO that magic number 268 deserves an explanation, it's
no random number.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 16:11:44 +0100

>   parameter was given on MAIL -command.

Add "downgrading impossible" to the enumeration ?  I'm not exactly sure
where you are, the I-D has no 2.7.7 yet.  If the addition is okay I get:

| If downgrading is no option, and a HDR=UTF8SMTP parameter was used
| for the MAIL-command, the final delivery MTA SHOULD reject any
| RCPT-command, where the given mailbox does not accept UTF8SMTP
| messages.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 16:49:07 +0100

Kari Hurtta wrote:

> I have interpreted MDA to be for example that thing what sendmail
> calls for delivery to local mailbox.

Possible, I know that sendmail uses the term "local mailer" for say
mailx.  Checking the index of a Bat book printed 1994:  MDA, same
as Mlocal.  Oops... :-)

> That think that "final delivery MTA" is synonym of Mail Delivery
> Agent (MDA) is new to me.

Maybe the reason why John eliminated all "MDA" acronyms in the
framework RFC.

> ( On http://en.wikipedia.org/wiki/Mail_Delivery_Agent there is
>   one usage. )

Going as far as "not necessarily an MTA".  I-D.hutzler-spamops
(authors include Dave and Eric) apparently also takes this view

I-D.crocker-email-arch has "(smtp, lmtp, or local)" to the hMDA.

> somewhat similar and consistent my usage on messagestore I-D

Yes, you've eliminated the hMDA vs. rMDA detail.  Okay, I'll try
to say "final delivery MTA" instead of "MDA" if it's important.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 16:55:19 +0100

> That [EAI-downgrading] is little strange. Is there missing some text?

I think it's just a reference to the downgrading I-D.  Maybe...
s/parameter. [EAI-downgrading]./parameter, see [EAI-downgrading]./
...is clearer.

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 18:27:38 +0200

Frank Ellermann <[email-masked]> writes:

> 256 in 2821 ?

Yes.   

>                How about using 64+1+255=320 for local part 64, domain
> 255 + "@", resulting in 12+320=332 ?

This also makes sense.

>                                       [[ I lost that argument already

Yes.
      
Hmm. Add ALT-ADDRESS paramater need to use same encoding as ORCPT,
that adds maximum length also. So 268 is not enough :-(

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 18:37:44 +0200

Following addition is needed:

  The syntax for "esmtp-value" in [RFC2822] do not allow "=", SP and
  control characters. Therefore ALT-ADDRESS paramater value uses same
  encoding than ORCPT paramater value on [RFC3461]. 

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 18:04:25 +0100

Kari Hurtta wrote:

> ALT-ADDRESS paramater need to use same encoding as ORCPT

+1 (good catch)

> that adds maximum length also. So 268 is not enough :-(

64 local part, minus two for the quotes, 268+62+62=392.
And at some point let's rename EAI to COW (can of worms).

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 20:23:50 +0200

|   mailbox        =  name-addr / addr-spec / utf8-addr-spec
|
|   angle-addr = [CFWS] "<" utf8-addr-spec SP <alt-address> SP ">" [CFWS]
|
|   utf8-addr-spec =  utf8-local-part "@" utf8-domain
|
|   utf8-local-part=  utf8-dot-atom / utf8-quoted-string / obs-local-part
|
|   utf8-domain    =  utf8-dot-atom / domain-literal / obs-domain
|
|   alt-address    =  [CFWS] "<" addr-spec ">" [CFWS]
|
|   Below list a few possible <mailbox> representation as example.
|
|
|      "DISPLAY_NAME" <ASCII@ASCII>
|         ; traditional mailbox format
|
|      "DISPLAY_NAME" <non-ASCII@non-ASCII>
|         ; UTF8SMTP but no ALT-ADDRESS parameter provided,
|         ; message will bounce if UTF8SMTP extension is not supported
|
|      "DISPLAY_NAME" <non-ASCII@non-ASCII <ASCII@ASCII>>
|         ; UTF8SMTP with ALT-ADDRESS parameter provided,
|         ; ALT-ADDRESS can be used if downgrade is necessary

Specification of "angle-addr" makes "alt-address" required. 
On  examples there is non-ASCII address without "alt-address".
I think that "alt-address" should be optional.

That makes it

      angle-addr = [CFWS] "<" utf8-addr-spec SP <alt-address> SP ">" [CFWS] /
                   [CFWS] "<" utf8-addr-spec ">" [CFWS]

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 20:47:38 +0200

|    These are taken from FRC 3629, but kept in this document for reasons
                          ^ RFC

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 24 Mar 2007 22:56:44 +0200

> And at some point let's rename EAI to COW (can of worms).

I think that 64  '=' -characters is valid local part:

   ================================================================

You can not count minus two for the quotes.

       396 ?

( this is going to be close to 400 ?)

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 22:23:50 +0100

> I think that 64  '=' -characters is valid local part:

Typing "rfc 2822", enter, ",atext =", enter:  Yes, "="
needs no quotes.

> ( this is going to be close to 400 ?)

400 is better, we're anyway over the 268 guaranteed to
work with the path limits.  The prose will be tricky:

| 25 characters are needed for HDR=UTF8SMTP ALT-ADDRESS=
| followed by an ASCII-address suited for the maximal
| path-length 256 guaranteed to work in [RFC 2821].
|
| The local part of this ASCII-address might contain
| characters like '=' which have to be encoded when
| used in an SMTP parameter value as <xtext> specified
| in [RFC 3461].  With a maximal local part length 64
| guaranteed to work in [RFC 2821] this yields a total
| length of 25 + 256 + 128 = 409.

Or 396 for the variant without HDR=UTF8SMTP.  Ugly, but
magic numbers without explanation are worse.

The <xtext> explanation shown above isn't good enough,
it doesn't explain why '+' also has to be encoded (in
addition to characters not allowed in 2821).

Frank

P.S., I just saw that RFC 1869 is a part of STD 10.
      No obvious difference from 2821 wrt parameters.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Mar 2007 23:16:20 +0100

>|   angle-addr = [CFWS] "<" utf8-addr-spec SP <alt-address> SP ">" [CFWS]

The second SP is IMO wrong.  Should we really do two complex I-Ds
at once ?  Who including the poor authors and Chairs is going to
read, let alone track, so much stuff ?

>|      "DISPLAY_NAME" <non-ASCII@non-ASCII <ASCII@ASCII>>

Good example without 2nd SP.

> I think that "alt-address" should be optional.

Yes.  And I think that we don't want to have comments _within_
an <angle-addr> smuggled in by this construct:

|   alt-address    =  [CFWS] "<" addr-spec ">" [CFWS]
......................??????...................??????

P1 - Proposed fix for these three issues:

|   angle-addr  = [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS]
[...]
|   alt-address = 1*WSP "<" addr-spec ">" *WSP

That's one mandatory WSP as delimiter, optionally more, but
no folding white space.  And optional WSP at the end.

Possible variants (I don't like them):
P2   alt-address = FWS "<" addr-spec ">" [FWS]
P3   alt-address = 1*SP "<" addr-spec ">"
P4   alt-address = SP "<" addr-spec ">"

P2 uses folding white space instead of white space.
P3 enforces SP instead of WSP (= no TAB), no space at the end
P4 is acceptable, a single mandatory SP as delimiter, but no
   other nonsense (= no folding, TAB, or optional white space)

Anybody using CFWS or LWSP in ABNF needs a license to kill. ;-)

Note that CFWS and FWS as specified in 2822 includes "obs-FWS",
see the DKIM RFC for a simple no-nonsense FWS without obs-FWS.

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 25 Mar 2007 08:42:56 +0300

> | RCPT-command, where the given mailbox does not accept UTF8SMTP

Yes. That is better.
 
> Frank

Chapter 2.7.7 is chapter what I suggested to add on my item #8.

Basically  that HDR=UTF8SMTP idea helps only on sitations where
downgrading is no option.   If downgrading is supported by final 
delivery MTA, and some of given mailboxes are configured to
accept only non-UTF8SMTP messages (or downgraded messages), final
delivery MTA can anyway note that downgrading is impossible for
given message only on final dot on DATA -command.

There is cases on draft-ietf-eai-downgrade-03.txt which are syntactically
valid messages, but downgrading for them is not possible:

|       2.  <Non-ASCII>
|           This email header downgrading fails because this header is
|           not downgradable.

So that is quite hard problem for the final delivery MTA.

Assuming that 
        1) message is syntaxtically valid, 
        2) it have two recipients which one accepts UTF8SMTP messages 
           and another do not accept UTF8SMTP, and 
        3) on message have not enough information for downgrading

Only way on where final delivery MTA can inform that
        1) One recipient success, and
        2) Another recipeint fails
is
        1) Accept message on final dot on DATA -command
        2) send Non-delivery-notification (NDN) for failed
           recipeint.

( Fixing that may require SMTP code for
  "message acceptable for some recipients, retry delivery
   separately".   

   Well, on gmane.ietf.smtp there seems to have discussed 
   better ways for this also.
)

So

   ---------------            +----------+           +----------+
  /               \           | "border" |           |  final   |
  |   Internet    | ---smtp-> |          | --smtp--> | delivery |
  \               /           |   MTA    |           |   MTA    |
   ---------------            +----------+           +----------+

is not needed for "backscatter",

   ---------------             +----------+
  /               \            |  final   |
  |   Internet    | ---smtp->  | delivery |
  \               /            |   MTA    |
   ---------------             +----------+

is enough. Assuming that on Internet there is senders which
fake MAIL FROM address :-)

/ Kari Hurtta

---

From: Bill McQuillan <[email-masked]>
Date: Sun, 25 Mar 2007 00:02:00 -0700

> |   alt-address = 1*WSP "<" addr-spec ">" *WSP

I do not see any parsing requirement for the space *before* the "<".

This smacks of an annoying "taste-based" requirement. What's really wrong with

  "DISPLAY_NAME" <non-ASCII@non-ASCII<ASCII@ASCII>>

-- 
Bill McQuillan <[email-masked]>

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 25 Mar 2007 08:47:45 +0200

>   "DISPLAY_NAME" <non-ASCII@non-ASCII<ASCII@ASCII>>

A 2822 parser might be more confused than with a mandatory SP.
I'm not sure about this "SP as safeguard" for "old" parsers.

For human users no delimiter is hard to read, and I think the
EAI goal is to make mail easier for users not familiar with
ASCII.  A plausible case would be a non-ASCII address in a
script not supported / known by this user, if that user then
also has serious difficulties with ASCII what he sees without
delimiter is gibberish.

Soobok Lee posted some really ugly examples in
<http://article.gmane.org/gmane.ietf.ima/1332/raw>

All combinations from
<abc&#xFE6B;address.tld&#xFE65;&#xFE50;&#xFE64;[email-masked]> to
<abc&#xFF20;address.tld&#xFF1E;&#xFF0C;&#xFF1C;[email-masked]> with
<http://purl.net/net/ucode/FE6B>, <http://purl.net/net/ucode/FF20>,
<http://purl.net/net/ucode/FE65>, <http://purl.net/net/ucode/FF1E>,
<http://purl.net/net/ucode/FE50>, <http://purl.net/net/ucode/FF0C>,
<http://purl.net/net/ucode/FE64>, <http://purl.net/net/ucode/FF1C>.

Maybe a mandatory delimiter is remotely related to security (?)

Frank

---

From: "Yao Jiankang" <[email-masked]>
Date: Sun, 25 Mar 2007 22:28:46 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 1:53 PM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#1): 2.6. Body Parts and 
SMTPExtensions

>    that message is UTF8SMTP message.

ALTERNATIVE 1: will be used since our WG has removed 'HDR=UTF8SMTP 
parameter' .

> ________________________________________P with SMTP AUTH                 [RFCxxxx]
 SMTPS           SMTP with STARTTLS                  [RFCxxxx]
 SMTPSA        SMTP with both STARTTLS and         [RFCxxxx]
                        SMTP AUTH
"
so in the future, we may also need upaded RFC for below
"UTF8SMTPA            UTF8SMTP with SMTP AUTH                 [RFCxxxx]
   UTF8SMTPS            UTF8SMTP with STARTTLS                  [RFCxxxx]
   UTF8SMTPSA           UTF8SMTP with both STARTTLS and         [RFCxxxx]
                        SMTP AUTH
"
Currently, the UTF8SMTPA  UTF8SMTPS UTF8SMTPSA RFC are not available.

Thanks a lot
YAO Jiankang

>
> -- 
> 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
>

---

From: "Yao Jiankang" <[email-masked]>
Date: Sun, 25 Mar 2007 22:28:46 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 1:53 PM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#1): 2.6. Body Parts and 
SMTPExtensions

_______

---

From: "Yao Jiankang" <[email-masked]>
Date: Sun, 25 Mar 2007 22:44:40 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 9:52 PM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#8.1): Addition: 2.7.7. 
finaldelivery MTA

>>   UTF8SMTP support on EHLO reponse if MDA or MS does not support

will consider to add.

>  parameter was given on MAIL -command.

'HDR=UTF8SMTP parameter' has been removed by this WG.

---

From: Kari Hurtta <[email-masked]>
Date: 25 Mar 2007 18:08:48 +0300

"Yao Jiankang" <[email-masked]> writes in gmane.ietf.ima:

> Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#1): 2.6. Body Parts
> and SMTPExtensions
> 
> 
> >

I have not seen call on list.

http://www3.ietf.org/proceedings/07mar/slides/eai-0.pdf

says "Disposition of HDR=UTF8SMTP idea"

Was it this ?

I looked "Disposition" from my ISP's English to Finnish dictionary.
( it gives "alttius", järjestely", "jäsennys", "jäsentely",
  "katsantokanta", "luonne", "luonteenlaatu", "luontumus" and so on )

Look like it is something like "handling" -- nothing of these translations
what looks like "removal" or "rejection".

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 25 Mar 2007 19:08:07 +0300

Suggestion:  
   I suggest new reply code to SMTP "Some recipients failed UTF8SMTP
     downgrade, retry message with one recipient"

   I think that that is some 4XX  code (perhaps Klensin may give
   suggestion?)

   Charles Lindsey suggested new reply code for "message rejected
   because next hop does not support UTF8SMTP"

   I call this 5XX code.

   These 4XX  and 5XX needed replaced with actual numbers.
   Is there registry?

   (Hmm. Also new extended status codes are required. )

Question:
   Is something required for enabling this new reply code ?
   HDR=UTF8SMTP was dropped. Can this be enable just implicity
   because SMTP client seemed send UTF8SMTP message ?

Rationale:  (from message <[email-masked]>
             subject "Re: draft-ietf-eai-smtpext-04.txt: (#8.1): 
                      Addition: 2.7.7.final delivery MTA" )

|       2.  <Non-ASCII>

    Assuming that 

    So

Chapter "2.1.  Framework for the Internationalization Extension" 
addition:

   (8) New  SMTP reply codes 4XX, 5XX are defined by this 
       extension.

New chapter "2.X New SMTP reply codes"

  Two new SMTP reply codes are defined. By sending UTF8SMTP 
  message SMTP client indicates that it understand these new 
  codes.

  These new reply codes are used on response of final dot
  on DATA -command.

  SMTP Reply-code 4XX indicates that for some (but not all 
  recipients) is UTF8SMTP downgrading required, but that 
  failed. SMTP clinet is asked to retry message with every
  recipient as own smtp transaction.

  SMTP Reply-code 5XX indicates that UTF8SMTP downgrading
  was required for all recipients but downgrading failed.
  
Chapter "2.7.7. final delivery MTA" addition (I suggested that 
chapter on my item #8):

   The final delivery MTA may reply with SMTP rcode 4xx 
   on response of final dot on DATA command if message are several 
   recipients, message is UTF8SMTP message, some (but not all 
   recipients) do not accept UTF8SMTP messages and downgrading
   of message fails.

   The final delivery MTA may reply  with SMTP code 5XX
   on response of final dot on DATA command if 
   message is UTF8SMTP message, all recipients do not accept
   UTF8SMTP message and downgrading of message fails.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 25 Mar 2007 19:56:37 +0300

Addition: 

  If the UTF8SMTP SMTP extension is not offered by the server, 
  client MUST NOT transmit messages which includes MIME parts 
  with new MIME subtypes of "message" defined on [EAI-dsn] 
  (or on other UTF8SMTP related RFC) if  these parts include 
  (unencoded) 8-bit data.

Rationale:

  Effectively it is required that 8BITMIME downgraders 
  reject message/* subtypes (except message/rfc822) 
  which includes 8-bit data.    

  Because on this context UTF8SMTP was not offered,
  this indicates that possible 8BITMIME downgrader
  knows nothing about UTF8SMTP. Therefore it dows not
  know these message/* subtypes defined on [EAI-dsn].
  And it can not do anything smart for them. Only 
  option is reject (or drop message if mail from is
  <>)  when message/* subtype includes 8-bit data.
  MIME forbids quote-printabe and base64 encoding of 
  them.
  
  (I have discussed about this already several times.) 

/ Kari Hurtta

---

From: "Yao Jiankang" <[email-masked]>
Date: Mon, 26 Mar 2007 09:20:31 +0800

your understanding of "Disposition" may be correct.
but in the Prague IETF EAI meeting, majority did not like the "Disposition of HDR=UTF8SMTP idea".
it is not that the "Disposition" can be understood as "remove".
but the "Disposition of HDR=UTF8SMTP idea" is rejected by last IETF EAI meeting.

YAO Jiankang
CNNIC

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 02:42:24 +0200

> 'HDR=UTF8SMTP parameter' has been removed by this WG.

I think you confuse that with the header field _within_
a message/utf-8 saying "I am a message/utf-8 (or not,
or downgraded, or upgraded)".

Otherwise I'd like to see a pointer where that precisely
was decided, by whom, on what base, etc.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 02:54:25 +0200

Yao Jiankang wrote:

> the "Disposition of HDR=UTF8SMTP idea" is rejected by last IETF EAI meeting

No problem, I dispute that "rejected disposition" or whatever it was.
I also ask Harald and XiaDong to stop such EAI backchamber decisions,
not even visible in jabber for folks online at the meeting.

Frank

---

From: Yangwoo Ko <[email-masked]>
Date: Mon, 26 Mar 2007 11:49:04 +0900

> was decided, by whom, on what base, etc.

There was a short discussion on this in the last IETF meeting, and it is 
found that there is a "significantly" rough consensus on not having this 
parameter. Since it is very rough, we need more discussion on this. 
However, Yao, as author, doesn't seem to want taking the risk of relying 
on that parameter that is on the risk of possible removal. :-)

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 03:34:30 +0200

>   (or on other UTF8SMTP related RFC) if  these parts include

That's bogus, nothing is wrong with transporting 8bit
MIME Content-Types in the body over 8BITMIME.

> know these message/* subtypes defined on [EAI-dsn].

So what ?  The sender obviously knows what UTF8SMTP
is, after all he sent it.  If he gets a "downgraded"
(8BITMIME) DSN he'll manage.  And if that beast is
forced to take a 7bit route they'd "encapsulate" it
as application/message or similar.  They could also
admit that 7bit relays are somewhat unpopular in
this millennium.

> I have discussed about this already several times

Failing to convince me, yes.  I propose to use the
term message/utf8 whereever you want long and IMO
factually wrong discussions of parsing MIME, with
message/utf8 we have a single point to define how
it works:

- by looking at the header (my proposal)
- by looking at the headers (incl. some MIME parts,
  not yet clearly specified wrt message/* subtypes)
- by looking at the header and MIME version

If we use message/utf8 consistently there's only
one point explaining how it's identified.  Doing
that again and again in each I-D or section of an
I-D strikes me as Bad Thing.

Frank

---

From: "abel" <[email-masked]>
Date: Mon, 26 Mar 2007 11:18:05 +0800

> > Is that length("ALT-ADDRESS=")+256=268 based on the path length limit
.
> that adds maximum length also. So 268 is not enough :-(
+1 on "...use same encoding as ORCPT..."

if max lengths in ORCPT local-part use % (percent-encode),  a utf8 char
equals
3-6 bytes , 1 byte converts to  percent-encode will become 3 bytes, base on
this rule,the Local-Part can not over 7 UTF8 characters ( 7 x 3 x 3 = 63 ),
propriety in the worst case, local-part can't be more than 3 UTF8 characters
( 4 x 6 x 3 =72 > 64)  , unless the mail admin knows this issue.

\uUnicode ? I am not sure what the 'Unicode' means, UCS-2 ? UCS-4 ? or just
UTF8?
it means U+XXYY or #&XXYY or otherwire.

---

From: "abel" <[email-masked]>
Date: Mon, 26 Mar 2007 11:28:56 +0800

thanks for Kari,
Your point is clear !
I will make some changes in next versoion.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 04:30:35 +0200

>    I think that that is some 4XX code

| replies are 4yz if they can be successful if repeated without any
| change in command form or in properties of the sender or receiver
| (that is, the command is repeated identically and the receiver
|  does not put up a new implementation.)

Interesting question, I bet on 5xx.

>    These 4XX  and 5XX needed replaced with actual numbers.

I-D 2821bis chapter 4.2 (?)

> Assuming that on Internet there is senders which fake
> MAIL FROM address :-)

Unlikely, they'd get an SPF FAIL :-)  Multiple receivers
with different properties (UTF8SMTP aware or not) without
the HDR=UTF8SMTP parameter are a royal PITA.

Maybe we should adopt I-D.hall-deferrals (*) for EAI, it has
precisely what we need, selective reject after DATA.

>   was required for all recipients but downgrading failed.

Yeah, selective reject without selective reject is tricky.
How about using the "too many recipients" code as long as
there is a "mixed" scenario ?

Frank

*: <http://tools.ietf.org/html/draft-hall-deferrals-00>

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 04:53:09 +0200

Yangwoo Ko wrote:

> There was a short discussion on this in the last IETF meeting

Next time I'm interested in a meeting I try to find a PC with audio :-)

> there is a "significantly" rough consensus on not having this

Okay, that sounds better than "decided and ready", I only understood
what HDR=UTF8SMTP is good for _after_ the meeting (yesterday) when
Kari proposed the alternatives:

It avoids backscatter without employing "selective reject" tricks
only existing as 00 I-D, or worse emulations of "selective reject".

> Yao, as author, doesn't seem to want taking the risk of relying

Understandable.  We could demand that UTF8SMTP "MUST NOT" use more
than one RCPT TO, but I fear that won't pass giggle tests:  It's
an unnecessary restriction after an SPF PASS.

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 26 Mar 2007 07:28:33 +0300

> admit that 7bit relays are somewhat unpopular in

message/utf8 (or what it is) media types can occur
on also some other messages than on DSN.

On DSN this situation is likely NOT to occur because
"The sender obviously knows what UTF8SMTP is, after all 
 he sent it"   -- therefore smtp server is offering 
 UTF8SMTP SMTP extension.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 26 Mar 2007 07:54:24 +0300

Yangwoo Ko <[email-masked]> writes in gmane.ietf.ima:

> There was a short discussion on this in the last IETF meeting, and it
> is found that there is a "significantly" rough consensus on not having
> this parameter. Since it is very rough, we need more discussion on
> this. However, Yao, as author, doesn't seem to want taking the risk of
> relying on that parameter that is on the risk of possible removal. :-)

I'm still suggesting HDR=UTF8SMTP.   

It have merits on SMTP (and it is yet more needed for LMTP --
there is some discussion on draft-hurtta-eai-messagestore-00)

There is not definately consensus on this mailing list for
removal of HDR=UTF8SMTP parameter :-)

Basically HDR=UTF8SMTP makes possible to reject RCPT TO command
if SMTP server is not willing to do downgrade and it knowns that
mailbox do not accept UTF8SMTP messages.

There is still even with HDR=UTF8SMTP needed new SMTP reply codes.
DATA content may be valid, but not UTF8SMTP-downgradeable, so
reply code for '1 recipient only' is needed (or we make dependency to 
draft-hall-deferrals-00 (if that draft flys) ).

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 06:03:53 +0200

> on also some other messages than on DSN.

Yes, there are quite a lot message/* subtypes, starting
with message/news (chronologically the oldest, I think):

http://www.iana.org/assignments/media-types/message/

Your idea to "aggregate" the future UTF8SMTP related
subtypes, expecting that UTF8SMTP gateways know all
UTF8SMTP subtypes not limited to message/utf-8, also
the subtypes needed for DSNs, and whatever else might
be added, is just odd.  Or I don't understand it.

message/disposition-notification-utf-8 ???
message/partial-utf-8 ???
message/sipfraq-utf-8 ??? (or is that already UTF-8 ?)
message/tracking-status-utf-8 ???
...

The poor gateway MUST NOT be forced to parse such sub-
types for it's decision if a message is message/utf-8
or not.  There's a top-level CTE, and we know that
it's not allowed to have 8bit parts within 7bit, or
binary parts within 8bit.  That ought to be enough.

>  he sent it"   -- therefore smtp server is offering

Yes.  Using a 7bit mailout in parallel with an UTF8SMTP
final delivery MTA, forced to use this mailout for its
bounces, appears to be unwise...

...we need application/message to encapsulate any weird
message subtype over 7bit hops.  It might be a perfect
8bit message/news, who knows ?  Harald and Charles did
not let me finish it off when we had this chance... :-)

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 26 Mar 2007 08:46:48 +0300

> binary parts within 8bit.  That ought to be enough.

Poor gateway is forced to check  Content-* header fields
on mime subparts.

Most of these message/* media types on 
    http://www.iana.org/assignments/media-types/message/
are not applicable for SMTP mail.

And these media types (except perhaps message/news)
which are applicable for SMTP mail are 7-bit.

I have said several times that these new message/utf-8
types must NOT leak outside of UTF8SMTP universe.

What to do with them must be defined on downgrade draft
(must likely message/utf-8 is converted to message/rfc822
 and Content-Type: header field is modified correspondingly).

Because draft-ietf-eai-smtpext comes before
draft-ietf-eai-dsn these media types can not enumerated
on draft-ietf-eai-smtpext.

Poor gateway is required to know media types which are
on these eai workgroup drafts. 

> not let me finish it off when we had this chance... :-)

Yes, application/message is good idea :-)

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 26 Mar 2007 09:03:06 +0300

> I-D strikes me as Bad Thing.

I have used term "UTF8SMTP message", but on where 
that can be defined?  

Perhaps on "draft-ietf-eai-utf8headers" ?

That is difficult if  draft-ietf-eai-utf8headers
comes before draft-ietf-eai-dsn.   

Perhaps I can try suggest chapter to 
draft-ietf-eai-utf8headers.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 26 Mar 2007 11:10:02 +0300 (EEST)

>>> abel

> it means U+XXYY or #&XXYY or otherwire.

Hmm. Can  maximum length of ORCPT redefined ?

UTF8SMTP can (and must define) addition to command line 
length MAIL FROM and RCPT TO commands. That can take
account also longer ORCPT.

But then there is problem when message is downgraded.
Command line length may be longer than what DSN extension
gives.

So can ORCPT transfer UTF-8 original address at all ?

If not it must be dropped when message leaves UTF8SMTP
environment.

( Who was talking about can of worms? :-) )

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 26 Mar 2007 11:11:43 +0300 (EEST)

> I will make some changes in next versoion.

There was also some problems with SP  (which I did not noticed).

/ Kari Hurtta

---

From: "abel" <[email-masked]>
Date: Mon, 26 Mar 2007 16:44:36 +0800

> > >                    [CFWS] "<" utf8-addr-spec ">" [CFWS]
Yes, I saw this issue,
I think it' is better without SP:
angle-addr = [CFWS] "<" utf8-addr-spec<alt-address>">" [CFWS] /
                    [CFWS] "<" utf8-addr-spec ">" [CFWS]

because of MTAs  tokekize and parse issue.
SP or SPs will make different when header values change, such as
downgrading,
<UTF8@IDN SP <ALT-ADDRESS>SP> , that should delete UTF8@IDN or
get ALT-ADDRESS. it is possible make some confuse with SP(s),
and other comments are welcome.

---

From: Chris Newman <[email-masked]>
Date: Mon, 26 Mar 2007 09:42:50 +0000

The implementation limits for DSN (including ORCPT) are in RFC 3461 section 
5.4.  I believe the limits suffice.

As the ORCPT parameter is a trace parameter rather than a deliverable address, 
it is not subject to the local-part and domain limits in SMTP.

The UTF8SMTP specification needs to be clear about the impact on line length 
limits.  Do limits remain "characters" in which case a UTF8SMTP server has to 
have a line length octet limit of roughly four times the current ASCII octet 
limits?

                - Chris

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Mar 2007 12:12:07 +0200

>  and Content-Type: header field is modified correspondingly).
This was discussed in Prague in the context of the DSN draft.

The overwhelming conclusion was that the message/utf8smtp was a better 
thing to do for this experiment than application/utf8smtp. Also for the 
case when these attachments are sent over the ordinary SMTP 
infrastructure - WITH transfer encodings.

There is no guarantee in the MIME standard that message/* types won't 
have transfer encodings on them. And if the bad practice of depending on 
the absence of transfer encodings on message/* types is widespread (or 
the practice of descending message/* types you don't know anything 
about) is widespread, that is a good thing for the experiment to get 
information about.

And yes, Eric Allman was in the room while this was being discussed. 
Just in case you wonder what the sendmail people will think when they 
hear this.

Harald

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 26 Mar 2007 15:51:57 +0300 (EEST)

>>> Harald Alvestrand

Text what I suggested my item #15 did not forbid sending 
message/* WITH encoding over the ordinary SMTP:

| Addition: 
|
|  If the UTF8SMTP SMTP extension is not offered by the server, 
|  client MUST NOT transmit messages which includes MIME parts 
|  with new MIME subtypes of "message" defined on [EAI-dsn] 
|  (or on other UTF8SMTP related RFC) if  these parts include 
|  (unencoded) 8-bit data.

This just forbid sending 8-bit data on message/* without
transfer encoding.

What was type names decided ?

Is it message/utf8smtp  (and not message/utf-8) ?

What was other media type names ?
 
> Just in case you wonder what the sendmail people will think when they 

Unknown message/* WITH encodings do not cause any problem to sendmail.
Only unknown message/* with 8-bit data causes (ie. non-encoding case).

And if type is already encoded to 7-bit I guess that 8BITMIME downgraders
do not have problems.  

Encodings on multipart types are generally ignored, I do not know
about message types.

I can guess that encoding for message/rfc822 is ignored.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: Mon, 26 Mar 2007 16:17:31 +0300 (EEST)

>>> Kari Hurtta

However, I can guess that many reads RFC 2045 text as guarantee 
for non-encoding:

|   Certain Content-Transfer-Encoding values may only be used on certain
|   media types.  In particular, it is EXPRESSLY FORBIDDEN to use any
|   encodings other than "7bit", "8bit", or "binary" with any composite
|   media type, i.e. one that recursively includes other Content-Type
|   fields.  Currently the only composite media types are "multipart" and
|   "message".  All encodings that are desired for bodies of type
|   multipart or message must be done at the innermost level, by encoding
|   the actual body that needs to be encoded.

Even when this is no guarantee in the MIME standard that message/* 
types won't have transfer encodings on them.  

It is quite difficult read "EXPRESSLY FORBIDDEN" otherway :-)

/ Kari Hurtta

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 Mar 2007 14:52:37 +0100

> infrastructure - WITH transfer encodings.

Which just goes to illustrate that you cannot decide complex technical  
issues in a 2-hour meeting of which a mere 5 minutes might be devoted to  
each topic.
> have transfer encodings on them.

Yes there is, at least so far as using Q-P or Base64 is concerned. From  
RFC 2045:

    Certain Content-Transfer-Encoding values may only be used on certain
    media types.  In particular, it is EXPRESSLY FORBIDDEN to use any
    encodings other than "7bit", "8bit", or "binary" with any composite
    media type, i.e. one that recursively includes other Content-Type
    fields.  Currently the only composite media types are "multipart" and
    "message".  All encodings that are desired for bodies of type
    multipart or message must be done at the innermost level, by encoding
    the actual body that needs to be encoded.

which means that you cannot use message/utf8smtp as an opaque  
encapsulation mechanism which can be C-T-Ed straight down to 7bit.

We have already been through this once, and Crhis Newman agreed, On Feb  
16th:

    "Ok, I've been convinced application/utf-8-message is a safer label for
     the type."

> And if the bad practice of depending on the absence of transfer  
> encodings on message/* types is widespread (or the practice of  
> descending message/* types you don't know anything about) is widespread,  
> that is a good thing for the experiment to get information about.

I don't think that an experiment with such a gross breach of RFC 2045 can  
be described as a "good thing".

-- 
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

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 16:55:33 +0200

Chris Newman wrote:
 
> The implementation limits for DSN (including ORCPT) are in RFC 3461
> section 5.4.  I believe the limits suffice.

500 "characters", taking that as octects and the worst case factor 4
that's only 125 Unicode points in plane 1 ff.  That's not much. (?)
Ditto 3*167.

Related:

For a domain xn--anything.xn--anything.xn--anything.xn--anything.us
I get 4 * length( "xn--." ) + length( "us" ) = 22.  To simplify it
I take four identical labels xn--anything with length 61, what's
the worst UTF-8 octet length for an xn--anything with length 61 ?

Beats me, I never did anything with punycode... :-(  Whatever this
worst case is, we can get it as domain part of an I18N address in
stringprep form.  Roughly, I ignored "x@" for a minimal local part.

Frank

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 17:33:41 +0200

> I have used term "UTF8SMTP message", but on where

message/utf-8 is defined in dsn-00 at the moment...

> Perhaps on "draft-ietf-eai-utf8headers" ?

...yes, that's a good place to explain how a "top-
level" message/utf-8 can be identified.  "Embedded"
message/utf-8 (or similar DSN subtypes) parts have
Content-Type header fields in the MIME part header,
with CTE 8bits.

> comes before draft-ietf-eai-dsn.

The DSN draft registers message/utf-8, both I-Ds
would reference each other normatively.

> draft-ietf-eai-utf8headers.

Good.  BTW, I had a rather odd idea wrt the MIME
version question.  In theory I think we need a
new version 2.0 if the MIME part headers use UTF-8
or are permitted to use UTF-8 (it makes no sense
to look if they actually do this).

But if we restrict UTF-8 in MIME part headers to
message/utf-8 (+ maybe a few other subtyps), then
we could say that this implicitly permits UTF-8 in
the MIME part headers of all parts contained in
the (nested) multipart/* within a message/utf-8.

But for a message/foo (notably message/rfc822) as
body or part of a message/utf-8 this permission
ends, i.e. the embedded message/rfc822 MUST NOT
use UTF-8 in its own parts.  Does that make sense ?

Maybe these MIME and message/utf-8 considerations
deserve their own draft if the WG insists on doing
"UTF-8 in MIME part headers" now.  IMO adding this
feature later (after the EAI experiment) is better,
MIME 1.0 parsers confused by UTF-8 shouldn't count
as EAI failure.

Frank

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 26 Mar 2007 16:41:15 +0100

> removal of HDR=UTF8SMTP parameter :-)

You cannot "remove" something that was never there in the first place.

HDR=UTF8SMTP is just the Header-Type header by the back door, and all the  
arguments against that header apply equally here - principally that its  
absence is not sufficient proof that there is not a utf-header somewhere  
inside there. It was made clear to me that the only way to detect a UTF-8  
message was to scan all the way through it (recursively descending through  
the MIME structure). I do not think that was a good argument, but it was  
the argument that prevailed and we are now stuck with it.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 18:02:24 +0200

> are not applicable for SMTP mail.

I can't judge it, I only know message/news.  There are
two SIP subtypes, and I know that an MMS to mail gateway
RFC exists, but I've no clue if that's related.

> which are applicable for SMTP mail are 7-bit.

In theory message/news has an ASCII header like an
ordinary message/rfc822, but of course both can have
8bit bodies.  In practice there can be non-ASCII in
the header of message/news (and message/rfc822), but
we don't know what it is (UTF-8, Latin-x, windows-y,
etc.)
 
> types must NOT leak outside of UTF8SMTP universe.

That's an odd demand.  It's IMO legal to forward a
message/utf-8 as part of an (8bit) message/rfc822,
or where is it possible to forbid this ?  

> Poor gateway is required to know media types which
> are on these eai workgroup drafts.

Gateway software checking the MIME type registry, is
that normal, or would it be a new concept ?

> Yes, application/message is good idea :-)

Does it need an extra I-D, or where can we add it ?
So far the MIME type registration stuff is all in
dsn-00,that could be a good place, the concept is
rather simple.

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 26 Mar 2007 19:45:25 +0300

"Charles Lindsey" <[email-masked]> writes in gmane.ietf.ima:

> HDR=UTF8SMTP is just the Header-Type header by the back door, and all
> the  arguments against that header apply equally here - principally

Not actually.  HDR=UTF8SMTP occurs on MAIL FROM -command.
That is before RCPT TO commands. Header-Type header field
occurs on DATA command. That is after RCPT TO commands.

That is the big difference.  

So it is not true that there is same arguments.

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 26 Mar 2007 19:51:11 +0300

> that normal, or would it be a new concept ?

Do not twist my words. There is limited number of
documents listed on eai charter 
( http://www.ietf.org/html.charters/eai-charter.html ).
 
> dsn-00,that could be a good place, the concept is

IMHO it belongs to downgrade document.

/ Kari Hurtta

---

From: Bill McQuillan <[email-masked]>
Date: Mon, 26 Mar 2007 10:27:43 -0700

> That is the big difference.  

And the consequence of this difference is that the receiving MTA can treat
the discovery of 8-bit/utf-8 data within the subsequently received headers
as merely data errors if HDR=UTF8SMTP had not previously been negotiated in
the MAIL FROM command.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 26 Mar 2007 19:37:18 +0200

> It is quite difficult read "EXPRESSLY FORBIDDEN" otherway :-)
2045 seems to have been forgotten even by its writers...
the text quoted in Prague was from 2046 section 5.2:

Subtypes of "message" often impose restrictions on what encodings are
allowed. These restrictions are described in conjunction with each
specific subtype.

And the oh-so-precise words from section 5.2.4:

Future subtypes of "message" intended for use with email should be
restricted to "7bit" encoding. A type other than "message" should be
used if restriction to "7bit" is not possible.

Note the clear definition of "email" and the use of "should".
I personally think that this wasn't the best text we created.....

Harald

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 20:32:41 +0200

Charles Lindsey wrote:

> HDR=UTF8SMTP is just the Header-Type header by the back door

No, they are significantly different, like SPF and SenderID:

HDR=UTF8SMTP is for SMTP, it allows to reject messages a.s.a.p.
per RCPT TO.  HDR=UTF8SMTP is on the same level as BODY=8BITMIME.

The dead Header-Type header field talked about the header it's
a part of, you needed to look into header (after DATA wrt SMTP)
to find it, and when you look into the header anyway you can as
well figure out if it uses UTF-8, only ASCII, or something else.

HDR=UTF8SMTP is a MAIL parameter, it comes before RCPT TO + DATA.

It's remotely a similar idea as "SUBMIT" (RFC 4407), but unlike
SenderID we can require that it's supported by any conforming
UTF8SMTP MTA (receivers are free to ignore it when they have no
use for it, but senders SHOULD set it).

Selective reject emulations aren't attractive, and heuristics
based on UTF-8 in the forward or reverse paths are unreliable:
There can be cases with UTF-8 in the envelope, but not in the
header, and vice versa.

> its absence is not sufficient proof that there is not a
> utf-header somewhere inside there.

Per RCPT TO rejections are based on its presence.  When it's
absent although it should be there it's an error after DATA.

> It was made clear to me that the only way to detect a UTF-8
> message was to scan all the way through it (recursively
> descending through the MIME structure).

Scanning MIME part headers in the nested multipart structure
is only necessary if they can legitimately contain UTF-8, and
the MIME version number isn't updated to avoid this trouble.

Scanning embedded messages of any subtype for UTF-8 is AFAIK
never needed, the only question at this point is 8bit or 7bit
or binary (and that check should match the BODY= parameter,
not the HDR= parameter).

> I do not think that was a good argument

Nor me...

> the argument that prevailed and we are now stuck with it.

...why should we ?  There are some less desirable HTML <head>
constructs, where saying that they're redundant doesn't imply
that similar HTTP header fields are also unnecessary.

Frank

---

From: Kari Hurtta <[email-masked]>
Date: 26 Mar 2007 21:43:51 +0300

> HDR=UTF8SMTP is a MAIL parameter, it comes before RCPT TO + DATA.

Following is my older message which questioned from different angle:
------------------------------------------------------------------
From: Kari Hurtta <[email-masked]>
Subject: ESMTP -- is bounce only (no downgrade) allowed
Newsgroups: gmane.ietf.ima
To: [email-masked]
Date: 11 Feb 2007 08:43:13 +0200

On 8BITMIME there is on operation mode where
        - SMTP server announces 8BITMIME
        - never parses or downgrades MIME structure

        Instead mail is always bounces if next hop
        does not support 8BITMIME

This is possible because on ESMTP there is parameter
BODY=8BITMIME

Is following wanted on UTF8SMTP
        - SMTP server announces UTF8SMTP
        - never parses or downgrades MIME structure
        - never downgrades mail header fields

        Instead mail is always bounces if next hop
        does not support UTF8SMTP

This requires that SMTP server knows that mail
is using  UTF8SMTP.  So if that opartion mode
is make posible, that requires that on ESMTP
there is parameter HDR=UTF8

Basically that is: Do we allow SMTP servers
which do not parse MIME structure ?

( SMTP servers which does downgrade do not need
  either HDR=UTF8 or BODY=8BITMIME.  They can
  just start downgrading if next hop does not
  support 8BITMIME or UTF8SMTP.  If there is 
  no anything that requires downgrading, output
  is original mail. That downgrade process is 
  also that pass when mail is parsed. No other
  parsing is required, if that output is stored
  to memory and after full succesfully downgrade 
  then is DATA commend given to next hop. )

/ Kari Hurtta

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 26 Mar 2007 21:31:11 +0200

> documents listed on eai charter

We're arguing in circles.  So you think of a proper
subset of message/* with similar properties.  And I
don't see why that set shouldn't be extended later.

Where it would break with applications knowing only
an older (= smaller) set of these message subtypes.

A new message8/* hierarchy could avoid this trouble,
but without looking I fear that's not possible in an
experiment.

For XML there are various application/xml+foobar, the
set here could identify itself as message/utf8+foobar.
Applications could then know that message/utf8+* is
for them.

Frank

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Mar 2007 16:24:11 +0800

ok, will update it.

YAO Jiankang
CNNIC

---

From: Martin Duerst <[email-masked]>
Date: Tue, 27 Mar 2007 17:44:14 +0900

Hello Chris,

At 18:42 07/03/26, Chris Newman wrote:
>The UTF8SMTP specification needs to be clear about the impact on line length limits.  Do limits remain "characters" in which case a UTF8SMTP server has to have a line length octet limit of roughly four times the current ASCII octet limits?

I'm not sure exactly how you got to this 'roughly four times', but if
this is simply the expansion from ASCII to UTF-8, then in particular
the word 'roughly' may be a bit misleading.

Given that there is now wide consensus between ISO 10646 and Unicode
that the 'working' code space is limited to 17 planes, with the
highest theoretical codepoint being U+10FFFF, an expansion factor
of 4 is the *maximum* factor necessary. But this factor is only
necessary under the following conditions:
- All characters that would be ASCII are 'internationalized',
  which means that there are no syntax characters (such as e.g. '@').
  This is obviously field-dependent, but it would definitely not
  apply to usual email headers, where the header field name at least
  is pure ASCII.
- All such characters are taken from scripts that are allocated to
  a 'higher plane'. This is highly unlikely, although not completely
  impossible. The planes outside the BMP (Base Multilingual Plane)
  are mainly used for scripts that are no longer in use or not
  in major daily use, and for very characters (e.g. Han Ideographs).
- All these characters have an information density similarly low
  as US-ASCII. Scripts with a large number of characters usually
  have a higher information density, but again, there are some
  very small scripts beyond the BMP, too. 

Satisfying the above conditions isn't easy, the scripts in Unicode
5.0 that come closest in my mind are Gothic, Deseret, and Shavian.

What I want to say here is *not* that we should use multipliers lower
than 4 for length limits. Even if I consider it extremely rare that
anybody would use any of the abovementioned scripts, I think we
should not try to restrict things based on our estimates of script
usage.

But I want to stress that a multiplier of 4 is extremely well-designed
and generous, definitely on the safe side.

All this is of course modulo the slack that we have (or not) in the
current length limits. If there is a field that we already now wish
would be longer in many cases, we should use the occasion of moving
to UTF-8 to extend it by more than a factor 4. If there is a field
that we already know was designed way to generously, we may use
an expansion factor lower than 4.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Mar 2007 19:12:40 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 2:51 PM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#5): 2.1. Framework for theInternationalization Extension

>       commands are extended to include UTF-8 >characters.

yes, good
YAO Jiankang

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Mar 2007 19:21:08 +0800

will consider to update it.

Yao Jiankang
CNNIC

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Mar 2007 19:17:42 +0800

----- Original Message ----- 
From: "Frank Ellermann" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 8:49 PM
Subject: [EAI] Re: draft-ietf-eai-smtpext-04.txt: (#5): 2.1. Framework for the Internationalization Extension

>>        commands are extended to include UTF-8 characters.

I think that "on" is ok. any other view from native englisher?

> because we pulled it from the optional source routing part.

yes, that is good.

> soon as possible makes sense.

in section 2.2, there are already such a sentence.

"Any domain names that are to be looked up in the DNS MUST first be
   processed into the form as specified in IDNA [RFC3490] by means of
   the ToASCII() operation unless they are already in that form.  Any
   domain names that are to be compared to local strings SHOULD be
   checked for validity and then MUST be compared as specified in
   section 3.4 of IDNA.
"

YAO Jiankang 
CNNIC

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Mar 2007 19:24:05 +0800

ok, good.
thanks.
Yao Jiankang
CNNIC

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Mar 2007 19:45:08 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, March 24, 2007 7:09 PM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#12): 2.2. The AddressInternationalization Service Extension

> That [EAI-downgrading] is little strange. Is there missing some text?

may change it to

"If it is replaced, the replacement MUST be the ASCII-only address
 specified with the ALT-ADDRESS parameter, see more in [EAI-downgrading].
"

is it ok?

YAO Jiankang
CNNIC

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Mar 2007 20:05:35 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, March 25, 2007 12:37 AM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#13) 2.4. The ALT-ADDRESSparameter

>  encoding than ORCPT paramater value on [RFC3461]. 

according to my understanding, esmtp-value has been redefined in this document 
 ( ALT-ADDRESS-esmtp-value=Mailbox)

"If the ALT-ADDRESS
   esmtp-keyword is used, it MUST have an associated esmtp-value (ALT-
   ADDRESS-esmtp-value which is defined below) which requires an all-
   ASCII email address.

   Based on the definition of mail-parameters in [RFC2821], the ALT-
   ADDRESS parameter usage in the commands of "mail from" and "rcpt to"
   is defined below.

        "MAIL FROM:" SP <uReverse-path> [ SP <mail-parameters> ]<CRLF>
                   ; Update mail command in RFC 2821, section 3.3

            "RCPT TO:" SP <uForward-path> [ SP <rcpt-parameters> ]<CRLF>
                   ; Update rcpt command in RFC 2821, section 3.3

        uReverse-path = uPath
               ; Replace Reverse-path in RFC 2821, section 4.1.2

        uForward-path = uPath
               ; Replace Forward-path in RFC 2821, section 4.1.2

        uPath = "<" [ A-d-l ":" ] uMailbox ">"
               ; Replace Path in RFC 2821, section 4.1.2
                   ; A-d-l is defined in RFC 2821, section 4.1.2
                   ; uMailbox is defined in section 2.3 of this document

        ALT-ADDRESS-esmtp-value=Mailbox
           ; Mailbox is defined in RFC 2821, section 4.1.2
"

BTW,  "esmtp-value"  is defined in [RFC2821], not in  [RFC2822]

---

From: "YAO Jiankang" <[email-masked]>
Date: Tue, 27 Mar 2007 20:12:38 +0800

----- Original Message ----- 
From: "Kari Hurtta" <[email-masked]>
To: <[email-masked]>
Sent: Monday, March 26, 2007 12:56 AM
Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#15) 2.2. The AddressInternationalization Service Extension

>  (or on other UTF8SMTP related RFC) if  these parts include 

I think that it is reasonable.
if none object it, I will add it according to your kind suggestion.

YAO Jiankang
CNNIC

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 27 Mar 2007 15:22:32 +0100

> This is possible because on ESMTP there is parameter

That was the theory, but in practice that NOBY parameter gets left out  
even when there IS 8bit stuff later on. So (or so I was told when were  
debating Header-Type) implementations still go looking for 8bit stuff even  
when that parameter was absent.

I grant you that this only enables them to reject after DATA, and  
precludes the possibility of sending the message at least to thos RCPTs  
that can accept 8BITMIME.
> there is parameter HDR=UTF8

Which will be just as reliable, or unreliable, as that BODY parameter.

And it still does nothing for transports other than SMTP which may need to  
gateway into SMTP later on. Header-Type would have been much better. Sigh!

But yes, HDR-UTF8 will indeed give a little benefit, but not as much as  
people are claiming.

---

From: Kari Hurtta <[email-masked]>
Date: 28 Mar 2007 20:42:08 +0300

Rationale:
   Frank Ellermann suggested (if I remember correctly), that
   UTF8SMTP message should be defined on one place and
   referenced on smtp document (instead trying to
   define it on every document).

(I more or less promised to write that defination.)

New chapter to draft-ietf-eai-utf8headers:

   5.5 UTF8SMTP message

   Certain messages must be transmitted only if 
   SMTP extension specified in [EAI-SMTP-extension]
   is supported or otherwise environment supports
   these messages. These messages are called to 
   UTF8SMTP messages.

   Message is "UTF8SMTP message", if 
    * it uses  UTF-8 header fields as specified on this 
      document on header of message, or
    * it uses UTF-8 header fields on MIME header blocks
      on body of message, or
    * it includes MIME parts with new MIME subtypes of 
      "message" defined on [EAI-dsn] (or on other UTF8SMTP 
       related RFCes  such as this document, 
       [EAI-SMTP-extension], [EAI-mailing-list] or 
       [EAI-downgrading]) when  these MIME parts 
       include (unencoded) 8-bit data.

   This means that if message includes UTF8SMTP messages,
   with are carried on MIME subtypes of "message", message
   itself is UTF8SMTP messages.
   
   Media type for  UTF8SMTP message is defined on [EAI-dsn].

(perhaps also:)
   MIME subtypes of "message" are included, because these
   not support well 8-bit data on traditional SMTP.
   Generally it is suggested on MIME that new subtypes
   of "message" uses on 7-bit encoding on email environment.

Addition to 11.1.  Normative References:
   
 [EAI-dsn]  Newman, C., "SMTP extensions for DSNs",
            draft-ietf-eai-dsn-00.txt (work in progress), 1 2007.

If this addition is accepted, then my item 
draft-ietf-eai-smtpext-04.txt: (#15) can be changed

from 
  " If the UTF8SMTP SMTP extension is not offered by the server, 
    client MUST NOT transmit messages which includes MIME parts 
    with new MIME subtypes of "message" defined on [EAI-dsn] 
   (or on other UTF8SMTP related RFC) if  these parts include 
   (unencoded) 8-bit data. "

to  (chapter "2.2. The AddressInternationalization Service Extension")

    If the UTF8SMTP SMTP extension is not offered by the server,
    client MUST NOT transmit UTF8SMTP messages (as defined on
    [EAI-utf8header]], see [EAI-downgrading].

(I do not really care which one version is used.)

Rationale:

   MIME forbids quote-printable and base64 encoding of 
   them.

Note:
   This addition to draft-ietf-eai-smtpext-04.txt
   itself does not by forbid just using quoted-printable
   or base64 encoding of these "message" subtypes.

   However possible downgrader faces also RFC 2045's
   "EXPRESSLY FORBIDDEN" text :-)

   I guess however that this is ignored (and quite
   likely using of quoted-printable or base64 works
   in practise.)

/ Kari Hurtta

( Hmm. I think that I do not care. )

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 28 Mar 2007 20:31:26 +0100

On Tue, 27 Mar 2007 13:12:38 +0100, YAO Jiankang <[email-masked]> wrote:

> Subject: [EAI] draft-ietf-eai-smtpext-04.txt: (#15) 2.2. The  
> AddressInternationalization Service Extension
>
>
>>
>> Addition:
>>

No, I think we need to see what happens to [EAI-dsn]. In any case, the  
proper thing to do with such message types which happen to contain 8-bit  
stuff is to define a downgrade machenism for them. Agreed they must not be  
allowed through to the non-UF8SMTP server, but that is already true of  
lots of other things too, not just this case.

---

From: "abel" <[email-masked]>
Date: Thu, 29 Mar 2007 08:49:07 +0800

thanks for your information and Harald comments, 
tomorrow ,I will finish the utf8header-05.

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 29 Mar 2007 11:49:46 +0100

>       document on header of message, or

No, this doesn't quite work yet.

Firstly, the term defined is "UTF-8 header", not "UTF-8 header field".

The definition is:

    In this document, header fields are "UTF-8 headers" if the bodies of
    those headers contain UTF-8 characters.

So, secondly, we need a definition of "UTF-8 character", but there is none  
given. For example, is 'A' a UTF-8 character? Yes, of course it is, since  
every ASCII character is already a UTF-8 character. So the term we  
actually need is <UTF8-xtra-char> (or whetever we decide to call it, since  
Smtpext currently uses a different term). That term is defined by a clear  
syntax, and 'A' is not one of them.

Then, thirdly, the definition of a UTF-8 header needs to make clear that  
it MUST contain at least one <UTF8-xtra-char>, and then we can say that a  
UTF8SMTP message contains at least one such "UTF-8 header" somewhere  
within it.

For defining what we mean by "somewhere within it", then the definitions  
you give are getting nearer.

>     * it uses UTF-8 header fields on MIME header blocks

Yes, but you also need:

       * it contains a message/rfc822 which is itself a UTF8SMTP message, or

>        include (unencoded) 8-bit data.

But that one assumes that we are going to have such message types defined  
in [EAI-dsn], and that depends whether we can get around that "EXPRESSLY  
FORBIDDEN" in RFC 2045.

Safer to say:

       * it includes MIME parts with new MIME subtypes that are, by their
         definitions, only permitted in UTF8SMTP messages.

Since it is not clear to me that the presence of a message/utf-8 or  
application/utf-8-message, or whatever we decide to call it, necessarily  
causes the containing message to be a UTF8SMTP one (for example, the  
object defined in [EAI-dsn] is intended to be transportable as part of an  
ordinary RFC 2822 message).

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 29 Mar 2007 18:21:01 +0200

Charles Lindsey wrote:

> the definition of a UTF-8 header needs to make clear that it MUST
> contain at least one <UTF8-xtra-char>

It's a definition, not a reqirement, strike the MUSTard.  It should
also say that a header field containing unencoded 8 bit characters
which are *_not_* UTF-8, is certainly no "UTF-8 header field".

Let's not mix "header" and "header field" here, we have already THE
header (top level), more headers (for MIME parts), each consisting
of "header fields", some of them with a "header field body" using
<UTF8-non-ASCII>.  Any other (unencoded) non-ASCII is OUT, and any
header field names using non-ASCII are also OUT.

> then we can say that a UTF8SMTP message contains at least one such
> "UTF-8 header" somewhere within it.

That's not the case for a contained 8-bit message/rfc822, which in
turn contains an 8-bit message/utf8 (or similar).

Likewise a contained 8bit message/foo (unknown) could "contain" a
message/ut-8.  Actually if message/foo is unknown for applications
they also have no concept of what's "contained" in a message/foo:

> For defining what we mean by "somewhere within it", then the
> definitions you give are getting nearer.

>>     * it uses UTF-8 header fields on MIME header blocks

UTF-8 in a MIME part header including Content-Type message/foo
says nothing about the internal structure of a message/foo body.

>      * it contains a message/rfc822 which is itself a UTF8SMTP
>        message

While any message/rfc822 is always also a message/utf-8 I don't
see what you're getting at.  It would be clearer if you just say
"it contains a message/utf-8 part" or "an UTF8SMTP message part".

But only directly nested (part of a multipart ... of a multipart),
not in a foreign context message/foo with an unknown structure.

> Safer to say:
>        * it includes MIME parts with new MIME subtypes that are, by
>          their definitions, only permitted in UTF8SMTP messages.

Is there any process trick to disable RFC 4288 for a split second ?
This issue would be clearer with a new MIME top level type.  Or a
new MIME version 2.0, you're killing far too many MIME 1.0 rules.

Frank

---

From: Bill McQuillan <[email-masked]>
Date: Thu, 29 Mar 2007 15:50:22 -0700

On Thu, 2007-03-29, Charles Lindsey wrote:
> a UTF-8 header ... MUST contain at least one <UTF8-xtra-char> ...

This seems to over specify UTF-8 header. What happens, in *mumble* years when everybody is happily using EAI emails and I, completely accidentally, happen to send an email that fortuitously contains only ASCII characters. When my correspondent replies including a copy of my original as an attached message, MUST his MUA scan the included message to see whether it contains any <UTF8-xtra-char>s and mark it message/rfc822 rather than, by then default, message/utf8?

What happens if it is lazy and just marks it message/utf8, since that is a superset of message/rfc822. Must any MTA it transits determine that it is improperly marked and reject or modify it?

Perhaps the phrasing of the quoted phrase should be:
a UTF-8 header MAY contain at least one <UTF8-xtra-char>.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 30 Mar 2007 14:46:20 +0100

On Thu, 29 Mar 2007 23:50:22 +0100, Bill McQuillan <[email-masked]>  
wrote:

> This seems to over specify UTF-8 header.

We are trying to define the term "UTF8 message", and the essential  
requirement is that it defines that class of messages which MUST NOT be  
forwarded as they stand to an MTA which does not advertise UTF8SMTP.  
Therefore we require that a message which adheres strictly to RFC 2822 and  
the present MIME standards is NOT a "UTF8 message". Therefore, to be a  
"UTF8 message" it MUST contain somewhere within it a header with a genuine  
<UTF8-xtra-char> inside it. Otherwise, it is already acceptable to present  
MTAs which do not advertise UTF8SMTP.

> What happens, in *mumble* years when everybody is happily using EAI  
> emails and I, completely accidentally, happen to send an email that  
> fortuitously contains only ASCII characters.

In *mumble* years, all MTAs will advertise UTF8SMTP, and nobody will need  
to care any more.

> When my correspondent replies including a copy of my original as an  
> attached message, MUST his MUA scan the included message to see whether  
> it contains any <UTF8-xtra-char>s and mark it message/rfc822 rather  
> than, by then default, message/utf8?

That all depends whether we are going to define message/utf8 or not. All  
suggested definitions of that type so far are EXPRESSLY FORBIDDEN by RFC  
2045. Personally, I want to allow UTF8 messages to be sent as  
message/rfc822, in which case the question will not arise.

---

From: "Charles Lindsey" <[email-masked]>
Date: Fri, 30 Mar 2007 16:23:30 +0100

On Thu, 29 Mar 2007 17:21:01 +0100, Frank Ellermann  
<[email-masked]> wrote:

> It's a definition, not a reqirement, strike the MUSTard.

It is a definition of those things which MUST NOT be forwarded to MTAs  
which do not advertise UTF8SMTP. If there is no <UT8-xtra-char> within any  
header within it, then it is OK to send it through present-day MTAs.

>  It should

That is already covered by the syntax of <UTF8-xtra-char>. So a header  
containing any octet not a valid part of a UTF-8 character would not be a  
UTF8 header - in fact it would not be a valid header for ANY kind of mail  
message currently envisaged.

> of "header fields",

Agreed. It is the present definition of "UTF8 header" in the UTF8headers  
draft which should be changed to "UTF8 header field".

> turn contains an 8-bit message/utf8 (or similar).

Since we haven't defined the term "message/utf8" yet (at least, not in any  
manner permitted by RFC 2045), your remark is meaningless. If and when we  
define such a term, it will be in order to ask whether a UTF8 header field  
inside it would count towards causing something to be a "UTF8 message".
> they also have no concept of what's "contained" in a message/foo:

Which is precisely why the phrase "contains ... somewhere within it" needs  
careful definition so that is is clear whether such cases fall within it.  
It you look at what I said further down, you will see that things inside a  
message/foo do not count.
> says nothing about the internal structure of a message/foo body.

Irrelevant. It you see the header
    Content-Type: message/foo; name="manaña"
then it is going to be a UTF8 message whatever the internal structure of  
message/foo might be.

> "it contains a message/utf-8 part" or "an UTF8SMTP message part".

What you say is meaningless until you can point to an agreed definition of  
"message/utf-8". AFAIAC, a message/rfc822 can perfectly well be a "UTF8  
message", in which case any message that contains it is itself a "UTF8  
message".

> new MIME version 2.0, you're killing far too many MIME 1.0 rules.

It will work perfectly well with extensions of the present MIME 1.0 rules,  
provided there are clear rules for downgrading those extensions.

---

From: Bill McQuillan <[email-masked]>
Date: Fri, 30 Mar 2007 09:44:55 -0700

+1

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 30 Mar 2007 19:51:56 +0200

>     those headers contain UTF-8 characters.

Charles, we went over this in USEFOR.

According to RFC 2822, a "header field" is a single (possibly folded) line 
- consisting of a header field name and a header field value.

A "header" is the whole set of header fields before the first blank line.

               Harald

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 31 Mar 2007 12:41:38 +0200

Charles Lindsey wrote:

> That all depends whether we are going to define message/utf8 or not.
> All suggested definitions of that type so far are EXPRESSLY FORBIDDEN
> by RFC 2045.

It's "only" a SHOULD, and necessarily EAI is an excuse to violate it.

> Personally, I want to allow UTF8 messages to be sent as message/rfc822

That gives you MIME 1.0 as is with RFC 2049 as is, and the whole EAI
effort should IMNSHO never survive something like an IETF Last Call.