* bug#4593: 23.1; RMAIL bug regarding Message not valid RFC2822 message
@ 2009-09-30 0:51 ` Lane A. Hemaspaandra
2009-10-02 7:01 ` Glenn Morris
2009-10-03 2:15 ` bug#4593: marked as done (23.1; RMAIL bug regarding Message not valid RFC2822 message) Emacs bug Tracking System
0 siblings, 2 replies; 3+ messages in thread
From: Lane A. Hemaspaandra @ 2009-09-30 0:51 UTC (permalink / raw
To: bug-gnu-emacs
I've since the upgrade to emacs23 been having a problem that when I read
a mailfile sometimes it says Message is not a valid RFC2822 message
and I end up in a deeply corrupted state: one can move up and down
in the header buffer, but the message window doesn't change messages,
and if one says the file one gets a somewhat mbox-like file that
is not a valid mbox file that has the content of just 3 or 4 of
the, say, hundred emails that had been originally in the mailfile.
I finally found a set of files on which I can precisely reproduce the
problem. So if I do this:
(each "read" means i ran rmail-input on the named file)
read ~/junk
q
read ~/=shortCutToOldEmail/WESTFIELD
(at this point it says: Replacing BABYL format with mbox format...done)
q
read ~/WESTFIELD
q
read ~/junk
q
read ~/=shortCutToOldEmail/WESTFIELD
then bang, it says:
Message is not a valid RFC2822 message
and shows as the first line of the screen the cryptic text beween the ===
lines
===
_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, TO_NO_NAME 0, __CP_URI_IN_BODY 0, __FRAUD_419_ANTIABUSE 0, __FRAUD_419_CONTACT_NAME 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __SANE_MSGID 0, __STOCK_PHRASE_24 0, __TO_MALFORMED_2 0'
X-RMAIL-ATTRIBUTES: --------
This is a confirmation that your Westfield order was successfully received and
[and so on for the rest of the message]
===
and when i do this with set-variable debug-on-error set to true, that
gives this at this point:
===
Debugger entered--Lisp error: (error "Message is not a valid RFC2822 message")
signal(error ("Message is not a valid RFC2822 message"))
error("Message is not a valid RFC2822 message")
rmail-error-bad-format()
rmail-get-header-1("X-RMAIL-ATTRIBUTES")
apply(rmail-get-header-1 "X-RMAIL-ATTRIBUTES")
rmail-apply-in-message(1 rmail-get-header-1 "X-RMAIL-ATTRIBUTES")
rmail-get-header("X-RMAIL-ATTRIBUTES" 1)
rmail-message-attr-p(1 "......U")
rmail-first-unseen-message()
byte-code("^Hq\210 \204\f^@\304\305 !\210\n\203^S^@\306 \210\307 \210^K\203^^^@\310\311!\210\304\207" [mail-buf msg-shown rmail-display-summary run-mail-hook rmail-show-message rmail-first-unseen-message rmail-summary rmail-construct-io-menu run-hooks rmail-mode-hook] 2)
rmail("~/=shortCutToOldEmail/WESTFIELD")
rmail-input("~/=shortCutToOldEmail/WESTFIELD")
call-interactively(rmail-input t nil)
execute-extended-command(nil)
call-interactively(execute-extended-command nil nil)
===
Note by the way that it does this NOT the first time in that session
that it rmail-input'ed the file ~/=shortCutToOldEmail/WESTFIELD
but rather on the second, and at a time when it had another
buffer WESTFIELD<2> of almost the same name. (variations on
my sequence that course this seem not to cause the bug. i have
no idea why; i'm sorry.)
and if one then types "h" for header mode, it says:
Message 1 is not a valid RFC2822 message
and if one saves the file one ends up with a file that is much smaller
than the (Babyl) what one started with---wildly shorter. and that new
file itself is sort-of-mbox-format but not into a valid mbox format.
It started at size 978312 and it ends up as size 41363. (note to
myself: i have saved this file under the name
=shortCutToOldEmail/junksample.)
I have saved away the files:
~/junk
~/=shortCutToOldEmail/WESTFIELD
~/WESTFIELD
~/=shortCutToOldEmail/junksample
so that I have copies of all the files involved, in case that would
be helpful.
As a final comment, let me mention a few things. When the above happens,
~/=shortCutToOldEmail/WESTFIELD
starts in Babyl format. Also, I did the above with NO .emacs file.
When I have in place my .emacs file, which does set some variables
such as
(setq rmail-display-summary t) ; always display summary
I get, as above, an error the second time I read
~/=shortCutToOldEmail/WESTFIELD
but when I then hit "h" for header mode, I get a different
behavior than above, namely, it says in the message line
on the bottom of the screen:
Error in post-command-hook: (error Message is not a valid RFC2822 message)
and what it displays on the screen is a message but starting with
the following lines (except without the leading ">" marks), and yes,
the first and third are identical:
===
>X-RMAIL-ATTRIBUTES: --------
>From Notify@westfieldcomics.com Tue Jul 14 20:15:00 2009
>X-RMAIL-ATTRIBUTES: --------
>X-Coding-System: undecided-unix
>Return-Path: <Notify@westfieldcomics.com>
>X-Spam-Checker-Version: SpamAssassin 3.2.5-cs.rochester.edu_001 (2008-06-10)
> on slate.cs.rochester.edu
>X-Spam-Level:
>X-Spam-Status: No, score=-13.3 required=5.0 tests=AWL,BAYES_60,
> USER_IN_WHITELIST autolearn=no version=3.2.5-cs.rochester.edu_001
>X-Spam-Pyzor:
>X-Spam-Report:
> * -15 USER_IN_WHITELIST From: address is in the user's white-list
> * 1.0 BAYES_60 BODY: Bayesian spam probability is 60 to 80%
> * [score: 0.6241]
> * 0.7 AWL AWL: From: address is in the auto white-list
===
I've been using RMAIL for many, many years, but I don't understand
well how emacs/rmail actually work. But I'll be very happy to do my
best to provide any additional info or run any tests that might help
diagnose this. (And my apologies if it is some problem due to me.
But the mailfile it is choking on is a typical babyl file. And I
have this problem repeatedly, with other files too, but not too
often.)
Thank you very, very much.
Sincerely,
Lane
In GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.6)
of 2009-09-22 on x86-6.fedora.phx.redhat.com
configured using `configure '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xft' '--with-xpm' '--with-x-toolkit=gtk' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-bu
ffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: C
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: RMAIL
Minor modes in effect:
shell-dirtrack-mode: t
tooltip-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
ESC [ > 0 ; 2 4 2 ; 0 c ESC x r m a i l - i n SPC RET
j u n k RET y q ESC x r m a i l - i n SPC RET = s h
TAB W E S T F TAB RET q ESC x r m a i l - i n SPC RET
W E S T F SPC DEL TAB RET q ESC x r m a i l - i n SPC
RET j u n k RET q ESC x r m a i l - i n SPC RET = s
h TAB W E S T F SPC DEL TAB RET ESC x r e p o r t -
e m a c s - b u g RET
Recent messages:
(No changes need to be saved)
Wrote /tmp/rmail4600dlq
Writing messages to /tmp/rmail4600FDD...done
Replacing BABYL format with mbox format...
Marking buffer unmodified to avoid rewriting Babyl file as mbox file
Counting messages...done
Replacing BABYL format with mbox format...done
(No changes need to be saved)
Counting messages...done
(No changes need to be saved) [2 times]
rmail-error-bad-format: Message is not a valid RFC2822 message
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#4593: 23.1; RMAIL bug regarding Message not valid RFC2822 message
2009-09-30 0:51 ` bug#4593: 23.1; RMAIL bug regarding Message not valid RFC2822 message Lane A. Hemaspaandra
@ 2009-10-02 7:01 ` Glenn Morris
2009-10-03 2:15 ` bug#4593: marked as done (23.1; RMAIL bug regarding Message not valid RFC2822 message) Emacs bug Tracking System
1 sibling, 0 replies; 3+ messages in thread
From: Glenn Morris @ 2009-10-02 7:01 UTC (permalink / raw
To: Lane A. Hemaspaandra; +Cc: 4593
"Lane A. Hemaspaandra" wrote:
> problem. So if I do this:
>
> (each "read" means i ran rmail-input on the named file)
> read ~/junk
> q
> read ~/=shortCutToOldEmail/WESTFIELD
> (at this point it says: Replacing BABYL format with mbox format...done)
> q
> read ~/WESTFIELD
> q
> read ~/junk
> q
> read ~/=shortCutToOldEmail/WESTFIELD
>
> then bang, it says:
> Message is not a valid RFC2822 message
If you don't mind making them public, can you tar up / zip those
messages and send them to 4593@emacsbugs.donarmstrong.com? Or if that
is not acceptable, then just to me? Thanks.
> (variations on my sequence that course this seem not to cause the
> bug. i have no idea why; i'm sorry.)
[...]
> so that I have copies of all the files involved, in case that would
> be helpful.
^ permalink raw reply [flat|nested] 3+ messages in thread
* bug#4593: marked as done (23.1; RMAIL bug regarding Message not valid RFC2822 message)
2009-09-30 0:51 ` bug#4593: 23.1; RMAIL bug regarding Message not valid RFC2822 message Lane A. Hemaspaandra
2009-10-02 7:01 ` Glenn Morris
@ 2009-10-03 2:15 ` Emacs bug Tracking System
1 sibling, 0 replies; 3+ messages in thread
From: Emacs bug Tracking System @ 2009-10-03 2:15 UTC (permalink / raw
To: Glenn Morris
[-- Attachment #1: Type: text/plain, Size: 918 bytes --]
Your message dated Fri, 02 Oct 2009 22:09:58 -0400
with message-id <vkab095itl.fsf@fencepost.gnu.org>
and subject line Re: bug#4593: 23.1; RMAIL bug regarding Message not valid RFC2822 message
has caused the Emacs bug report #4593,
regarding 23.1; RMAIL bug regarding Message not valid RFC2822 message
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@emacsbugs.donarmstrong.com
immediately.)
--
4593: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4593
Emacs Bug Tracking System
Contact owner@emacsbugs.donarmstrong.com with problems
[-- Attachment #2: Type: message/rfc822, Size: 10349 bytes --]
From: "Lane A. Hemaspaandra" <lane@cs.rochester.edu>
To: bug-gnu-emacs@gnu.org
Subject: 23.1; RMAIL bug regarding Message not valid RFC2822 message
Date: Tue, 29 Sep 2009 20:51:55 -0400
Message-ID: <200909300051.n8U0pt6K005244@e19.cs.rochester.edu>
I've since the upgrade to emacs23 been having a problem that when I read
a mailfile sometimes it says Message is not a valid RFC2822 message
and I end up in a deeply corrupted state: one can move up and down
in the header buffer, but the message window doesn't change messages,
and if one says the file one gets a somewhat mbox-like file that
is not a valid mbox file that has the content of just 3 or 4 of
the, say, hundred emails that had been originally in the mailfile.
I finally found a set of files on which I can precisely reproduce the
problem. So if I do this:
(each "read" means i ran rmail-input on the named file)
read ~/junk
q
read ~/=shortCutToOldEmail/WESTFIELD
(at this point it says: Replacing BABYL format with mbox format...done)
q
read ~/WESTFIELD
q
read ~/junk
q
read ~/=shortCutToOldEmail/WESTFIELD
then bang, it says:
Message is not a valid RFC2822 message
and shows as the first line of the screen the cryptic text beween the ===
lines
===
_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, TO_NO_NAME 0, __CP_URI_IN_BODY 0, __FRAUD_419_ANTIABUSE 0, __FRAUD_419_CONTACT_NAME 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __SANE_MSGID 0, __STOCK_PHRASE_24 0, __TO_MALFORMED_2 0'
X-RMAIL-ATTRIBUTES: --------
This is a confirmation that your Westfield order was successfully received and
[and so on for the rest of the message]
===
and when i do this with set-variable debug-on-error set to true, that
gives this at this point:
===
Debugger entered--Lisp error: (error "Message is not a valid RFC2822 message")
signal(error ("Message is not a valid RFC2822 message"))
error("Message is not a valid RFC2822 message")
rmail-error-bad-format()
rmail-get-header-1("X-RMAIL-ATTRIBUTES")
apply(rmail-get-header-1 "X-RMAIL-ATTRIBUTES")
rmail-apply-in-message(1 rmail-get-header-1 "X-RMAIL-ATTRIBUTES")
rmail-get-header("X-RMAIL-ATTRIBUTES" 1)
rmail-message-attr-p(1 "......U")
rmail-first-unseen-message()
byte-code("^Hq\210 \204\f^@\304\305 !\210\n\203^S^@\306 \210\307 \210^K\203^^^@\310\311!\210\304\207" [mail-buf msg-shown rmail-display-summary run-mail-hook rmail-show-message rmail-first-unseen-message rmail-summary rmail-construct-io-menu run-hooks rmail-mode-hook] 2)
rmail("~/=shortCutToOldEmail/WESTFIELD")
rmail-input("~/=shortCutToOldEmail/WESTFIELD")
call-interactively(rmail-input t nil)
execute-extended-command(nil)
call-interactively(execute-extended-command nil nil)
===
Note by the way that it does this NOT the first time in that session
that it rmail-input'ed the file ~/=shortCutToOldEmail/WESTFIELD
but rather on the second, and at a time when it had another
buffer WESTFIELD<2> of almost the same name. (variations on
my sequence that course this seem not to cause the bug. i have
no idea why; i'm sorry.)
and if one then types "h" for header mode, it says:
Message 1 is not a valid RFC2822 message
and if one saves the file one ends up with a file that is much smaller
than the (Babyl) what one started with---wildly shorter. and that new
file itself is sort-of-mbox-format but not into a valid mbox format.
It started at size 978312 and it ends up as size 41363. (note to
myself: i have saved this file under the name
=shortCutToOldEmail/junksample.)
I have saved away the files:
~/junk
~/=shortCutToOldEmail/WESTFIELD
~/WESTFIELD
~/=shortCutToOldEmail/junksample
so that I have copies of all the files involved, in case that would
be helpful.
As a final comment, let me mention a few things. When the above happens,
~/=shortCutToOldEmail/WESTFIELD
starts in Babyl format. Also, I did the above with NO .emacs file.
When I have in place my .emacs file, which does set some variables
such as
(setq rmail-display-summary t) ; always display summary
I get, as above, an error the second time I read
~/=shortCutToOldEmail/WESTFIELD
but when I then hit "h" for header mode, I get a different
behavior than above, namely, it says in the message line
on the bottom of the screen:
Error in post-command-hook: (error Message is not a valid RFC2822 message)
and what it displays on the screen is a message but starting with
the following lines (except without the leading ">" marks), and yes,
the first and third are identical:
===
>X-RMAIL-ATTRIBUTES: --------
>From Notify@westfieldcomics.com Tue Jul 14 20:15:00 2009
>X-RMAIL-ATTRIBUTES: --------
>X-Coding-System: undecided-unix
>Return-Path: <Notify@westfieldcomics.com>
>X-Spam-Checker-Version: SpamAssassin 3.2.5-cs.rochester.edu_001 (2008-06-10)
> on slate.cs.rochester.edu
>X-Spam-Level:
>X-Spam-Status: No, score=-13.3 required=5.0 tests=AWL,BAYES_60,
> USER_IN_WHITELIST autolearn=no version=3.2.5-cs.rochester.edu_001
>X-Spam-Pyzor:
>X-Spam-Report:
> * -15 USER_IN_WHITELIST From: address is in the user's white-list
> * 1.0 BAYES_60 BODY: Bayesian spam probability is 60 to 80%
> * [score: 0.6241]
> * 0.7 AWL AWL: From: address is in the auto white-list
===
I've been using RMAIL for many, many years, but I don't understand
well how emacs/rmail actually work. But I'll be very happy to do my
best to provide any additional info or run any tests that might help
diagnose this. (And my apologies if it is some problem due to me.
But the mailfile it is choking on is a typical babyl file. And I
have this problem repeatedly, with other files too, but not too
often.)
Thank you very, very much.
Sincerely,
Lane
In GNU Emacs 23.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.16.6)
of 2009-09-22 on x86-6.fedora.phx.redhat.com
configured using `configure '--build=i386-redhat-linux-gnu' '--host=i386-redhat-linux-gnu' '--target=i586-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-dbus' '--with-gif' '--with-jpeg' '--with-png' '--with-rsvg' '--with-tiff' '--with-xft' '--with-xpm' '--with-x-toolkit=gtk' 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu' 'target_alias=i586-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-bu
ffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: C
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_US.UTF-8
value of $XMODIFIERS: nil
locale-coding-system: utf-8-unix
default-enable-multibyte-characters: t
Major mode: RMAIL
Minor modes in effect:
shell-dirtrack-mode: t
tooltip-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
global-auto-composition-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent input:
ESC [ > 0 ; 2 4 2 ; 0 c ESC x r m a i l - i n SPC RET
j u n k RET y q ESC x r m a i l - i n SPC RET = s h
TAB W E S T F TAB RET q ESC x r m a i l - i n SPC RET
W E S T F SPC DEL TAB RET q ESC x r m a i l - i n SPC
RET j u n k RET q ESC x r m a i l - i n SPC RET = s
h TAB W E S T F SPC DEL TAB RET ESC x r e p o r t -
e m a c s - b u g RET
Recent messages:
(No changes need to be saved)
Wrote /tmp/rmail4600dlq
Writing messages to /tmp/rmail4600FDD...done
Replacing BABYL format with mbox format...
Marking buffer unmodified to avoid rewriting Babyl file as mbox file
Counting messages...done
Replacing BABYL format with mbox format...done
(No changes need to be saved)
Counting messages...done
(No changes need to be saved) [2 times]
rmail-error-bad-format: Message is not a valid RFC2822 message
[-- Attachment #3: Type: message/rfc822, Size: 2120 bytes --]
From: Glenn Morris <rgm@gnu.org>
To: 4593-done@emacsbugs.donarmstrong.com
Subject: Re: bug#4593: 23.1; RMAIL bug regarding Message not valid RFC2822 message
Date: Fri, 02 Oct 2009 22:09:58 -0400
Message-ID: <vkab095itl.fsf@fencepost.gnu.org>
Thank you for the example mails (received off list, now deleted).
As it turns out, this problem can be reproduced simply by trying to
visit any two rmail files with the same basename in different
directories, eg:
M-x rmail-input ~/directory/RMAIL
M-x rmail-input ~/RMAIL
M-x rmail-input ~/directory/RMAIL
I believe it is now fixed by this change:
* mail/rmail.el (rmail-generate-viewer-buffer): Be more careful about
reusing existing buffers, in case we happen to visit two files
with the same basename. (Bug#4593)
http://cvs.savannah.gnu.org/viewvc/emacs/lisp/mail/rmail.el?root=emacs&r1=1.552&r2=1.553&pathrev=MAIN
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-10-03 2:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <vkab095itl.fsf@fencepost.gnu.org>
2009-09-30 0:51 ` bug#4593: 23.1; RMAIL bug regarding Message not valid RFC2822 message Lane A. Hemaspaandra
2009-10-02 7:01 ` Glenn Morris
2009-10-03 2:15 ` bug#4593: marked as done (23.1; RMAIL bug regarding Message not valid RFC2822 message) Emacs bug Tracking System
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.