Closed Bug 172104 Opened 17 years ago Closed 10 years ago

multiple subject headers causes different subject in thread pane than preview pane, should use first subject

Categories

(MailNews Core :: Backend, defect, major)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 3.1a1

People

(Reporter: juggy, Assigned: lusian)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [good first bug][impacts gloda])

Attachments

(2 files, 2 obsolete files)

I just received an email in which - for whatever reason - two subject lines
existed. The first was shown when the mail was selected (in the subject field),
the second (=last?) in the message-list-window and mozillanews-title display.
We have seen it here, too.
Still occurs with Mozilla 1.3 and 1.4b-0516.  This is closely related to bug 
156588.
Status: UNCONFIRMED → NEW
Ever confirmed: true
yes, the msg parsing code used to generate the db header will use the last
subject. We could easily make it use the first subject.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Greetings . . .

I noted the same problem when I received a "phising" email purportedly from PayPal.

The "Subject" line displayed in the Thunderbird InBox is . . .

     Important information PayPal customers. confirmation code 9832-JGQKY

. . . but the "Subject" line that is displayed when the e-mail is viewed is:

     -- Spam -- PayPal Security Request confirmation code  421-RRO

My ISP, COX Communications, inserted the "-- Spam -- " prefix in the latter Subject for know spammers, but somehow this is not the Subject line that is presented to my Thunderbird client, which has a Filter designed to move such incoming e-mail to the "Junk" folder.

Are MULTIPLE "Subject" lines allowed in an e-mail message?  UGH!

Thanks for your attention.

George
David in comment #4:
> msg parsing code used to generate the db header will use the last
> subject. We could easily make it use the first subject.

Is there a RFC that requires use of the first line or last line?

spamassassin only tags the FIRST subject line, thus filtering of [SPAM] via suite and thunderbird is defeated (as noted in bug 310189)
OS: Windows 2000 → All
QA Contact: olgam
Hardware: PC → All
> Is there a RFC that requires use of the first line or last line?

Not as such, but RfC 2822 limits the number of subject headers to 0-1, while RfC 822 just says:
            This specification permits multiple  occurrences  of  most
            fields.   Except  as  noted,  their  interpretation is not
            specified here, and their use is discouraged.
and there's no special remark about the subject header there.
hmm, which field is being used by junk filtering, the faulty(?) non-first subject shown in the thread pane?

RFC 2822 of course obsoletes rfc 822. I don't know what other spam packages do, but spamassassin flags only the FIRST subject field

related SA bugs: 
 http://issues.apache.org/SpamAssassin/show_bug.cgi?id=1239 *
 http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4927 

* SA v3.17 is not removing multiple subject lines, contrary to SAbug 1239 "In 2.50, multiple subjects are removed and replaced with a single rewritten one
(I believe the first subject)"
Blocks: 310189
Summary: multiple subject headers in one mail causes different subject display → multiple subject headers in one mail causes different subject display in thread pane, defeats filtering
David in comment #4:
> yes, the msg parsing code used to generate the db header will use the last
> subject. We could easily make it use the first subject.

David, sounds like that's the way to go. Besides it should be consistent, no?

I filed SA bug - http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5181
- SA outputs two subjects, the first subject with [SPAM] and the second subject the untouched original.
example where it's better to use first subject.  filters and thread pane are using subject 2. But message preview pane shows subject 1.


-- after SA processsing - SA has tagged subject 1 --

To: info@playandwin.co.uk
Subject: [SPAM] A few drops a day is all thats needed to create a leaner fitter you
From: "shut@playandwin.co.uk <to6332"@playandwin.co.uk
Content-Transfer-Encoding: 7bit
Content-Type: multipart/mixed; boundary="----------=_460125D6.BAF3E3EA"
Subject: A few drops a day is all thats needed to create a leaner fitter you
Message-Id: <20070321123218.489831B4149@srv12.komogvind.dk>
Date: Wed, 21 Mar 2007 13:32:18 +0100 (CET)
X-Virus-Scanned: ClamAV 0.90.1/2892/Wed Mar 21 06:40:09 2007 on blah
X-Virus-Status: Clean
X-Spam-Flag: YES
X-Spam-Status: Yes, score=26.8 required=5.0 tests=HEADER_COUNT_SUBJECT,
	MAILTO_TO_SPAM_ADDR,RAZOR2_CF_RANGE_51_100,RAZOR2_CF_RANGE_E8_51_100,
	RAZOR2_CHECK,SARE_URI_DIGITS4,URIBL_BLACK,URIBL_JP_SURBL,URIBL_SBL,
	URIBL_SC_SURBL,URIBL_WS_SURBL autolearn=disabled version=3.1.8
