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)

x86
Linux
defect
Not set
major

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 49305

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).
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
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
> *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
QA Contact: gayatri → laurel
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).
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.
Bug still not marked as duplicate of Bug #49305
*** This bug has been marked as a duplicate of 49305 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
marking verified as duplicate
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.