[EAI] idea of "Bounce and resend" model

[[e-mail]]

Hi, All,

The WG meeting decided removing "<UTF8 <ASCII>>" format and ALT-ADDRESS.
And downgrade (RFC 5504) is used for POP/IMAP delivery only.

I don't like new extension between MUA and Submission server.

This is my idea that use RFC 5335 and RFC 5336 without ASCII alternate
address. I propose MUA and sender user have new following functions.

 - MUA can select two modes:

      The EAI mode:
		The sender can use non-ASCII From: address and non-ASCII
		To, CC address.
		The MUA can generate EAI messages.
                   (non-ASCII in headers, MIME headers)

      The compatibility mode:
      	  	The sender can not use non-ASCII From, To, CC.
		The MUA generates RFC 5322 message using MIME encoding.

 - Sender user MUST know the modes.
#          - Or,    the MUA does not use EAI extensions
#                   if all recipients' address are ASCII.

Precondition:

  P.0: exclude mailing-list case

  P.1:  based on current experimental RFCs. (RFC 5335 and RFC 5336)

  P.2a: If the recipient uses non-ASCII address as its address, 
        his MX servers support EAI extension.
	Otherwise, it's misconfiguration.

  P.2b: If the recipient uses ASCII address as its address,
        its MX servers and its client may not support EAI extension.

  P.3a: The sender's MUA supports EAI extension.

  P.3b: The sender's submission server supports EAI extension.
	Otherwise, the MUA reports an error.

  P.4: The sender has both non-ASCII address and ASCII address.
       Otherwise, the sender cannot talk with another traditional email user.

  P.5: The sender knows the recipient's non-ASCII address.
       The sender may know the recipient's ASCII address.

  P.6: Sending error may happen at the MX (mail exchange) boundary.

Cases are from draft-ietf-eai-scenarios-03.txt
    http://tools.ietf.org/html/draft-ietf-eai-scenarios

Case 2.1: Two i18mail users (non-ASCII to non-ASCII)

  The sender cannot choose the compatibility mode.
  The message will reach to the recipient because of P.2a, P.3a and P.3b.

Case 2.2: Three i18n users

  The sender cannot choose the compatibility mode.
  The message will reach to the recipient because of P.2a, P.3a and P.3b.

Case 2.4: One i18mail user sends to one ascii user

  (1) First, the sender choose EAI mode and uses its non-ASCII address
  as "From:" header. The recipient address is ASCII.

  If the recipient system and MUA support EAI, it receives the message.

  (2) If the recipient system does not support EAI extension,
  the boundary MTA bounces the message and the sender receives error message.

  **** The error message is very important. ****

  (3) Then the sender resend the message using ASCII From: address and
      compatibility mode.  Then, the message is RFC 5321/5322 and it
      will reach the traditional recipient.

  (2') if the recipient system support EAI,
       but the recipient user's MUA does not support EAI,
       then the POP server downgrade the message,
       but the From: header field is downgraded as
       "From: Internationalized address ENCODED-WORD removed:;".

       **** The recipient cannot reply anything. ****
            How to solve ?

case 2.5: An i18mail user sends to one ascii user and one i18mail user
          A sends B and X ; both reply.  (A and B are non-ASCII, X is ASCII)

  Preconditions: A and B have both non-ASCII address and ASCII address.
  		 A(a) is ASCII address of A. A(n) is non-ASCII address of A.
  		 B(a) is ASCII address of B. B(n) is non-ASCII address of B.

  (1) First, A choose EAI mode:
          From: A(n)
          To: B(n), X

     if X support EAI, X can receive the message.
        B(n) receive the message.
	Both reply works well -> done

     if X does not support EAI:

        B(n) receives the message.
        A(n) receives error message that X does not support EAI extention.

       (2): A need to resend the message.
            A know B's ascii address and A has ASCII address.
	    A resends message using the compatibility mode.
                  From: A(a)
		  To:   B(a), X
            -> X receives the message.
		 -> reply works.
 	    B receives the message twice.
               (then B will know X does not support EAI).
               -> B can reply using ASCII version.

case 2.7: An i18mail user forwards to an ASCII user

         A sends to B and B forwards the message as a MIME attachment to X

  I don't agree the "Desirable property" because it rewrites messages.
  X can reply it cannot read the attachment and B can re-send the message
  as a text.

----------------------------------------------------------------------------
Regards,

--
Kazunori Fujiwara, JPRS <[e-mail]>