404264 - Junk Mail Controls to stop abnormally when processing email with null "from" (sender)

Status: RESOLVED FIXED

(MailNews Core :: Address Book, defect)

Description

[Cris Fuhrman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9
Build Identifier: version 2.0.0.9 (20071031)

Here's the Javascript error:

Error: [Exception... "Component returned failure code: 0x80004003 (NS_ERROR_INVALID_POINTER) [nsIAbMDBDirectory.hasCardForEmailAddress]"  nsresult: "0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: chrome://messenger/content/mailCommands.js :: anonymous :: line 609"  data: no]
Source File: chrome://messenger/content/mailCommands.js
Line: 609

Below are two munged examples of full headers (via CTRL-U) of a mail that will cause the bug. Notice either the absence of a "From" and/or a Return path that is null "<>". Sadly, some messages (bounces, backscatter) have this format.

Line 609 of the javascript mailCommands.js doesn't take this assumption into account (I think).

---------EXAMPLE 1-----------------
From - Sun Nov 18 14:21:03 2007
X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
Delivered-To: [e-mail]
Received: by 10.100.208.13 with SMTP id f13cs263182ang;
        Sun, 18 Nov 2007 10:46:26 -0800 (PST)
Received: by 10.90.36.3 with SMTP id j3mr5563399agj.1195411586728;
        Sun, 18 Nov 2007 10:46:26 -0800 (PST)
Return-Path: <>
Received: from mail-kr.bigfoot.com (mail-kr.bigfoot.com [211.115.216.252])
        by mx.google.com with SMTP id f75si7497501pye.2007.11.18.10.46.23;
        Sun, 18 Nov 2007 10:46:26 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of mail-kr.bigfoot.com designates 211.115.216.252 as permitted sender) client-ip=211.115.216.252;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of mail-kr.bigfoot.com designates 211.115.216.252 as permitted sender) smtp.mail=
Received: from cuatro.vandenberg.af.mil ([132.1.207.4])
	by BFLITEMAIL-KR5.bigfoot.com (LiteMail v3.03(BFLITEMAIL-KR5)) with SMTP id 0711190348_BFLITEMAIL-KR5_811453_5693672;
	Mon, 19 Nov 2007 03:49:29 +0900 EST
Received: from XCOM12000M-SG03 (xcom12000m-sg03.vandenberg.afspc.ds.af.mil [132.1.215.63])
	by cuatro.vandenberg.af.mil with ESMTP id lAIImrNw009505
	for <[e-mail]>; Sun, 18 Nov 2007 18:48:53 GMT
Date: Sun, 18 Nov 2007 18:48:53 GMT
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Returned Mail
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
 boundary="=====mte=boundary=number=1====="
... 
[deleted]

-----------Example 2-----------------
From - Sun Nov 18 14:20:24 2007
X-Mozilla-Status: 0001
X-Mozilla-Status2: 10000000
Delivered-To: [e-mail]
Received: by 10.100.208.13 with SMTP id f13cs263877ang;
        Sun, 18 Nov 2007 11:13:46 -0800 (PST)
Received: by 10.90.56.11 with SMTP id e11mr5548191aga.1195413226590;
        Sun, 18 Nov 2007 11:13:46 -0800 (PST)
Return-Path: <>
Received: from mail-kr.bigfoot.com (mail-kr.bigfoot.com [211.115.216.226])
        by mx.google.com with SMTP id r1si4957023nzd.2007.11.18.11.13.45;
        Sun, 18 Nov 2007 11:13:46 -0800 (PST)
Received-SPF: pass (google.com: best guess record for domain of mail-kr.bigfoot.com designates 211.115.216.226 as permitted sender) client-ip=211.115.216.226;
Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of mail-kr.bigfoot.com designates 211.115.216.226 as permitted sender) smtp.mail=
Received: from spamfilter.chs-adphila.org ([12.175.116.25])
	by BFLITEMAIL-KR3.bigfoot.com (LiteMail v3.03(BFLITEMAIL-KR3)) with SMTP id 0711181151_BFLITEMAIL-KR3_1049224_18490805;
	Sun, 18 Nov 2007 11:53:46 -0500 EST
MIME-Version: 1.0
From: MAILER-DAEMON <>
Message-Id: <000601c82a03$0679ffc8$190be8ad@pxgnsdk>
Subject: **Message you sent blocked by our bulk email filter**
Content-Type: multipart/report; report-type=delivery-status;
    charset=utf-8;
    boundary="----------=_1195404820-8547-39"
