End of header "" line falsly ignored
Categories
(Thunderbird :: Untriaged, defect)
Tracking
(Not tracked)
People
(Reporter: support, Unassigned)
Details
Attachments
(1 file)
|
13.38 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:77.0) Gecko/20100101 Firefox/77.0
Steps to reproduce:
received spam and viewed email ( default settings, no js )
Actual results:
the message body was shown, without 3 lines of header which should be inside, if the email got parsed correctly.
Expected results:
3 Lines of headers should have been shown before the actual email body.
The email is attached. The spammer who sent it, was counting on it, because the MTA did not connect those headers to the "head", but refered to it as "body".
Updated•6 years ago
|
Comment 1•6 years ago
|
||
(In reply to support from comment #0)
Created attachment 9161858 [details]
EXAMPLE SPAM
Expected results:
3 Lines of headers should have been shown before the actual email body.
Do you mean the 3 Lines after the Subject header and before the first MIME-part?
| Subject: =?UTF-8?B?V2FydGVuIFNpZSBuaWNodCBiaXMgenVyIGxldHp0ZW4gTWludXRlLi4uIE01R0Iy?=
|
| Return-Path: <bounce-9dxh-5989534790104693126@createmorecode.com>
| x-mail: YW14pY5m7989iyZ0B86f3ZWIuZGU
| Delivered-To: ORIGINALRECIPIENT
|
| This is a multi-part message in MIME format.
| --kogkcijkuw0dyc8qnj5srjsgu1yxj5j5ea08v5p7dfk8x4bjz1yjzt4sczpmxt5tg6v044
If so: no, this area is called "preamble" and must be ignored by any client.
See:
https://www.rfc-editor.org/rfc/rfc2046#section-5.1.1
| There appears to be room for additional information prior to the
| first boundary delimiter line and following the final boundary
| delimiter line. These areas should generally be left blank, and
| implementations must ignore anything that appears before the first
| boundary delimiter line or after the last one.
|
| NOTE: These "preamble" and "epilogue" areas are generally not used
| [...], since such notes will be ignored by
| MIME-compliant software.
Description
•