Closed Bug 1272195 Opened 8 years ago Closed 8 years ago

Cannot Forward Send Received E-mail Message With Full Headers

Categories

(MailNews Core :: Composition, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: david, Unassigned)

Details

Windows 7 Ultimate SP1
Thunderbird 45.0

When reporting spam or E-mail abuse, ISPs want the complete, unaltered headers of the offensive message.  When reporting attempted Internet fraud or other criminal actions, law enforcement also wants unaltered headers of the offensive message.  Thunderbird does not support this.  

I have tried several methods, all while running Thunderbird in Safe Mode.  

1.  I have a template that explains why I am sending a copy of an offensive message.  I can alter the template as needed.  I select the template, right-click, and select "Edit As New Message".  I then select the offensive message, select [View > Message Source].  On the "Source of" window, I right-click and select "Select All" and then "Copy".  I paste the result into the new message.  It all looks okay; but when I send it, a greater-than symbol (>) is inserted at the beginning of the first line of the pasted offensive message.  The headers no longer reflect exactly what I received.  

2.  I requested [View > Headers > All].  I selected the offensive message and attempted to forward it inline.  The first line (here from an actual spam message) in the message source was:
         From - Wed May 11 07:45:57 2016
The inline forwarded message, however, had:
         From: 	57 2016 <>
Again, the headers no longer reflect exactly what I received.  

3.  I requested [View > Headers > All].  I selected a message and attempted to forward it as an attachment.  The resulting attachment failed to include many of the header fields.  Especially noted was the lack of the "Received" header fields.  

4.  Saving the offensive message as a plain-text file (instead of an .eml file) to attach to my outgoing message is afflicted by bug #97073.
I honestly doubt we'd want to add UI and code for such a rare need that is really a "debug" situation, that average users will never use. But perhaps Blake will have different perspective. (I didn't find any similar bug that is open or wontfix)

The workaround is View Source, and from there either save it as a file or copy the text into compose.
Severity: normal → minor
Flags: needinfo?(bwinton)
Summary: Cannot Send Received E-mail Message With Unaltered Headers → Cannot Forward Send Received E-mail Message With Full Headers
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #1)
> The workaround is View Source, and from there either save it as a file or
> copy the text into compose.  

That is my case #1, in which 
       From - Thu May 12 07:25:26 2016
becomes
       >From - Thu May 12 07:25:26 2016
Note that > symbol does NOT appear in the compose window.  It is inserted after I request Send.
> when I send it, a greater-than symbol (>) is inserted at the beginning of the first line of the 
> pasted offensive message.  The headers no longer reflect exactly what I received.  

I can't reproduce this.  You might attach a testcase file

Even if one can reproduce, I don't see why this is a big problem.  ">" is just an escape from the message store and trivial to remove after pasting.
Turns out the ">" before the "From" is one of those terrible ancient bits of Internet history, and yeah, we don't really have a way to work around it, since it can get added by any mail server along the route to its destination…

I think I mostly agree that it doesn't warrant UI in the main product, but does sound like a good idea for an add-on…
Flags: needinfo?(bwinton)
The problem is NOT with "From - Wed May 11 07:45:57 2016" being the first line (my case #1).  The problem with any line beginning with "From", even when that is merely the first word of a sentence.  

I am closing this and replacing it with bug #1272369, which describes this problem more correctly.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.