[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: smtpmail and ~/.authinfo

From: Ted Zlatanov
Subject: Re: smtpmail and ~/.authinfo
Date: Sun, 25 Sep 2011 08:21:36 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux)

On Sun, 25 Sep 2011 08:48:07 -0400 Eli Zaretskii <address@hidden> wrote: 

>> From: Ted Zlatanov <address@hidden>
>> Date: Sun, 25 Sep 2011 07:33:20 -0500
>> Reply-To: address@hidden
>> Thus the Emacs format is backwards compatible but older netrc consumers
>> can't necessarily read our tokens, so I think it's OK that we go further
>> and explicitly allow Unicode characters through UTF-8.  Would it make
>> sense, then, to explicitly use utf-8 or auto-guess for the encoding
>> instead of raw-text?

EZ> Only if either (a) we encode the responses we send to the SMTP server
EZ> during handshake, or (b) SMTP servers support UTF-8 encoding in the
EZ> strings they expect to receive.

EZ> Lars said "encoding is local", which suggest that neither of the above
EZ> is true.  raw-text leaves the byte stream unchanged, and only converts
EZ> the EOL, so a netrc file encoded in some locale-specific way has a
EZ> better chance with SMTP servers from the same locale.

EZ> IOW, to answer your question, someone who knows more than I do about
EZ> communications with SMTP servers should tell us how, if at all,
EZ> non-ASCII characters are supposed to be handled when communicating
EZ> with the server.

I don't think the SMTP interaction should not be the critical factor
here.  The SMTP library should deal with invalid (for SMTP) characters
on its side; many other libraries and protocols use `auth-source-search'
that can handle non-ASCII characters.  In other words, let's not limit
the capabilities of `auth-source-search' just because one of the users
can't handle non-ASCII.

I think authinfo/netrc files should be portable and support Unicode in a
way that enables other (older or new!) software to use them too.  IMHO
enforcing UTF-8 encoding is the best way to achieve that.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]