Re: bug#8070: gnus damages attached file

[Hobbit <werehobbit@yandex.ru>]

Andreas Schwab <schwab@linux-m68k.org> writes:

> It doesn't make sense to send a text without charset information, unless
> it is pure ASCII.  Why would you want the recipient to guess wrong?

Because almost all of my work recepients use Windows and expect only
CP1251. Especially my boss, which hates receiving files in any other
codepages. And sometimes I had to send files in CP866 (old DOS encoding)
to my colleagues which still use some old DOS programs. I use UTF8 only
when I'm talking with Open-Source hackers. So 98 % cases my recepients
know what they are going to view. I even doubt that

Content-Type: text/plain; charset=xxxxxxx

could make a difference, because in most of a cases they just save a
file to a hard drive and open it in some other program. Introducing some
Gnus ability for other 2 % just create unnecesary problems.

And some text formats (for example, LaTeX) have something like

\usepackage[cp1251]{inputenc}

which directly states document encoding.

> Are you sure it is Gnus that reencodes the attachment?  It could also be
> altered by any MTA.

At least when I evaluate (setq mm-coding-system-priorities
'(iso-8859-1)) before sending a mail I receive my files unchanged. Could
a MTA reencode files when it sees

Content-Type: text/plain; charset=xxxxxxx

string? Because some of my Internet interlocutors also have this problem
(and they use other MTA's).

Andreas Schwab <schwab@linux-m68k.org> writes:

> Hobbit <werehobbit@yandex.ru> writes:
>
>> Gnus should find out the correct charset only for inline attachment or
>> for Disposition='attachment' attachement too?
>
> How does that make any difference?
>

When I use an 'inline' attachment it part of a message and could be
reencoded (it's normal). If it's Disposition='attachment' then it's best
for Gnus to leave file unchanged. It's an 'attachment' ('burn after
reading, please'), imagine: you ordered a tech book and received it with
others man handwritten notes as 'improvement'.