Headers in Message Saved As Text should resemble RFC 822 spec



18 years ago
2 years ago


(Reporter: goodmanj, Unassigned)


Firefox Tracking Flags

(Not tracked)




18 years ago
Reproducing the bug:
1. Select a message in MailNews.  
2. Right-click on the message, and choose "Save As..." from the pop-up menu.  
3. Save as "foo.txt".
4. View file "foo.txt".

The headers in foo.txt look like this:
Test message
"J Q Public" <jqpublic@aol.com>
Sun, 26 Aug 2001 12:07:48 -1000
"Mozilla Fan" <mozfan@mit.edu>
Expected results:
RFC 822 wants the header field body to be on the same line as the header field
name, like this:
Subject: Test message
From: "J Q Public" <jqpublic@aol.com>
Date: Sun, 26 Aug 2001 12:07:48 -1000
To: "Mozilla Fan" <mozfan@mit.edu>
-------------Following this spec looks nicer, is easier to read, takes up less
space, is consistent with other mail agents, and allows messages to be parsed
easily by scripts and other tools.
The file doesn't need to follow RFC822 exactly -- after all, it's not intended
to be an "internet text message" -- but it would be nice if it was close.

Mozilla build: 2001080312
Reproducibility: always

Comment 1

17 years ago
Maybe related: bug 92183

Comment 2

17 years ago
Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 3

17 years ago
Reopening for Ksosez.
Resolution: WORKSFORME → ---

Comment 4

17 years ago
Ever confirmed: true

Comment 5

15 years ago
Thunderbird 0.7 on Windows 98 SE still has the same behaviour when saving
messages as .txt files.
Product: Browser → Seamonkey


14 years ago
Assignee: sspitzer → mail

Comment 6

13 years ago
At the time this bug was opened, I don't know if the Save As filepicker distinguished between Mail Files, HTML Files, Text Files, or even if it saved 
as a .EML file at all.  The .EML file does contain the headers -- all headers 
-- as requested here, but won't decode quoted-printable/base64 bodies or leave off the attachments.

On the other hand, "As Text" has issues with character encodings (bug 112069, bug 230042, bug 261923, bug 269812).

"As HTML" puts the headers in a table form, but the HTML is often malformed
(bug 74424, bug 164154, bug 227872, bug 221348).
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Backend
OS: Linux → All
Product: Mozilla Application Suite → Core
QA Contact: esther → backend
Hardware: PC → All
Summary: Message "Save As..." should resemble RFC 822 header spec → Headers in Message Saved As Text should resemble RFC 822 spec


13 years ago
Product: Core → MailNews Core

Comment 7

3 years ago
Windows 7 Ultimate SP1
Thunderbird 45.0

This is still a problem.  When I save an E-mail message as message.txt, x0D0A (carriage return, line feed) is added after each colon (:).  I get this while running Thunderbird in Safe Mode.  

Note:  When reporting spam or an abusive message to an ISP, the ISP wants to see the message's header section as it actually was received, without alterations.  The same is true when reporting attempted Internet fraud or other criminal activity to law enforcement.  Thus, this is not a "Minor" bug.
Severity: minor → normal

Comment 8

3 years ago
If your ISP wants to see all the message headers as they were received, you shouldn't save the message as text. You should save it as a .eml so that everything is preserved.

That doesn't mean that this bug shouldn't be fixed (I think it's worth fixing), but I don't think reporting spam is a valid use case for this bug.

Comment 9

2 years ago
Windows 7 Ultimate SP 1 (x64)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0

I have been viewing and saving E-mail message sources as .txt (plain text) files.  I just now did the same with a newsgroup message source.  It appears that this bug is fixed.  It works for me as cited in the Description under "Expected results".  

I suggest someone else try this -- possibly with a different operating system -- before closing this bug report.
You need to log in before you can comment on or make changes to this bug.