--On Friday, November 27, 2015 1:06 PM -0500 Felipe Gasper
<felipe@???> wrote:
> On 27 Nov 2015 6:05 AM, Jasen Betts wrote:
>> On 2015-11-26, Felipe Gasper <felipe@???> wrote:
>>> Hi all,
>>>
>>> When I do:
>>>
>>> fail text "$home:/Nööö!!!"
>>>
>>> … I get a fail message with:
>>>
>>> /home/mortal:/N\303\266\303\266\303\266!!!
>>>
>>> This (with US-ASCII encoding) appears to be hard-coded into
>>> src/deliver.c … is there any motion in the direction of
>>> being able to specify an encoding for fail messages?
>>
>> As far as I understandthe rules of SMTP:
>>
>> The only other charset allowed is UTF8 and that only if the
>> HOST advertises "SMTPUTF8" in in response to "EHLO" _and_ the
>> client says "SMTPUTF8" after the <address> part of the SMTP
>> "MAIL FROM" command.
>>
>> SMTPUTF8 support in exim is still considered experimental,
>> but if building with EXPERIMENTAL_INTERNATIONAL enabled does
>> not allow UTF8 in responses I would consider that a bug.
>> (not that I have any authority)
To the extent to which I qualify as an authority, Jason is
correct.
> But why is this relevant for the message body?
>
> The argument to "fail text" is put into the message body,
> not the headers … ?
I'm not sure I completely understand what is happening here,
but, if the text you cite is part of a non-delivery
notification, a body part would have to have content-type
message/global-* to contain non-ASCII (specifically UTF-8; there
are deliberately no other options) information. And one is not
supposed to produce those notifications unless SMTPUTF8 is in
use. See RFC 6533 for more information.
FWIW, the WG struggled very hard to make all of this more
flexible, but every approach that could be found lead to cases
of lost, trashed, or dead end messages with no possibility of
delivery of intelligible error reports... and one really does
not want to go there.
john
>
> -FG