To: <[e-mail]>
Date: Sun, 18 Nov 2007 11:53:40 -0500 (EST)

This is a multi-part message in MIME format...
...

Reproducible: Always

Steps to Reproduce:
1. Make sure you have a bounced email coming from a null sender (e.g., <> in the From email)
2. Run Junk Mail controls on the folder.

Actual Results:  
The Junk Mail Controls stopped (nothing got filed in the Junk Folder) and I saw the errors in the Error Console.

Expected Results:  
Junk mail should have been filed.

A work-around is to manually move all "null"-addressed emails to the junk folder by hand, and re-run the junk controls.

Comment 1

[Cris Fuhrman]

Sorry I forgot to include the version of T-Bird (n00b mistake):
version 2.0.0.9 (20071031)

Comment 2

[Cris Fuhrman]

Also, these emails were in an IMAP folder on a Gmail account (could be important for header info?)

Comment 3

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #2)
> Also, these emails were in an IMAP folder on a Gmail account (could be

Adding Bug 402793 in dependency, because mail of RFC violation from "Gmai IMAP" is involved, although JS error/crash itslef is Tb's fault.

RFC 2822 defines mail address as follows.
> mailbox         =       name-addr / addr-spec
> name-addr       =       [display-name] angle-addr
> angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
> addr-spec       =       local-part "@" domain
> obs-angle-addr  =       [CFWS] "<" [obs-route] addr-spec ">" [CFWS]

Comment 4

[Cris Fuhrman]

(In reply to comment #3)
> Adding Bug 402793 in dependency, because mail of RFC violation from "Gmai IMAP"
> is involved, although JS error/crash itslef is Tb's fault.
> 
> RFC 2822 defines mail address as follows.
> > mailbox         =       name-addr / addr-spec
> > name-addr       =       [display-name] angle-addr
> > angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
> > addr-spec       =       local-part "@" domain
> > obs-angle-addr  =       [CFWS] "<" [obs-route] addr-spec ">" [CFWS]

I'm not sure that IMAP is the cause of the problem, but I understand the point of Bug 402793. 

I'm quoting wikipedia on bounces here - I think <> is legal for a from address.

http://en.wikipedia.org/wiki/Bounce_message#Causes_of_a_bounce_message

> Bounce messages in SMTP are sent with the envelope sender address <>, known as the null sender address. They are frequently sent with a From: header address of MAILER-DAEMON at the recipient site.

I should quote the RFC, but I don't know which one it is. Whether or not this is RFC-correct, the fact is that it *does* happen a lot (I get tons of backscattered bounces, over 500/day) and Thunderbird's junk mail controls should be working appropriately.

Comment 5

[WADA:World Anti-bad-Duping Agency]

As seen in Bug 402426, From: is returned as "ENVELOPE structure" when ENVELOPE is requested in FETCH. What will be returned for "from" in "ENVELOPE structure" by "Gmail IMAP"?
 1. Set mail.imap.use_envelope_cmd=true and restart Tb
 2. Get mail of "From: <>", with NSPR logging. (See Bug 402793 Comment #1) 
JS error/crash occurs too?

Comment 6

[WADA:World Anti-bad-Duping Agency]

See Bug 402426 Comment #15 for ENVELOPE response by Gmail IMAP, please.

Comment 7

[Cris Fuhrman]

(In reply to comment #5)
> As seen in Bug 402426, From: is returned as "ENVELOPE structure" when ENVELOPE
> is requested in FETCH. What will be returned for "from" in "ENVELOPE structure"
> by "Gmail IMAP"?
>  1. Set mail.imap.use_envelope_cmd=true and restart Tb
>  2. Get mail of "From: <>", with NSPR logging. (See Bug 402793 Comment #1) 
> JS error/crash occurs too?

I tried #1, but #2 takes me too much work - sorry. It's the same problem. Bounces often have null senders, regardless of how they're received (IMAP, POP3, whatever). Also, if you set up a rule in Tb to "reply with template" to a message that has a null sender, it tries to do it. I know this was a problem before Gmail's IMAP had come out. I worked around it by checking on my filter if the "Sender" contained a "@" (but this is probably another bug).

IMAP is surely not the problem, in this bug. Here's a new example (again partially munged). The first header is obtained via IMAP on Tb (CTRL-U), and later the header of the message via Gmail's web interface (show original). They are both showing null sender <>. On Gmail's web interface, it substitutes the "null" with "(unknown sender)" on the message list.

----VIA IMAP-------
From - Sun Nov 18 18:35:11 2007
X-Mozilla-Status: 0005
X-Mozilla-Status2: 10000000
Delivered-To: [e-mail]
Received: by 10.100.208.13 with SMTP id f13cs269321ang;
        Sun, 18 Nov 2007 14:56:10 -0800 (PST)
Received: by 10.65.192.19 with SMTP id u19mr9857862qbp.1195426569680;
        Sun, 18 Nov 2007 14:56:09 -0800 (PST)
Return-Path: <>
Received: from mail-kr.bigfoot.com (mail-kr.bigfoot.com [211.115.216.226])
        by mx.google.com with SMTP id i5si5178039nzi.2007.11.18.14.56.08;
        Sun, 18 Nov 2007 14:56:09 -0800 (PST)
Received-SPF: pass (google.com: domain of mail-kr.bigfoot.com designates 211.115.216.226 as permitted sender) client-ip=211.115.216.226;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of mail-kr.bigfoot.com designates 211.115.216.226 as permitted sender) smtp.mail=
Date: Sun, 18 Nov 2007 14:56:09 -0800 (PST)
Received: from outmail.kcc.com ([205.203.75.10])
	by BFLITEMAIL-KR3.bigfoot.com (LiteMail v3.03(BFLITEMAIL-KR3)) with SMTP id 0711181606_BFLITEMAIL-KR3_1049286_8486776;
	Sun, 18 Nov 2007 16:08:00 -0500 EST
Received: from [172.17.247.4] by outmail.kcc.com with ESMTP (:
 Unauthorized access prohibited (Email Firewall v6.3.1)); Sun, 18 Nov
 2007 15:07:25 -0600
X-Server-Uuid: BF489A06-5F67-4413-918C-92622EB8CE59
To: [e-mail]
Subject: Returned Mail
MIME-Version: 1.0
X-WSS-ID: 6B5E76064NG3372169-01-01
Content-Type: multipart/report;
 report-type=delivery-status;
 boundary="=====mte=boundary=number=1====="
Message-ID: <6B5E76054MO1301192-01@Kimberly-Clark_E-mail_Automation_(WSS)>


-----VIA GMAIL's SHOW ORIGINAL---------
                                                                                                                                                                                                                                                               
Delivered-To: [e-mail]
Received: by 10.100.208.13 with SMTP id f13cs269321ang;
        Sun, 18 Nov 2007 14:56:10 -0800 (PST)
Received: by 10.65.192.19 with SMTP id u19mr9857862qbp.1195426569680;
        Sun, 18 Nov 2007 14:56:09 -0800 (PST)
Return-Path: <>
Received: from mail-kr.bigfoot.com (mail-kr.bigfoot.com [211.115.216.226])
        by mx.google.com with SMTP id i5si5178039nzi.2007.11.18.14.56.08;
        Sun, 18 Nov 2007 14:56:09 -0800 (PST)
Received-SPF: pass (google.com: domain of mail-kr.bigfoot.com designates 211.115.216.226 as permitted sender) client-ip=211.115.216.226;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of mail-kr.bigfoot.com designates 211.115.216.226 as permitted sender) smtp.mail=
Date: Sun, 18 Nov 2007 14:56:09 -0800 (PST)
Received: from outmail.kcc.com ([205.203.75.10])
	by BFLITEMAIL-KR3.bigfoot.com (LiteMail v3.03(BFLITEMAIL-KR3)) with SMTP id 0711181606_BFLITEMAIL-KR3_1049286_8486776;
	Sun, 18 Nov 2007 16:08:00 -0500 EST
Received: from [172.17.247.4] by outmail.kcc.com with ESMTP (:
 Unauthorized access prohibited (Email Firewall v6.3.1)); Sun, 18 Nov
 2007 15:07:25 -0600
X-Server-Uuid: BF489A06-5F67-4413-918C-92622EB8CE59
To: [e-mail]
Subject: Returned Mail
MIME-Version: 1.0
X-WSS-ID: 6B5E76064NG3372169-01-01
Content-Type: multipart/report;
 report-type=delivery-status;
 boundary="=====mte=boundary=number=1====="
Message-ID: <6B5E76054MO1301192-01@Kimberly-Clark_E-mail_Automation_(WSS)>

Comment 8

[Cris Fuhrman]

(In reply to comment #4)
> I should quote the RFC, but I don't know which one it is.

It's RFC 3461, and we see in section 5.2 that "<>" return addresses are sometimes acceptable:

> 5.2 Handling of messages received via SMTP
> [snip]
>   NOTE: A DSN MUST NOT be returned to the sender for any message for
>   which the return address from the SMTP MAIL command was NULL ("<>"),
>   even if the sender's address is available from other sources (e.g.,
>   the message header). 

My feeling is that this bug is independent of any IMAP issues, although it doesn't mean an IMAP problem can't provoke this bug. All of the examples I have shown are indeed "DSN" (bounces, delivery status notifications, etc.)

Comment 9

[Cris Fuhrman]

changed "(addressee)" to "(sender)" in title of bug for clarity

Comment 10

[WADA:World Anti-bad-Duping Agency]

> IMAP is surely not the problem,

Thanks for testing. I was afraid that new problem occur by workaround of "ENVELOPE" use for "Gmail Imap". But it's found that there is no need to worry about it.

JS error for nsIAbMDBDirectory.hasCardForEmailAddress of mailCommands.js is reproduced by manual "Tools/Run Junk Controls on Folder" on a local mail folder(dummy POP3 account), with Tb 2.0.0.6 on MS Win-XP.
> Followings in mail source are changed by manual editing.
>  Return-Path : <>
>  From: <>
But "crash" can not be re-produced.
You say "crash" in bug summary. What is talkback ID for the crash?

When latest-trunk(2007/11/18 buuld), no JS Error was observed when manual manual "Tools/Run Junk Controls on Folder".
I think that problem won't occur after changes on trunk which relate to next phenomena.
(1) Tb 2.0.0.6 :
    "Sender" column is blank when mail of "From: <>".
(2) latest-trunk(2007/11/18 build) :
    "From" column is "<>" when mail of "From: <>".
    - Column name is changed to "From" from "Sender".
    - Meaning of the column is possibly changed to data in "From:" header only.

Comment 11

[WADA:World Anti-bad-Duping Agency]

Removing dependncy, because "Gmail IMAP" has no relation. 

Comment 12

[Cris Fuhrman]

Changed title, since it's not a crash with a talk-back ID, but rather the filtering stops abnormally. There's a JS error in the Error Console as described.

Comment 13

[WADA:World Anti-bad-Duping Agency]

Confirming based on test result of comment #10.
Can problem be re-produced with latest-trunk?

Comment 14

[Cris Fuhrman]

Sorry - I can't/won't test with unofficial release (latest trunk) because I'm not a software tester and use my PC to get important work done. 

I agree with your hypothesis regarding comment #10, but I can only confirm after an auto-update.

Also, another work-around for now is to uncheck the account's Junk Setting option "Do not mark mail as junk if sender is in:" -- this prevents the faulty check of a null sender from being done on this look-up.

However, I think there will still be a bug with a user-programmed message filter that tries to "Reply with template" to a null sender, since there will be an SMTP error. I may log this as another bug after the next official release, depending on how ungraceful such an SMTP error is handled. It's disappointing that automated filters get blocked with a dialog that the user has to dismiss, and the user has to clear the message. Again, a workaround is to test for null sender in the filter before attempting an automated reply, so it's not a show stopper.

Comment 15

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #14)
> However, I think there will still be a bug with a user-programmed message filter > that tries to "Reply with template" to a null sender, since there will be an SMTP error.

I think it's not branch only problem and problem can be produced with trunk.
Open separate bug, please.

(about workaround)
> another work-around for now is to uncheck the account's Junk Setting option
> "Do not mark mail as junk if sender is in:"

It's reasonable because the JS error occurs when Tb tries to check address book for existence of From: mail address. But it may increase number of false positive in Junk mail detection. 
As you say in comment #7, message filter at top of rules like following is simplest and effective workaround.
 - IF from doesn't contain "@", THEN mark as "Junk" and move to "Junk"
 - IF from contains "<>", THEN mark as "Junk" and move to "Junk"

Comment 16

[Cris Fuhrman]

(In reply to comment #15)
> (In reply to comment #14)
> (about workaround)
> > another work-around for now is to uncheck the account's Junk Setting option
> > "Do not mark mail as junk if sender is in:"
> 
> It's reasonable because the JS error occurs when Tb tries to check address book
> for existence of From: mail address. But it may increase number of false
> positive in Junk mail detection. 
> As you say in comment #7, message filter at top of rules like following is
> simplest and effective workaround.
>  - IF from doesn't contain "@", THEN mark as "Junk" and move to "Junk"
>  - IF from contains "<>", THEN mark as "Junk" and move to "Junk"

This workaround is also prone to false-positives. Sometimes, if a user sends a legitimate email that cannot be delivered, a DSN will come back with a "<>" sender. Just because a sender is null, it does not make the mail junk. 

I found some other nicer (annotated) references to the RFCs that discuss null senders: 
http://www.rfc-ignorant.org/rfcs/rfc2821.php#section4.1.1.2
http://www.rfc-ignorant.org/rfcs/rfc2821.php#section6.1
http://www.rfc-ignorant.org/rfcs/rfc1123.php#section5.2.9
http://www.rfc-ignorant.org/rfcs/rfc1123.php#section5.2.13
http://www.rfc-ignorant.org/rfcs/rfc2505.php#section2.
http://www.rfc-ignorant.org/rfcs/rfc2505.php#section2.6.1.

Comment 17

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #16)
> This workaround is also prone to false-positives.

Modified workaround:
(Step-1) Automatic filtering to avoid JS error
IF from contains "<>" or from doesn't contain "@",
  THEN mark as "Junk" (in order to avoid this bug, JS error in Junk filering),
       add Tag of "null-from" (in order for ease of false-positive checking),
       move to "Has-null-may-be-Junk" folder
(Step-2) Manual recovery from false-positive
Mark as non-junk manually if "<>" but not Junk, and move to"Has-null-but-Not-Junk" folder manually in order to avoid manual run of "Run Junk Controls on this Folder".

> rfc2821.php#section4.1.1.2
> rfc2505.php#section2.

Please note that these are for "Envelope From" in SMTP which is protocol(command) when passing data from SMTP client to SMTP server, not for From: header in mail data stream defined by RFC2822.
(See Bug 359426 for difference between SMTP command and mail data stream.) 
But, some implementations seem to generate "From: <>" mail header and many(probably all) POP3/IMAP servers won't reject or remove "From: <>". So Mozilla family is better to be tolerant with such RFC2822 violation.
And, when this bug's case(JS error in Junk filtering), problem is already resolved with trunk nightly(builds for next Tb 3). 

Comment 18

[Magnus Melin [:mkmelin]]

I guess the error comes from here:
http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsAbMDBDirectory.cpp#1077

Should we handle null From address there (and just return), or just check it here:
http://lxr.mozilla.org/seamonkey/source/mail/base/content/mailCommands.js#659

Comment 19

[Mark Banner (:standard8)]

(In reply to comment #18)
> I guess the error comes from here:
> http://lxr.mozilla.org/seamonkey/source/mailnews/addrbook/src/nsAbMDBDirectory.cpp#1077
> 
> Should we handle null From address there (and just return), or just check it
> here:
> http://lxr.mozilla.org/seamonkey/source/mail/base/content/mailCommands.js#659

I think I would say that nsAbMDBDirectory::CardForEmailAddress should handle a null pointer as the argument, or a zero-length string. In both cases it should set the aAbCard to nsnull and return NS_OK.

This would account for all cases - and I think we should really be checking for a zero-length string anyway - if this is being used for whitelists etc, and the ab contains a card with no email, then we don't want to match against that and mistakenly mark the email as ok.

Note that the branch has an additional nsAbMDBDirectory::HasCardForEmailAddress function, but just fixing CardForEmailAddress in both cases will do the job.

Comment 20

[Mark Banner (:standard8)]

Attachment: The Fix (checked in)

I've not tested this yet (apart from to check compilation), but I believe this should fix the problem.

Comment 21

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #14)
> However, I think there will still be a bug with a user-programmed message filter 
> that tries to "Reply with template" to a null sender,
> since there will be an SMTP error.

This behavior was observed with Tb 2.0.0.6 and latest-trunk.
When "Reply with Template" is executed for mail of "From: <>", following dialog appeared.
> Sending of message failed.
> No recipients were specified. Please enter a recipient or newsgroup in the addressing area.
> [OK]
>(Filter log)
> Applied filter "From <> test" to message from <> - From: <> Test 001 at 2007/10/25 20:26:35 replied

There are at least 2 issues.
(1) No description about which server/account/identity/filter etc.
(2) Very annoying when this occurred on automatic download and when executed for many mails, and because of (1), problem isolation becomes very difficult.

To Cris Fuhrman(bug opener):
If you think above is bug of Tb, open separate bug, because it is completely different issue from this bug, even though "problem when 'From: <>' header" is common. Please note that I don't care about it, although I also think it's better to be improved and I think following enhancements may be a solution.
  - No send action when null To: in auto-reply
  - Error message in filter log

Comment 22

[Cris Fuhrman]

(In reply to comment #21)
> To Cris Fuhrman(bug opener):
> If you think above is bug of Tb, open separate bug, because it is completely
> different issue from this bug, even though "problem when 'From: <>' header" is
> common. 

Done. It's now bug 405063. 

Comment 23

[Mark Banner (:standard8)]

Comment on attachment 289854 [details] [diff] [review]
The Fix (checked in)

I found an easy way to reproduce (and hence test this).

In account settings, temporarily blank out your email address. Compose a message, then save as draft & close. Drag message to the inbox. Then select inbox and "Run Junk Controls on Folder".

Without this patch we get an error, with this patch we're ok.

Same patch will apply for branch, so I'll request that once we get this in on trunk.

Comment 24

[David :Bienvenu]

Comment on attachment 289854 [details] [diff] [review]
The Fix (checked in)

thx, Mark - how about

+  if (!aEmailAddress || !*aEmailAddress)
+    return NS_OK;

instead?

I guess this routine already return a null card but NS_OK in the case where it gets a real address but it's not in the db...that's a lot more convenient for js callers, though it's against our conventions.

Comment 25

[Mark Banner (:standard8)]

Note this is a core bug, so moving to core/mailnews address book

Comment 26

[Mark Banner (:standard8)]

Attachment: Branch patch

I've now checked the patch into the main trunk. This is what I checked in, generated ready for the branch.

Requesting branch approval, not sure which approval flag to request at the moment so apologies for doing both.

Low risk bug fix patch for Thunderbird & SeaMonkey (not FF) that will help to improve the stability and security of junk mail processing in some circumstances (no sender email address).

Comment 27

[Mark Banner (:standard8)]

This is now fixed on trunk builds (TB 3.x SM 2.x) so marking bug as fixed. If approval is obtained, I'll check into branch at the appropriate time.

Comment 28

[Daniel Veditz [:dveditz]]

Comment on attachment 289949 [details] [diff] [review]
Branch patch

missed 1.8.1.10

Comment 29

[Mark Banner (:standard8)]

Attachment: Testcase (checked in)

Seeing as I fixed this recently, and we now have unit tests for address book, I thought I'd add a test for this one, especially as it's a hard one to detect (note, I'm not going back through all the bugs I've fixed to add unit tests, just this one).

The test checks the two cases of an "empty" email address, checks that we don't match a card that doesn't exist, and we match a card that does. The test file also contains a card with no email address as an additional check that we don't return that in the "empty" email address case.

I've checked the tests work by backing out various bits of the patch etc, and of course they'll pass on the current trunk.

Comment 30

[Wayne Mery (:wsmwk)]

filter also has trouble with null from - Bug 391717 filter with from criteria doesn't work if message's From: address is null or missing

is 1.8.1.12 looking to be January time frame?

Comment 31

[Mark Banner (:standard8)]

(In reply to comment #30)
> filter also has trouble with null from - Bug 391717 filter with from criteria
> doesn't work if message's From: address is null or missing
> 
> is 1.8.1.12 looking to be January time frame?
> 
I wouldn't be surprised if that's the same bug as this. You should be able to check via the Error Console. I've got no idea when the next TB is to be released for the 1.8.1 series.

Comment 32

[Daniel Veditz [:dveditz]]

Comment on attachment 289949 [details] [diff] [review]
Branch patch

approved for 1.8.1.12, a=dveditz for release-drivers

Comment 33

[Mark Banner (:standard8)]

(In reply to comment #32)
> (From update of attachment 289949 [details] [diff] [review])
> approved for 1.8.1.12, a=dveditz for release-drivers
> 
Patch checked in, fixed on 1.8 branch.

Comment 34

[Al Billings [:abillings - ex-MoCo]]

Using steps in comment #23, I reproduced this problem in TB 2.0.0.9. In the 2.0.0.12 build, it is fixed (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/2008021304 Thunderbird/2.0.0.12).

Marking verified1.8.1.12.