Re: koi8 headers upset message list
Igorx Ivanov
> Whenever the message is displayed in the message
> list, mutt immediately behaves as if the '?' has
> been pressed and displays the list of key bindings.
> ~/tmp$ cat bb
> From a...@bbb.ccc Sat Mar 19 05:06:05 2005
> From: =?koi8-r?B?6cLSwcfJzc/XIOsu4i4=?= <h02ck...@lara.com>
> Subject: =?koi8-r?B?887BwtbFzsnFLCDU0sHO09DP0tQsINTBzc/WztEgycHM?=
> Content-Type: text/html; charset="koi8-r"
Please show output of
:set ?charset
Mutt command.
--
Nudists are people who wear one-button suits.
Alan Connor
<mlvo31l1ds5qvnp1g...@4ax.com>,
"new...@foobar.clara.co.uk" wrote:
> Hi,
>
> I am having problems with Mutt due to some spam that has landed
> in my inbox. Whenever the message is displayed in the message
> list, mutt immediately behaves as if the '?' has been pressed
> and displays the list of key bindings.
>
X-No-Archive: yes
You have that in your headers.
That means that your posts won't be kept in the Usenet Archives
at groups.google.com.
And that means that you are a selfish prick, because the Usenet
is about sharing information.
Yet you call yourself: new...@foobar.clara.co.uk.
Should be: no-ne...@foobar.clara.co.uk
And/or it means that you are a troll or a spammer or a cracker
who doesn't want people to be able to track your posting history
through the Archives.
Or, possibly, you are just a paranoid nutbag.
Here are the headers that you are trying to hide from everyone:
Path: newsspool2.news.pas.earthlink.net!stamper.news.pas.earthlink.net
!stamper.news.atl.earthlink.net!elnk-atl-nf1!newsfeed.earthlink.net
!news.mediascape.de!newsfeed.arcor.de!newsfeed01.sul.t-online.de!t-online.de
!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!newspeer1-win.ntli.net
!newsfe2-gui.ntli.net.POSTED!53ab2750!not-for-mail
From: new...@foobar.clara.co.uk
Newsgroups: comp.mail.mutt
Subject: koi8 headers upset message list
Message-ID: <mlvo31l1ds5qvnp1g...@4ax.com>
X-Newsreader: Forte Agent 1.93/32.576 English (American)
X-No-Archive: yes
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 64
Date: Sat, 19 Mar 2005 19:46:07 GMT
NNTP-Posting-Host: 81.104.202.233
X-Complaints-To: http://www.ntlworld.com/netreport
X-Trace: newsfe2-gui.ntli.net 1111261567 81.104.202.233 (Sat, 19 Mar 2005
19:46:07 GMT)
NNTP-Posting-Date: Sat, 19 Mar 2005 19:46:07 GMT
Organization: ntl Cablemodem News Service
Xref: news.earthlink.net comp.mail.mutt:24554
X-Received-Date: Sat, 19 Mar 2005 11:48:01 PST
(newsspool2.news.pas.earthlink.net)
endquote
AC
Sven Guckes
> ~/tmp$ mutt -v
> Mutt 1.4i (2002-05-29)
mutt 1.5.9!
you are missing some 30 months
of development and about a
dozen version in between..
so - upgrade!
Sven
Igorx Ivanov
With Mutt 1.5.8i (2005-02-12) in uxterm X.Org 6.8.1(200) under
FreeBSD 5.4-PRERELEASE Mutt does not behave like key '?' was
pressed, but terminal output looks broken. Long non-ASCII strings
are cut because their lenghth is determined by counting bytes.
--
Why not go out on a limb?
Isn't that where the fruit is?
Sven Guckes
> Ok, I have installed mutt 1.5.9i from source,
> however I have built it in my home directory: ~/local/bin
> Mutt will now display the message list,
> albeit broken as described by Igorx.
>
> Mutt no longer jumps as if '?' was pressed,
> but instead says at the status bar:
> "Key is not bound. Press '?' for help.",
> so it is now behaving as if another key is pressed.
look for "push" commands in your setup!
$ grep push /etc/Muttrc ~/.muttrc
don't forget to list all "sourced" files, too!
> Also, when I run mutt on my real mailbox and try
> to delete a message it says "Mailbox is read-only."
> So is this because I compiled it my ~/local/bin
> directory? How can I fix this without being root?
folders (and mailboxes) should be owned by you.
you should be able to change their permissions.
hmm...
$ ls -ld /var/mail
?
> bb:~$ ls -l /var/spool/mail/bb
> -rw-rw---- 1 bb mail 60970846 Mar 20 22:30 /var/spool/mail/bb
> bb:~$ type mutt
> mutt is hashed (/home/bb/local/bin/mutt)
> bb:~$ mutt -v
> Mutt 1.5.9i (2005-03-13)
ok so far.. but does mutt really look
at /var/spool/mail/bb ? please check!
$ echo $MAIL
$ mutt -Q spoofile
> System: Linux 2.4.20-8 (i686) [using ncurses 5.3]
> MAILPATH="/var/mail"
hmm... is /var/mail linked to /var/spool/mail in any way?
Sven
Igorx Ivanov
Sven Guckes <use...@guckes.net> wrote:
> Look for "push" commands in your setup!
I'm sure that you will be able to reproduce the problem:
zsh> cat > /tmp/mbox
From a...@bbb.ccc Sat Mar 19 05:06:05 2005
From: =?koi8-r?B?6cLSwcfJzc/XIOsu4i4=?= <h02ck...@lara.com>
Subject: =?koi8-r?B?887BwtbFzsnFLCDU0sHO09DP0tQsINTBzc/WztEgycHM?=
^D
zsh> uxterm -e mutt -f /tmp/mbox
--
If you learn one useless thing every day, in
a single year you'll learn 365 useless things.
Paul Walker
> I'm sure that you will be able to reproduce the problem:
Does nothing for me here, running a Debian package of mutt 1.5.6. I'd be
interested just to see if the original poster (or yourself) can reproduce
the problem with all config files disabled, i.e.
mutt -n -F /dev/null -f /tmp/mbox
--
Paul
Only ssh is keeping me sane. That, and my collection of singing potatoes.
-- Red Drag Diva
Igorx Ivanov
Paul Walker <use...@blacksun.org.uk> wrote:
> Does nothing for me here
I removed one line which was required to reproduce the problem, sorry!
shell> cat > /tmp/mbox
From a...@bbb.ccc Sat Mar 19 05:06:05 2005
From: =?koi8-r?B?6cLSwcfJzc/XIOsu4i4=?= <h02ck...@lara.com>
Subject: =?koi8-r?B?887BwtbFzsnFLCDU0sHO09DP0tQsINTBzc/WztEgycHM?=
Content-type: text/plain; charset=koi8-r
^D
shell> uxterm -e mutt -f /tmp/mbox
--
You can't fall off the floor.
Sven Guckes
>>>> cat > /tmp/mbox
>>> From a...@bbb.ccc Sat Mar 19 05:06:05 2005
>>> From: =?koi8-r?B?6cLSwcfJzc/XIOsu4i4=?= <h02ck...@lara.com>
>>> Subject: =?koi8-r?B?887BwtbFzsnFLCDU0sHO09DP0tQsINTBzc/WztEgycHM?=
>>> Content-type: text/plain; charset=koi8-r
>>> ^D
>
>> $ echo $TERM
>
> xterm
> (uxterm X.Org 6.8.1(200))
uxterm != xterm
Sven
Igorx Ivanov
>> From a...@bbb.ccc Sat Mar 19 05:06:05 2005
>> From: =?koi8-r?B?6cLSwcfJzc/XIOsu4i4=?= <h02ck...@lara.com>
>> Subject: =?koi8-r?B?887BwtbFzsnFLCDU0sHO09DP0tQsINTBzc/WztEgycHM?=
>> Content-type: text/plain; charset=koi8-r
>> ^D
Sven Guckes <use...@guckes.net> wrote:
> $ echo $TERM
xterm
(uxterm X.Org 6.8.1(200))
--
Learn from other people's mistakes, you don't have time to make your own.
Sven Guckes
Alain Bench
On Saturday, March 19, 2005 at 7:46:07 PM +0000, Bernie wrote:
> Whenever the message is displayed in the message list, mutt
> immediately behaves as if the '?' has been pressed and displays the
> list of key bindings.
The help screen syndrom can have multiple causes, generally ending
in a charset discrepency between terminal, locale, and Mutt.
You use PuTTY in UTF-8 mode? So first thing to try: Pick an UTF-8
locale in output of "locale --all-locales", set it (perhaps "export
LANG=en_GB.UTF-8"), check output of "locale" and "locale charmap",
remove "set charset=" declaration from muttrc, start Mutt 1.4, and
verify typing ":reset charset;set ?charset" that the guessed charset is
"utf-8". Does it go to help screen?
OTOS I could not reproduce your symptoms here with the provided test
case... Very recently PuTTY changed something about this character
injection problem (byte 9A (SCI) does no more send back "ESC [ ? 6 c"),
so which version? Granted, there is no 9A in your test case. But once
converted to UTF-8 for display, there is a 9A in the "From:" line. Also
double check your PuTTY is really in UTF-8 mode (in config/translation).
Check cyrillic capital letter ka U+041A (coded D0 9A in UTF-8):
| From: =?koi8-r?Q?=EB=2E?= <h02ck...@lara.com>
For more infos look on mutt-dev archives the thread « mutt & xterm
character injection », and a recently closed bug on RedHat's Bugzilla.
Bye! Alain.
--
When you post a new message, beginning a new topic, use the "mail" or
"post" or "new message" functions.
When you reply or followup, use the "reply" or "followup" functions.
Do not do the one for the other, this breaks or hijacks threads.
Igorx Ivanov
>>>> From a...@bbb.ccc Sat Mar 19 05:06:05 2005
>>>> From: =?koi8-r?B?6cLSwcfJzc/XIOsu4i4=?= <h02ck...@lara.com>
>>>> Subject: =?koi8-r?B?887BwtbFzsnFLCDU0sHO09DP0tQsINTBzc/WztEgycHM?=
>>>> Content-type: text/plain; charset=koi8-r
>>>> ^D
>>>>> uxterm -e mutt -f /tmp/mbox
>> xterm
Sven Guckes <use...@guckes.net> wrote:
> uxterm != xterm
This is the default $TERM value for uxterm X.Org 6.8.1(200).
--
"I can't decide whether to commit suicide
or go bowling." -- Florence Henderson
Sven Guckes
>>>>>> cat > /tmp/mbox
>>>>> From a...@bbb.ccc Sat Mar 19 05:06:05 2005
>>>>> From: =?koi8-r?B?6cLSwcfJzc/XIOsu4i4=?= <h02ck...@lara.com>
>>>>> Subject: =?koi8-r?B?887BwtbFzsnFLCDU0sHO09DP0tQsINTBzc/WztEgycHM?=
>>>>> Content-type: text/plain; charset=koi8-r
>>>>> ^D
>>>>>> uxterm -e mutt -f /tmp/mbox
>>>> $ echo $TERM
>>> xterm
>
> Sven Guckes <use...@guckes.net> wrote:
>> uxterm != xterm
>
> This is the default $TERM value for uxterm X.Org 6.8.1(200).
so - do you get the same behaviour for a *real* xterm with TERM=xterm?
Sven
Alain Bench
On Sunday, March 20, 2005 at 12:26:26 PM +0000, Igorx Ivanov wrote:
> in uxterm X.Org 6.8.1(200) under FreeBSD 5.4-PRERELEASE Mutt does not
> behave like key '?' was pressed, but terminal output looks broken.
> Long non-ASCII strings are cut because their lenghth is determined by
> counting bytes.
You need an UTF-8 locale for correct output on an UTF-8 terminal.
Does FreeBSD have working UTF-8 locales?
Bye! Alain.
--
xtitles?
See the archives for more discussion on why this should,
like hydrogen for dirigibles, be relegated to the past.
PCC DTG on MU. © August 2004.
Alain Bench
On Tuesday, March 22, 2005 at 4:16:03 PM -0600, Peter H. Coffin wrote:
> On Tue, 22 Mar 2005 14:30:35 GMT, new...@foobar.clara.co.uk wrote:
>> Having an email trigger arbitrary commands in mutt smacks of a
>> security risk, no?
> I don't think it's mutt's problem, though. I think it's uxterm's.
PuTTY. But it doesn't report title by default. Help says:
| Section 4.6.6: Disabling remote window title querying
|
| PuTTY can optionally provide the xterm service of allowing server
| applications to find out the local window title. This feature is
| disabled by default, but you can turn it on if you really want it.
|
| NOTE that this feature is a potential security hazard. If a malicious
| application can write data to your terminal (for example, if you
| merely cat a file owned by someone else on the server machine), it can
| change your window title (unless you have disabled this as mentioned
| in section 4.6.5) and then use this service to have the new window
| title sent back to the server as if typed at the keyboard. This allows
| an attacker to fake keypresses and potentially cause your server-side
| applications to do things you didn't want. Therefore this feature is
| disabled by default, and we recommend you do not turn it on unless you
| really know what you are doing.
> window title reporting problems. Mutt isn't the only way to make that
> happen.
Even echo can, on a "vulnerable" PuTTY with unchecked option
Terminal/Features/Disable remote window title querying (SECURITY):
| $ echo -e "\e[21t"
| $ lSLRN comp.mail.mutt [7] <== I did *not* type that at prompt
The OP help screen syndrom is probably like:
| $ echo -e "\232" <== 9A control char SCI
| $ 6c <== There is an invisible "?" here
Bye! Alain.
--
Give your computer's unused idle processor cycles to a scientific goal:
The Folding@home project at <URL:http://folding.stanford.edu/>.
Alain Bench
> For more infos look [...] a recently closed bug on RedHat's Bugzilla.
Found it: That's Redhat closed bug #117524, « Mutt thrown in to help
menu by malicious subject line. Can't exit help. », at
<URL:https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=117524>.
Bye! Alain.
--
set honor_followup_to=yes in muttrc is the default value, and makes your
list replies go where the original author wanted them to go: Only to the
list, or with a private copy.
Igorx Ivanov
>>>>>> From a...@bbb.ccc Sat Mar 19 05:06:05 2005
>>>>>> From: =?koi8-r?B?6cLSwcfJzc/XIOsu4i4=?= <h02ck...@lara.com>
>>>>>> Subject: =?koi8-r?B?887BwtbFzsnFLCDU0sHO09DP0tQsINTBzc/WztEgycHM?=
>>>>>> Content-type: text/plain; charset=koi8-r
>>>>>> ^D
>>>>>>> uxterm -e mutt -f /tmp/mbox
>>>>> $ echo $TERM
>>>> xterm
>> This is the default $TERM value for uxterm X.Org 6.8.1(200).
uxterm is a shell script which runs *real* xterm
with TERM=xterm and UTF-8 options and app-defaults.
zsh> file -L =uxterm
/usr/X11R6/bin/uxterm: Bourne shell script text executable
--
We are going to have peace even if we have
to fight for it. -- Dwight D. Eisenhower
Igorx Ivanov
>> Mutt does not behave like key '?' was pressed, but terminal
>> output looks broken. Long non-ASCII strings are cut
>> because their lenghth is determined by counting bytes.
Alain Bench <albenc...@M.oreka.invalid> wrote:
> You need an UTF-8 locale for correct output on an UTF-8 terminal.
It's set by "uxterm" script.
> Does FreeBSD have
Yes.
> working UTF-8 locales?
How to check if UTF-8 locales are "working"?
--
Why am I so soft in the middle when the rest of my life is so hard?
-- Paul Simon
Alain Bench
> Paul Walker <use...@blacksun.org.uk> wrote:
>> mutt -n -F /dev/null -f /tmp/mbox
> With precompiled mutt 1.5.6 (Debian) the spam mail is listed like
> this:
>| 1 Mar 19 ????????? ?.?. ( 0K) ?????????, ?????????, ??????? ???
Fine display in a probably Latin-1 locale: Cyrillic chars don't
exist in Latin-1, thus are masked by question marks.
> On the other machine (RedHat), with mutt 1.5.9i compiled in my home
> directory, mutt says "Key is not bound. Press '?' for help.", and the
> spam mail is listed like this:
>| 1 O Mar 19 ะะฑัะฐะณะธะผะพะฒ ะ.ะ. ( 0K) ะกะฝะฐะฑะถะตะฝะธะต,
>| ััะฐะฝัะฟะพัั, ัะฐะผะพะถะฝั ะธะฐะป
Completely garbled display. This means your locale is UTF-8, fine.
But your terminal is Latin-1. Your symptoms are exactly reproducable
here in these conditions (no jump to help screen though). Use an UTF-8
terminal and you'll get no more spurious keypresses but the correct
Cyrillic characters.
Bye! Alain.
--
Mutt muttrc tip to send mails in best adapted first necessary and sufficient
charset (version for Western Latin-1/Latin-9/CP-850/CP-1252 terminal users):
set send_charset="us-ascii:iso-8859-1:iso-8859-15:windows-1252:utf-8"
Alain Bench
> Alain Bench <albenc...@M.oreka.invalid> wrote:
>> On Sunday, March 20, 2005 at 12:26:26 PM +0000, Igorx Ivanov wrote:
>>> looks broken. Long non-ASCII strings are cut because their lenghth
>>> is determined by counting bytes.
>> You need an UTF-8 locale for correct output on an UTF-8 terminal.
> It's set by "uxterm" script.
Don't hesitate to give precise information, please. What gives in
Mutt started from uxterm:
| :reset charset ; set ?charset
| !printenv | egrep "^(LANG|LC_)" | sort ; sleep 42
There is an ambiguity in thread: You don't suffer of "Key is not
bound" message, nor wrong Cyrillic characters, but *only* of index
misalignment due to early cut strings, right?
Also which version of libncursesw is Mutt using? Mutt -v shows
+HAVE_WC_FUNCS?
>> Does FreeBSD have working UTF-8 locales?
> How to check if UTF-8 locales are "working"?
Something in FreeBSD "what's new" document?
Bye! Alain.
--
Mutt muttrc tip for mailing lists: set followup_to=yes and declare the list as
- subscribe ^list@ddress$ if you are subscribed and don't want courtesy copy.
- lists ^list@ddress$ if you are not subscribed or want a courtesy copy.
Igorx Ivanov
>> It's set by "uxterm" script.
Alain Bench <albenc...@M.oreka.invalid> wrote:
> What gives in Mutt started from uxterm:
>> :reset charset ; set ?charset
charset="utf-8"
>> !printenv | egrep "^(LANG|LC_)" | sort ; sleep 42
LANG=uk_UA.UTF-8
> There is an ambiguity in thread: You don't suffer of "Key is
> not bound" message, nor wrong Cyrillic characters, but *only*
> of index misalignment due to early cut strings, right?
Looks like my mutt or libslang-1.4.9 or
/lib/libncurses.so.5 isn't ready for UTF-8.
> Also which version of libncurses is Mutt using?
> Mutt -v shows +HAVE_WC_FUNCS?
Yes.
>>> Does FreeBSD have working UTF-8 locales?
>> How to check if UTF-8 locales are "working"?
> Something in FreeBSD "what's new" document?
At least utf-8 silc-client (linked against the same
version of libncurses) works in FreeBSD uxterm.
Just tried to rebuild mutt 1.5.9 without
slang -- strings are still early cut.
--
There will always be beer cans rolling on the floor of your car when
the boss asks for a lift home from office.
Alain Bench
> What is utf-8 anyway?
The universal character set that can display all and every language.
But you don't have PuTTY well configured: Go set "UTF-8" in translation.
> My Debian system (which did not have the problem) has POSIX for the
> locale variables
Bad: "apt-get install locales" and/or "dpkg-reconfigure locales" to
generate at least en_GB, en_GB.ISO-8859-15, and en_GB.UTF-8 so they
become available in "locale --all-locales", then export LANG=en_GB.UTF-8
> bb@sirius:~$ echo $TERM
> xterm
BTW this is a widely working but suboptimal setting. You might have
better results with "putty" where available in terminfo: Go to PuTTY's
Config/Connection/Terminal-type string, and set "putty".
> mutt could itself protect against this, regardless of misconfigured
> terminal.
How? Filtering output of 9A is already done (masked by "?") where
applicable, but can't be done in an UTF-8 locale because 9A is then
necessary. Filtering output of various other escape sequences is also
already done where applicable. OTOS filtering input? But how to
distinguish spurious input from legitimate keypresses? And if we
hardcode filtering of "\e[?6c", other codes and other terminals will
send us other sequences. If we let it be configurable... Well yes, sure,
but it's already foolproofing against a first misconfiguration. Fixing
first may be better.
| bind index "\e[?6c" show-version
>>| $ echo -e "\232" <== 9A control char SCI
> I have upgraded to PuTTY 0.57 and still the above test injects 6c.
It's fixed since January 23, thus 0.57 next month should have been
clean. Seems the fix didn't go into release.
> Is there anything I can do to protect against the problem in future?
No problem when terminal's charset matches locale's charset, so
always configure perfectly all your hosts. ;-)
Bye! Alain.
--
When you want to reply to a mailing list, please avoid doing so from a
digest. This often builds incorrect references and breaks threads.
Thomas Dickey
> Looks like my mutt or libslang-1.4.9 or
> /lib/libncurses.so.5 isn't ready for UTF-8.
Redhat's libslang is patched to work more/less with UTF-8. Without the patch,
I've seen several comments that slang doesn't pay attention to locale for
the codes 128-159 (if there were a slang faq, that would be part of it).
libncurses is the 8-bit flavor (won't do UTF-8), but libncursesw would work.
The current version of ncurses is 5.4 (20040208)
There's an faq at
http://invisible-island.net/ncurses/ncurses.faq.html
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Thomas Dickey
> I smell a coincidental "window title reporting incident", or something
> similar.
I read the report as a response for the request for device attributes.
Thomas Dickey
> See http://www.securityfocus.com/bid/6945
I saw (and note that the person who wrote it didn't look closely enough
to see uxterm is a script, confused it with a program that's not been
available for several years - that's a reflection of the generally low
accuracy of the article on which it was based).
Thomas Dickey
> I find it surprising that mutt mis-behaves in this way, even if it is
> down to a problem with the terminal client. Having an email trigger
> arbitrary commands in mutt smacks of a security risk, no?
It's not "arbitrary" (the form of the DA response is pretty limited).
Thomas Dickey
>> So, you're running mutt on a particular terminal emulator and mutt's
>> behaving like you're pressing keys when it displays particular binary
>> data.
> Yes. I've now tried this from an HP-UX box and although the display
> is still broken by weird characters, mutt does not behave as if keys
> were pressed and I can delete messages without problem.
That's perhaps using old-xterm, which emulates a vt102.
Modern xterm (since 1996) emulates a vt220, which includes 8-bit equivalents
(single byte) for escape sequences that used 2 bytes in vt102.
xterm supports ANSI color, VT220 emulation and UTF-8
There's an faq at
http://invisible-island.net/xterm/xterm.faq.html
ftp://invisible-island.net/xterm/
Alain Bench
>>> mutt could itself protect against [character injection], regardless
>>> of misconfigured terminal.
> perhaps a 'Pure Ascii' option. This might work in one of two ways:
> [...] filter *all* 8-bit codes in the output, replacing them with '?'.
> Or, don't interpret the sequence. Play brain-dead wrt locales and just
> output the mail as is.
Well, both ways are already doable thru (mis)configuration. The
first with an US-Ascii locale¹, giving a clean but very suboptimal
result. The second with a forced iconv² breakage, giving both corrupted
display, and more risks to trigger character injection than in the
original situation. No go: We better avoid damaging normal operations.
(¹) Like perhaps LANG=en_GB.ASCII if you generated it, or LANG=C.
(²) Iconv is the library making the character conversions for Mutt.
> the above would cause limitations for some character sets. I guess for
> GB this would break the £ (currency symbol)
Pound sign £, currency ¤, €uro, and so on. And it could also mangle
names of strangers you attribute, and texts you quote. A misconfigured
Mutt is not polite... ;-)
> as long as I can 'borrow' an xterm I have email.
Yes: Either configure the xterm charset (to match your distant Mutt
locale), or export a locale with charset matching the terminal you don't
control. In some way for you any charset³ is ± good enough, as soon as
terminal and locale match.
(³) Well: At least Latin-1, Latin-9, or better.
> bb@duke:~/tmp$ echo -e "\232"
PuTTY 0.58 released today is finally fixed. :-)
Bye! Alain.
--
When you want to reply to a mailing list, please avoid doing so with
Microsoft Outlook. This lacks necessary references and breaks threads.