194135 - address matching should check "additional email" fields

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

Description

[Don Erway]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

For junk mail, filters and view "people I know" the address matching does not
check "additional email" fields in the address book.

Reproducible: Always

Steps to Reproduce:
1. Create an address book entry, with main and additional email addresses.
2. Receive mail from the "additional" address 
3. See message filters based on "is in personal address book" fail.
4. See that junk mail does not consider it from known addresses.
5. See it disappear when doing view "people I know"


Actual Results:  
address is not considered known

Expected Results:  
address should be treated as known.

I view this and the case sensitivity of address matching to make the current
facility worse than what I was doing before - to use a long list to catch all
the knowns, which at least was case insensitive.

Comment 1

[Giorgio Agrelli]

yes this affects also filtering based on an address book, and the case
sensitivety makes things work a lot worst!
BTW i guess it affects all hardware architectures and all the OSs as this does
the same for me on Mozilla 1.3.0 on Linux and FreeBSD

Comment 2

[Nicolas Owens]

I confirm that this bug exists on Mac OS X Moz 1.3

Comment 3

[Oscar Retana]

Yes. When processing junk mail, the additional email address is not checked. It
also happens that the email addresses are case sensitive, when processing junk
mail, even with the main email address.

Comment 4

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 5

[Wayne Mery (:wsmwk)]

works for filters so should also work for junk processing.  
WFM. Please reopen if you see otherwise

Comment 6

[Don Erway]

Sorry, no it does NOT work in filters, in thunderbird 2.0.0.6.

If you make a rule by saying "FROM: is in my address book", the "additional email" field does not cause a match for incoming email messages!  You have to have a whole extra address book entry, for each address, as "additional address" is never checked.

What version are you running?

Comment 7

[David :Bienvenu]

is this the issue that the check for "additional address" is case sensitive, but the primary address check is case-insensitive?

Comment 8

[Wayne Mery (:wsmwk)]

most likely. comment 0 does mention case sensitivity.  and of coursebug 317392 comment 9.

Comment 9

[Wayne Mery (:wsmwk)]

David, I vaguely recall that you or Mark said the "normal" email address is stored in a second location in the card for comparisons, but "additional" email doesn't have that.

Comment 10

[David :Bienvenu]

yes, right, as I remember it, the normal email address is stored twice; the second version is forced to lower case, and we use that for comparisions, after forcing the address we're looking for to lower case as well. We don't do that for the "additional" e-mail address.

Comment 11

[Don Erway]

Yes, sorry, you are right!  Now days it works, except when there are letter case differences.

Comment 12

[Martin Petricek]

Also, perhaps the meaning of "Additional email" could be changed to "Additionel email(s)" to allow specifying (there are few people out there who have more than two email addresses. Often they use only one or two of them, but they have some "history" - each new employer mean new email address for them)

Comment 13

[Torsten Villnow]

(In reply to comment #12)
I tend to disagree with the statement, that only few people have more
than two email addresses. I am in frequent contact with people, who use both their private and their business email address for communication. This is certainly not an uncommon behaviour.

Comment 14

[Torsten Villnow]

(In reply to comment #13)
Sorry - it's Monday obviously (being confused with numbers). Please disregard my comment.

Comment 15

[Mark Banner (:standard8)]

The remaining case sensitivity issue has been fixed by bug 450149 (a while ago) and is in the SeaMonkey 2.x preview builds.