Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses

Alexey Melnikov <> Sun, 27 August 2006 14:27 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GHLbV-00058P-KP; Sun, 27 Aug 2006 10:27:13 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GHLbU-00058D-Ow; Sun, 27 Aug 2006 10:27:12 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GHLbT-0007so-8R; Sun, 27 Aug 2006 10:27:12 -0400
Received: from [] ( []) by via TCP (submission) with ESMTPA; Sun, 27 Aug 2006 15:26:38 +0100
Message-ID: <>
Date: Sun, 27 Aug 2006 13:19:04 +0100
From: Alexey Melnikov <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Tony Finch <>
Subject: Re: [Ltru] Re: [EAI] New draft for allowing UTF-8 in SMTP responses
References: <> <> <> <003401c6c54d$18765640$6501a8c0@oemcomputer> <6AD3D4FD1D4C386BE716C69C@p3.JCK.COM> <> <>
In-Reply-To: <>
MIME-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: Greg Vaudreuil <>, LTRU Working Group <>, Addison Phillips <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Tony Finch wrote:

>Addison says:
>>Almost no one interacts with SMTP servers directly.
>Of course they do, to the same extent that they interact with IMAP or POP
>or HTTP servers - mediated by a user agent.
>From my point of view, and from the point of view of my colleagues on the
>help desk, it would be much easier if MUAs did not try to impose their own
>gloss on my servers' error messages (or do other stupid things like
>truncate them). That way I can provide helpful text that explains what
>went wrong, and/or a URL to help pages or a directory.
>The curre.
b). Extend message/delivery-status to allow for 8bit data. RFC 3464 seem 
to disallow this:

2.1 The message/delivery-status content-type

   The message/delivery-status content-type is defined as follows:

   MIME type name:             message
   MIME subtype name:          delivery-status
   Optional parameters:        none
   Encoding considerations:    "7bit" encoding is sufficient and
                               MUST be used to maintain readability
                               when viewed by non-MIME mail readers.

And RFC 2046 seem to advise against non-7bit encodings in message/*:

5.2.4. Other Message Subtypes

   MIME implementations must in general treat unrecognized subtypes of
   "message" as being equivalent to "application/octet-stream".

   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.


P.S. However I still thing that encouraging servers to implement 
Enhanced Status Codes is a good idea.
I would also like to work on response boilerplates.

IMA mailing list