Description of problem:
Mutt (running in a xterm) is thrown in to help menu by malicious
spam Subject line. I'm to exit from help menu. Forced to quit
from mutt using CTRL-C in order to recover.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Receive an email with this subject line (shown here in the
form of a hex dump):
009D310: 53 75 62 6A 65 63 74 3A 20 2D 37 36 38 2D 20 53 |Subject:
009D320: 43 4F 4F 4F 54 45 52 21 21 20 20 20 20 20 20 20 |COOOTER!!
009D330: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |
009D340: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 |
009D350: 20 20 20 20 20 20 20 20 20 34 20 20 20 20 6D 67 | 4
009D360: 6A 75 77 72 62 70 0A 44 61 74 65 3A 20 46 72 69 |juwrbp.Date:
2. Open mailbox with mutt and bring this subject line in to
Mutt goes in to it's help menu. Also note that the keys are all
messed up. Mainly that 'i' doesn't work to exit from help. CTRL-C
still works thankfully.
Mutt would somehow tolerate this nonsense (and perhaps also
cast an evil spell on the spammer).
Can you just attach the mail?
I'm working on it. I'll have to write a script or something
to extract the message from the folder and save it to a file.
Its in a large spam quarantine folder. Any "normal" way of
extracting the message prone to blowing up. And using mutt to do
it is impossible.
Also - There's no attachment option on the standard bug submission
form. What's with that? I would have put more effort into extacting
the message for attachment if there had been such an option on that
Created attachment 98324 [details]
Mail box folder containing problem email message
Ok here's the attachment. Open this folder with "mutt -f" to observe the
problem (but see below first). I think I may have misidentifed which message
was the problem in my initial report. But it's definitly one or several of
of the messages in this folder.
Now it turns out there's quite a lot more to the story. To get the error
you need a LANG environment variable mismatch between the xterm and mutt. I was
logged in remotely from another box, which is how I got the mismatch. On my
local FC1 box LANG was set to en_US.iso885915. I was logged in via ssh to a
remote RH9 box where I run mutt. LANG on the remote box was set to en_US.UTF-8.
I don't know enough about I18N to know if this should still be considered a
bug or not. Or if it is a still a bug, is it in mutt or xterm?
I don't know why lang was set to en_US.iso885915 on the FC1 box in the first
place. But this particular box is the only one around which has been upgraded
from one version of Red Hat to another and eventually to FC1. All other boxes
have received a fresh install instead of an upgrade, and they have a default
LANG of en_US.UTF-8.
I've just tried this on FC3 (apologies for the long delay); with a
en_US.iso885915 xterm and en_US.UTF-8 mutt, I can't reproduce this
with the mailbox given.
Please reopen if it still happens on FC2/FC3.