Re: [smtpmail.el] Encoding problem in smtpmail-send-queued-mail

[Simon Josefsson]

On Mon, 10 Dec 2001, Eli Zaretskii wrote:

> On Mon, 10 Dec 2001, Jesper Harder wrote:
> 
> > I did some tests by sending utf-8 with CTE 8bit -- and binding
> > `smtpmail-code-conv-from' doesn't work in this case.  When I run
> > `smtpmail-send-queued-mail' Emacs asks me to select a coding system:
> > 
> > ,----
> > | These default coding systems were tried:
> > |   iso-latin-1-unix
> 
> This last snippet indicates that Emacs visited the file thinking it
> was a Latin-1 file, which is wrong.  That's why it says iso-latin-1
> above, and that's why the mail goes out garbled.
> 
> The problem here is that it is not a good idea to let Emacs guess the
> encoding of a file, as it does by default, if we already know what the
> encoding is.  That's why I think the two alternatives I outlined in my
> previous message are the right ones: either don't use any conversions
> at all, or force the same conversion as was used when the file was
> written.
> 
> I think the first alternative, the one you originally suggested, is a
> better one, since Emacs doesn't need to do anything with the file
> except send it down the mail pipe.  So code conversions seem like a
> waste of CPU cycles.
> 
> Simon, do you agree with this reasoning?

Yes.  Altough the conclusion might not be perfect, since smtpmail.el may 
need to know the encoding the data is in if we are going to implement 
better 8BITMIME support (that is, have smtpmail.el fall back and QP if 
server does not support 8BITMIME). But if someone implements it, then they 
can think about this issue again.

Also, smtpmail.el is part of XEmacs as well, but if the mail is just sent
from disk to the network without any conversion when sending queued mail,
all will be fine regardless of which emacs did what.  The on-disk
representation would be latin-1 (for latin-1 mail) wouldn't it?