On 27 Nov 2015 3:31 PM, Viktor Dukhovni wrote:
> On Fri, Nov 27, 2015 at 02:55:34PM -0500, Felipe Gasper wrote:
>
>>> A non-delivery-notification (MIME multipart/report content type
>>> RFC3462) consists of (up to) three parts:
>>>
>>> 1. Required initial free-form body part, this can use UTF-8
>>> without any need for EAI.
>>>
>>> 2. Required message/delivery-status machine readable part,
>>> this requires EAI for non-ASCII content. (RFC3464).
>>>
>>> 3. Optional returned message or message headers. If
>>> the returned message has UTF-8 headers, it may need
>>> to encapsulated as an EAI message/global
>>>
>>> My interpretation of the question was that you wanted UTF-8 in the
>>> "part 1", body, in which case *in principle* you could have raw
>>> UTF-8 there, and a "charset=utf-8" attribute for the enclosing MIME
>>> part, provided that the code that generates bounces (in this case
>>> in Exim) allows you configure the charset and associated content.
>>
>> Yes, part 1 is where I want the UTF-8 to go.
>>
>> I’ve not consulted the RFCs myself. Basically, I want the text after Exim
>> shows the intended recipient address to be able to be any UTF-8 characters.
>
> This may well be a feature request, I don't know whether Exim
> supports this or not. As proof of concept (this is neither a
> sufficient nor implied reason to consider Postfix, just an
> example I happen to be familiar with):
>
I think, yes, this is a feature request.
src/deliver.c, at least, hard-codes US-ASCII as the charset for those
“fail” messages; the ability to customize those doesn’t seem to be in
evidence currently.
It would, of course, make Exim that much friendlier to i18n contexts to
have this!
-FG
