RFC 1342 and mutt
Velko Hristov
> I've been noticing I get some messages where the subject begins with
> =?US-ASCII?Q?<the subject>?=. I looked this up on google (took some time
> because a ton of things come up when you just look for the string) and
> finally found RFC 1342, which said that this was non-ascii text, and that
> the character set is what appears after the =? (us-ascii in this case,
> instead of ascii).
> After reading this, I decided to see what other IMAP clients saw when they
> displayed these messages, and they do not show the us-ascii thing, which
> means that they understand rfc 1342. Is there a way to get mutt to do so,
> also? Or does mutt use some external program I need in order to do this?
Well, I don't know anything about rfc 1342, but when I receive mail from
my parents the subject line looks usually like this:
Subject: =?windows-1251?B?x+Tw4PHy6Cwg8ejt5S4=?=
And mutt displays it correctly, so I don't see the encoding information
and all this x+Tw... stuff.
But, sorry, I don't know what you have to do in order to get it work.
Probably you should check if this encoding is installed on your system
and if so - try setting charset=us-ascii in your .muttrc. Only guessing,
anyway.
Velko
Velko Hristov
> But, sorry, I don't know what you have to do in order to get it work.
> Probably you should check if this encoding is installed on your system
> and if so - try setting charset=us-ascii in your .muttrc. Only guessing,
> anyway.
The charset information on my rh box is located under
/usr/share/i18n/charmaps. The real name of windows-1251 (putted by m$
outlook in the headers) is CP1251, and the charset file is called
/usr/share/i18n/charmaps/CP1251.gz.
I have also these hooks in my .muttrc (thanks to Anton Zinoviev):
# Aliases for broken MUAs
charset-hook windows-1250 CP1250
charset-hook windows-1251 CP1251
charset-hook US-ASCII CP1251
charset-hook ISO-8859-1 CP1251
set charset=windows-1251
Velko
Michael Tatge
> I've been noticing I get some messages where the subject begins with
> =?US-ASCII?Q?<the subject>?=.
try setting rfc2047_parameters. And read section 6.3.189 of the manual.
HTH,
Michael
--
We are Pentium of Borg. Division is futile. You will be approximated.
(seen in someone's .signature)
PGP-Key: http://www-stud.ims.uni-stuttgart.de/~tatgeml/public.key
jennyw
I also have /usr/share/i18n/charmaps/CP1251.gz. However, when I use your
hooks, I still get the =?us-ascii ... I'm using Debian 3.0, by the way.
Do you know where I can read more about charsets? This is one of those
things where I can't tell if the system is misbehaving or if it's mutt.
For example, how does mutt know what directory the charsets are in? If I
knew this and a way to test to see if the system is finding the right
charsets, I'd know whether the problem is with my mutt config or outside
of mutt. Also, how did you figure out the real name of the charsets?
There's no way I would have guessed that US-ASCII was really CP1251.
Thanks!
Jen
Nicolas Rachinsky
> I've been noticing I get some messages where the subject begins with
Can you send us the whole string? =?US-ASCII?Q?<the subject>?=
Nicolas
Lukas Ruf
> I've been noticing I get some messages where the subject begins with
> =?US-ASCII?Q?<the subject>?=. I looked this up on google (took some time
> because a ton of things come up when you just look for the string) and
> finally found RFC 1342, which said that this was non-ascii text, and that
> the character set is what appears after the =? (us-ascii in this case,
> instead of ascii).
>
I have a quite similar problem when displaying names of receivers who have
German umlauts. It is very strange however. When I receive emails with
German umlauts in the name of the sender, they get correctly
displayed. When I replied to such a message, the names of the (now)
receivers suffer from the same problem, for example:
100 F Jun 19 To Michel=?iso-8859-1? (0.3K) mq>
101 T Jun 19 Michel Dänzer (0.3K) mq>
(cut-&-paste from my index)
I am using mutt 1.4i, edit all my stuff with vim 6.1 on a debian 3.0
system, and mutt -v results in:
komsys-pc-basel:~!56> mutt -v
Mutt 1.4i (2002-05-29)
[..]
System: Linux 2.4.17-basel.v2 (i686) [using ncurses 5.2]
Compile options:
DOMAIN="maremma.ch"
-DEBUG
-HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE
+USE_FCNTL -USE_FLOCK
+USE_POP +USE_IMAP -USE_GSS -USE_SSL -USE_SASL
+HAVE_REGCOMP -USE_GNU_REGEX
+HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET
+HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM
+HAVE_PGP -BUFFY_SIZE +EXACT_ADDRESS -SUN_ATTACHMENT
+ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET
+HAVE_LANGINFO_YESEXPR
+HAVE_ICONV -ICONV_NONTRANS +HAVE_GETSID +HAVE_GETADDRINFO
ISPELL="/usr/bin/ispell"
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/local/share/mutt"
SYSCONFDIR="/etc/mutt"
EXECSHELL="/bin/sh"
-MIXMASTER
[..]
In my muttrc I have the following definitions (based on hints I got by
this mailing lists):
set charset="iso-8859-1"
set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8"
set locale="de_CH"
#
# charset-hook alias charset
# (define charset aliases)
#
charset-hook x-unknown ISO-8859-1
charset-hook windows-1250 CP1250
charset-hook windows-1251 CP1251
charset-hook windows-1252 CP1252
charset-hook windows-1253 CP1253
charset-hook windows-1254 CP1254
charset-hook windows-1255 CP1255
charset-hook windows-1256 CP1256
charset-hook windows-1257 CP1257
charset-hook windows-1258 CP1258
Thanks for any hint.
Lukas
Velko Hristov
> of mutt. Also, how did you figure out the real name of the charsets?
> There's no way I would have guessed that US-ASCII was really CP1251.
Oh sorry, forgot about this part. us-ascii has nothing to do with
cp1251. But because in cp1251 the latin letters are also present on the
same positions like in us-ascii I still can read mails written in
English, nevertheless I use cp1251 instead of us-ascii. The only problem
with this approach is the substitution of iso-8859-1 with cp1251 (by
charset-hook in my .muttrc) because I see cyrillic letters instead of
german umlauts. But I can live with that.
Velko
Rocco Rutte
* jennyw [02-07-27 13:53:03 +0200] wrote:
> On Fri, Jul 26, 2002 at 11:37:46PM +0200, Michael Tatge wrote:
> > try setting rfc2047_parameters. And read section 6.3.189
> > of the manual.
> I tried this, but no dice.
Clear. It only affects encoding in MIME parameters which is
not allowed (but this way you can handle it, too).
> By the way, RFC 2047 seems to refer to attachments. I'm
> having trouble with the subject header, so maybe it
> doesn't apply?
RfC2047:
,-
| MIME (Multipurpose Internet Mail Extensions) Part Three:
| Message Header Extensions for Non-ASCII Text
`-
bye, Rocco
Rocco Rutte
* jennyw [02-07-27 13:52:23 +0200] wrote:
> I've been noticing I get some messages where the subject
> begins with =?US-ASCII?Q?<the subject>?=.
First of all, in this case the encoding is stupid since it
only wasts bandwidth. The default for use in headers is
us-ascii (us-ascii and ascii is no difference at all) and
thus 7bit. It is correct to encode allready 7bit clean
subjects like this... but it's useless.
> After reading this, I decided to see what other IMAP
> clients saw when they displayed these messages, and they
> do not show the us-ascii thing, which means that they
> understand rfc 1342.
Clients (like mutt) should implement MIME and thus RfC2047.
RfC2047 is from 1996... enough time, IMHO.
> Is there a way to get mutt to do so, also? Or does mutt
> use some external program I need in order to do this?
Mutt has internal routines to handle RfC2047. If you see the
encoded instead of the decoded string, mutt wasn't abled to
decode it because most likely the sender's client is broken.
There's no real solution for use on your side. Personally I
use a mailfilter which corrects broken encodings but there's
no mutt-only solution I know of.
bye, Rocco
Luke Ravitch
> There's no real solution for use on your side. Personally I
> use a mailfilter which corrects broken encodings but there's
> no mutt-only solution I know of.
Could you post your filters (or a link)? Thanks.
--
Luke