Re: What's needed for mutt 1.6? (Debian patches)
Hi, Alain.
On Tue, Mar 06, 2007 at 08:02:35PM +0100,
Alain Bench wrote:
> > what/where is (8) multiple_charsets?
>
> <URL:http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.mutt-j.multi-charset.1.gz>
>
> Yet another mega-patch by Takashi, composed of assumed, attach,
> wcwidth, and several others. Noone knows how much. No comments included,
> no (english) doc.
The mutli-charset patch contains the followings:
- assumed_charset --> commited
- attach_charset --> commited
- ignore_linear_white_space --> commited
- iconvhook (written by MORIYAMA Masayuki) --> commited
- wcwidth --> proposing
http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt.wcwidth.3
- pgp_charsethack (written by Tamotsu Takahashi)
http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tamo.pgp_charsethack.1
$pgp_charsethack
If set, Mutt will assume a non-MIME PGP armored message to be in
the charset specified in Charset: armor header (by GnuPG) or in
Content-Type message header (by some MUAs). You should not set
this variable, because such an armor shouldn't have charset information.
By default, Mutt assumes such messages to be in UTF-8 (see RFC2440).
You will ignore the RFC if you set this variable!
(PGP only)
- create_rfc2047_params
http://www.emaillab.org/mutt/1.5.14/patch-1.5.14.tt.create_rfc2047_params.1
$create_rfc2047_params
When this variable is set, Mutt will add the following RFC-2047-encoded
MIME parameter to Content-Type header field as filename for attachment:
name="=?iso-2022-jp?B?GyRCO244MxsoQi50eHQ=?="
Note: this use of RFC 2047's encoding is explicitly prohibited
by the standard. You may set this variable only if a mailer
of recipients can not parse RFC 2231 parameters.
Because the pgp_charset patch and the create_rfc2047_params patch violate
RFCs, I don't propose it.
However, it is easy to use it when the message is sent with the user of
the legacy mailer each other.
--
TAKIZAWA Takashi
http://www.emaillab.org/