X-Spam-Level: **************************
X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on blah
...


-- original, before SA --

To: info@playandwin.co.uk
Subject: PlayAndWin.co.uk - shut@playandwin.co.uk
From: "shut@playandwin.co.uk <to6332"@playandwin.co.uk
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
Subject: A few drops a day is all thats needed to create a leaner fitter you
Assignee: mail → nobody
Component: MailNews: Main Mail Window → MailNews: Backend
Product: Mozilla Application Suite → Core
QA Contact: backend
Summary: multiple subject headers in one mail causes different subject display in thread pane, defeats filtering → multiple subject headers causes different subject in thread pane than preview pane, defeats subject filtering, should use first subject
spam issue (with probably trivial solution) should be priority for TB3 - despite the fact that but has existed lo for 5 years. Tthis is just begging for some spammers to take advantage of this loophole on an big scale.

Junk processing affected (comment 8)?
Severity: normal → major
Flags: blocking-thunderbird3?
I'm pretty sure that the junk processing will add tokens from both subject headers. Haven't tested it though. So this issue is with filters only, which are probably used rarely enough that it would not be worth an exploit.
Product: Core → MailNews Core
potentially affects gloda.
not good to be keying on one subject string, but user sees a different string.
Maybe we should just coalesce all subject headers for display (only)?
(In reply to comment #13)
> potentially affects gloda.
> not good to be keying on one subject string, but user sees a different string.

Gloda gets the subject from the nsIMsgDBHdr, so the presentation issue is the same as with the thread pane.  Fix the thread pane consistency, fix gloda.
Wouldn't block for this edge case; blocking‑thunderbird3-
Flags: blocking-thunderbird3? → blocking-thunderbird3-
Flags: wanted-thunderbird3?
Whiteboard: [good first bug][impacts gloda]
Attached patch Use the first subject, 1 (obsolete) — Splinter Review
Attachment #408253 - Flags: review?(mnyromyr)
Assignee: nobody → lusian
Status: NEW → ASSIGNED
You can just check m_subject.length(), like we do for other headers where we just want the first header, insead of adding the boolean.
Attachment #408253 - Attachment is obsolete: true
Attachment #408272 - Flags: review?(mnyromyr)
Attachment #408253 - Flags: review?(mnyromyr)
Comment on attachment 408272 [details] [diff] [review]
Use the fist subject, 2: Address comment 18

>+++ b/mailnews/local/src/nsParseMailbox.cpp
>-    if (header)
>-      header->value = value;
>+    if (header) {
>+      if (header != &m_subject)
>+        header->value = value;
>+      else
>+        // Bug 172104: Use the fist subject
>+        if (m_subject.length == 0)
>+          header->value = value;
>+    }

This is the wrong place to fix this. 
A couple of lines above, we already do process subject stuff explicitly:
<http://mxr.mozilla.org/comm-central/source/mailnews/local/src/nsParseMailbox.cpp#1020>, you should do patching there, cf. line 1040/1041 how to do it.

>     if (header)
>-      header->length = buf - header->value;
>+      if (header != &m_subject)
>+        header->length = buf - header->value;
>+      else
>+        // Bug 172104: Use the fist subject
>+        if(m_subject.length == 0)
>+          header->length = buf - header->value;

This will be unnecessary with the real fix above, because header will be null here in this case.

Thanks for tackling this!
Attachment #408272 - Flags: review?(mnyromyr) → review-
Attachment #408272 - Attachment is obsolete: true
Attachment #408302 - Flags: review?(mnyromyr)
Attachment #408302 - Flags: review?(mnyromyr) → review+
Keywords: checkin-needed
you need an sr before you can checkin.
Keywords: checkin-needed
Attachment #408302 - Flags: superreview+
Keywords: checkin-needed
Keywords: checkin-needed
Keywords: checkin-needed
Checked in: http://hg.mozilla.org/comm-central/rev/c4f25121bdf7
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: wanted-thunderbird3?
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1a1
Removing "defeats subject filtering" part from bug summary to avoid confusion, because it still remains even after fix of this bug and is processed by bug 310189.
Summary: multiple subject headers causes different subject in thread pane than preview pane, defeats subject filtering, should use first subject → multiple subject headers causes different subject in thread pane than preview pane, should use first subject
You need to log in before you can comment on or make changes to this bug.