Closed
Bug 138252
Opened 22 years ago
Closed 22 years ago
View | All headers -> All but one of many identically-named headers is ignored
Categories
(MailNews Core :: Backend, defect)
Tracking
(Not tracked)
People
(Reporter: tom-bugzilla.mozilla.org, Assigned: mscott)
References
()
Details
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020408
BuildID: 2002040814
When processing an email's headers (possibly the same with news headers), mail
ignores all but one header from each identically-named set of headers. For
example, MTA's often insert Received: or Delivered-To: headers, one each per
delivery hop. Since most emails take more than one hop to reach their ultimate
destinations, there are often more than one instance of the Received: and
Delivered-To: headers. *All* of the instances are useful for mail filtering,
but mail sees only *one* of each.
For example, consider this header pulled from a recent spam I received:
From - Thu Apr 18 14:18:58 2002
X-UIDL: 1019117982.26105.mailexchanger.mydomain.com
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Return-Path: <user@mailexchanger.mydomain.com>
Delivered-To: user-confirm@mailexchanger.mydomain.com
Received: (qmail 26096 invoked by alias); 18 Apr 2002 08:19:37 -0000
Delivered-To: user-confirm@mydomain.com
Received: (qmail 26088 invoked by uid 500); 18 Apr 2002 08:19:26 -0000
Received: (qmail 26043 invoked by alias); 18 Apr 2002 08:17:52 -0000
Delivered-To: useralias@mydomain.com
Received: (qmail 26037 invoked from network); 18 Apr 2002 08:17:46 -0000
Received: from vfe1.seed.net.tw (HELO vm2.seed.net.tw) (139.175.252.111)
by mailexchanger.mydomain.com with SMTP; 18 Apr 2002 08:17:46 -0000
Received: from www.tmc.com.tw ([211.21.186.21] helo=webhip01)
by vm2.seed.net.tw with smtp (Seednet Mail Server v2.316b)
id 16y568-0007v8-00
for useralias@mydomain.com; Thu, 18 Apr 2002 14:08:48 +0800
To: "'useralias@mydomain.com'" <useralias@mydomain.com>
From: TICE Service <sales@tice.com.tw>
Subject: TICE Pricing on 2002-4-18
Date: Thu, 18 Apr 2002 14:07:53 +0800
Message-Id: <37364.588808310181800.1211708@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Reading bottom-to-top, you can follow the Delivered-To headers to see the path
through which the email is delivered. Likewise I can follow the Received
headers to see which MTAs handled the delivery. All of the Delivered-To and
Received headers are significant and should be preserved.
However, mozilla sees only one instance of each. Mozilla shows only one
Delivered-To and one Received header when displaying the email with "view all
headers" on. Likewise, when filtering, only one instance of each is used.
Without having examined the source, my hunch is that mozilla reads the headers
into a hash or other key-lookup database, using a "last-one-in-wins" policy to
handle cases where more than one of each type of header exists.
Whatever the underlying implementation, mozilla throws away important header
information that is essential for filtering as well as spam detection and
processing.
Reproducible: Always
Steps to Reproduce:
1. Create an email by hand that contains multiple instances of
one kind of header (e.g., Received or Delivered-To), each
having a unique value.
2. Send the email to yourself.
3. Receive the email with Mozilla.
4. Look at the email with "view all headers" on.
Actual Results: Only one insance of the header appears.
Expected Results: All instances of the header appears.
The same goes for filtering: You can create filters on your multiple-instance
header, one for each of the unique values you used. When the email is received,
all of the filters should be triggered, but only one is (the one that matches
the instance of the header that mozilla kept).
Comment 1•22 years ago
|
||
not a mail database issue (those headers don't go in the mail database). I don't
know where view all headers gets its header info (but not from the mail
database, obviously). I would think the filter code should work first of all; we
can deal with view all headers second.
Assignee: bienvenu → naving
Component: Mail Database → Mail Back End
Comment 3•22 years ago
|
||
> *All* of the instances are useful for mail filtering,
>but mail sees only *one* of each.
*All* instances of such headers are used for filtering. I just set up a filters
on Received and was able to filter based on what was in the last Received:
header - worksforme.
We don't display all headers for View | All Headers - over to mscott
Assignee: naving → mscott
Summary: All but one of many identically-named headers is ignored → View | All headers -> All but one of many identically-named headers is ignored
Updated•22 years ago
|
QA Contact: gayatri → laurel
Comment 4•22 years ago
|
||
This look s a whole lot like the very ancient and still unfixed Bug 49305 some
year and a half old now. I suggest marking it a duplicate, updating the search
text (as I mentioned in the report), and upping the severity (also as I reasoned
in the other report).
Comment 5•22 years ago
|
||
View all headers should mean exactly that whether filtering is impacted or not.
Whatever mail-reader you use when you switch into viewing all headers then you
make the assumption that what you see is exactly what was in the message source
Using "view message source" as a workaround is all very well but if the UI entry
says "all headers" then it should either really give you all the headers or be
relabelled to reflect what it actually does. Reading through the original report
and comment #3 I'm guessing (since I dont have a source tree here to search and
cant find it in my inept CVS tree browsing ) that this is indeed a
last-entry-wins hash table but if filters work ok on multiple instance headers
I'd bet the hash table is built when constructing the ui headers widget and that
widget needs tweaking to handle multiple instances of the same header.
Comment 6•22 years ago
|
||
Bug still not marked as duplicate of Bug #49305
Comment 7•22 years ago
|
||
*** This bug has been marked as a duplicate of 49305 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•