This is spun off bug 128535 and bug 121478. In the patch to the above two bugs we changed the logic of hashing case insensitive email address to case sensitive in order to find the associated address card info. In doing so we also break the following scenario: You already have a card with email address all in lower case (like "cavin@netscape.com") and someone sends you an email and the To: line is specified as "Cavin@netscape.com" (ie, capital 'C'). In this case, we can no longer find the card info associated with "Cavin@netscape.com" because the card was created with all lower case letters, and so a new card with "Cavin@netscape.com" will be added to the Collected Addrbook. In other words, you now have two cards with email address "cavin@netscape.com" and "Cavin@netscape.com" respectively. Before the patch went in we did not have this problem because we used case insensitive email address to locate the card and was able to find it.

futuring. I don't think we're going to get to this any time soon.

Also happens for Linux -> OS/Platform=ALL pi

*** Bug 118388 has been marked as a duplicate of this bug. ***

*** Bug 145746 has been marked as a duplicate of this bug. ***

*** Bug 172806 has been marked as a duplicate of this bug. ***

mass re-assign.

*** Bug 218930 has been marked as a duplicate of this bug. ***

*** Bug 240012 has been marked as a duplicate of this bug. ***

Ok, this is pretty sad. I'm not a dev, but given how often this bug gets reported I'm awfully tempted to see if I can't hack something in there. It isn't like e-mail addresses are *that* complicated. Why can't the storing of the address be case insensitive, and the lookup be case insensitive, and that's it? If different formats for the address arrive, tough. You already have an entry with a matching format.

*** Bug 256526 has been marked as a duplicate of this bug. ***

note Bug 256526 comment 1

*** Bug 280067 has been marked as a duplicate of this bug. ***

*** Bug 305499 has been marked as a duplicate of this bug. ***

*** Bug 310601 has been marked as a duplicate of this bug. ***

*** Bug 312103 has been marked as a duplicate of this bug. ***

*** Bug 318840 has been marked as a duplicate of this bug. ***

Three and a half years later and still unfixed. Not bad. How can this be made into a security issue so it's given some attention other than "oh yes, it's a dupe"? :) For diligent users who've gotten this far: the misbehaviour stops if you go to Tools / Options / Advanced / General Settings and remove the check from "Automatically add outgoing e-mail address to my..." Of course you're going to lose that functionality but it's broken anyways, so...

In 1.5 beta (20051025), it's now located in Tools | Options | Composition | Addressing. Anyway, I'm not sure if it is fixed in 1.5 beta, or if the whole save e-mail addresses thing is broken.

*** Bug 319156 has been marked as a duplicate of this bug. ***

*** Bug 322271 has been marked as a duplicate of this bug. ***

Actually, email-address are case-sensitive before the '@' sign (john.doe@example.com isn't the same as JOHN.DOE@example.com or John.Doe@example.com), see RFC822, para 6. But almost nobody uses this in reality, and lots of mail-applications (client, server, MTA, ..) will happily translate from uppercase to lowercase and back. If the address collection would use it, it would be a big advantage.

(In reply to comment #21) > But almost nobody uses this in > reality, and lots of mail-applications (client, server, MTA, ..) will happily > translate from uppercase to lowercase and back. If the address collection would > use it, it would be a big advantage. Can't we reverse the argument by asking if there is any email application that *does* use the case-sensitive RFC822 requirement? If there are none, that means it is the de facto standard and the case-sensitive RFC822 requirement is defunct and we can proceed fixing this bug. Personally I am not aware of email applications or servers that do follow the RFC to the letter, but it has been a while since I've used anything else than Outlook/Exchange and Thunderbird/Mozilla Mail. Can other shed more light on this issue? Regards, Erik

If I already have this email address with the same name, I think it is rather obvious that it's a duplicate and shouldn't be added again. Even with a different name it would be nice to have an option which suppresses the addition of duplicates. My address book contains 30% duplicates with some addresses having been added 3 times. Not only does it clutter my address book, it also does make chosing a recipient more difficult (because the auto-completion dropdown box gets pretty crowded over here).

(In reply to comment #22) > Can't we reverse the argument by asking if there is any email application that > *does* use the case-sensitive RFC822 requirement? If there are none, that means > it is the de facto standard and the case-sensitive RFC822 requirement is > defunct and we can proceed fixing this bug. > > Personally I am not aware of email applications or servers that do follow the > RFC to the letter, but it has been a while since I've used anything else than > Outlook/Exchange and Thunderbird/Mozilla Mail. Can other shed more light on > this issue? > > Regards, > Erik > http://email.about.com/od/emailbehindthescenes/f/email_case_sens.htm http://mail.python.org/pipermail/mailman-developers/1998-October/005120.html http://www.cygwin.com/ml/cygwin-xfree/2001-q3/msg01408.html I've seen them before, but they would be extremely rare however. Some old systems have case-sensitive usernames, like a Control Data supercomputer that I once worked on in 1989.

Maybe there should be a hidden preference like mail.collect_email_adress.case_sensitive where the default is FALSE so that it would be a good compromise for those who actually need to set it on.

Regarding RFC822, I believe it does not apply to this issue. In the Scope section, the RFC states: "This specification is intended strictly as a definition of what message content format is to be passed BETWEEN hosts." Note the emphasis on BETWEEN (actual emphasis in the RFC text, not mine). The issue we are discussing here is not behavior between hosts. Rather, we are talking about what happens outside of the boundary of the "between hosts" channel. The RFC states that the local part is "case preserved" and "uninterpreted". We are talking about how the MUA interprets the address. That behavior is not defined by RFC822. Hopefully then anyone working on this issue will not feel constrained by RFC822. In my opinion, case should be preserved by the MUA where convenient. But, for the purpose of address matching, case sensitivity should be avoided for the local part as well as the domain part.

It would be interesting to know what RFC 2822 says about this, since it has superceded RFC 822.

RFC2822 says nothing about CS, as far as I can see. http://www.faqs.org/rfcs/rfc2822.html : ... specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This standard supersedes the one specified in Request For Comments (RFC) 822 ... ... (See [RFC2821] for a discussion of the envelope.) The contents comprise the object to be delivered to the recipient. ... It contains no specification of the information in the envelope. And I don't see that this bug has anything to do with the envelope.

(In reply to comment #28) > > And I don't see that this bug has anything to do with the envelope. > Correction: it does when formatting the envelope for a new message, I meant when matching addresses in the address book. It is up to the person composing the message to make sure the addresses are correctly formatted before sending.

Correct you are. RFC 822 is obsoleted by 2822. We are taling about the "local-part" of the address. Here's everything relevant that 2822 has to say on the issue: "The local-part portion is a domain dependent string. In addresses, it is simply interpreted on the particular host as a name of a particular mailbox." In other words, the receiving domain may or may not treat the local-part of the address in a case sensitive manner. RFC 2822 does not define that behavior. This argues in favor of preserving the case entered by a user or captured from an incoming message. But, matching should still be case-insensitive. How likely is the case where 2 email addresses differing only in case really define 2 separate delivery destinations?

*** Bug 347906 has been marked as a duplicate of this bug. ***

*** Bug 364031 has been marked as a duplicate of this bug. ***

(In reply to comment #30) > still be case-insensitive. How likely is the case where 2 email addresses > differing only in case really define 2 separate delivery destinations? I completely agree, the chance is hypothetical at best. Since the case sensitivity is so widely mis-used, we really should take the pragmatical approach here, IMO.

*** Bug 364784 has been marked as a duplicate of this bug. ***

So how would people feel about a user option? Wouldn't this solve the problem for pretty much everyone? (In reply to comment #25) > Maybe there should be a hidden preference like > mail.collect_email_adress.case_sensitive where the default is FALSE so that it > would be a good compromise for those who actually need to set it on. >

Sounds great--though I think it should default to "TRUE". Re: what Terry said... I've never, ever heard of a situation where it was relevant that "Greg@Supersilly.com" be distinct from "greg@supersilly.com".

I would suggest, looking at existing prefs: mail.collect_email_address_ignore_case or mail.collect_addressbook.ignore_case (In reply to comment #35) > So how would people feel about a user option? Wouldn't this solve the problem > for pretty much everyone? > > (In reply to comment #25) > > Maybe there should be a hidden preference like > > mail.collect_email_adress.case_sensitive where the default is FALSE so that it > > would be a good compromise for those who actually need to set it on. > > >

(In reply to comment #37) > I would suggest, looking at existing prefs: > mail.collect_email_address_ignore_case or mail.collect_addressbook.ignore_case Love to - what version of Thunderbird did you say this was in again? Can't see anything in 1.5.0.9 and this is all that a lot of people have been asking for.

It doesn't exist yet... Ian was proposing what it would look like if and when it's done.

my 5c: I don't think a pref would be needed, it's just not something anyone would have any use for in real life. Also note that the *domain* should be case-insensitive no matter what, which makes it even more complicated to implement such a pref.

(In reply to comment #40) > my 5c: I don't think a pref would be needed, it's just not something anyone > would have any use for in real life. Right now, e-mail address matching is case-sensitive. The options are either to make it case-insensitve, or to provide a pref to make it case-insensitive. I'd imagine the two are about the same amount of work. > > Also note that the *domain* should be case-insensitive no matter what, which > makes it even more complicated to implement such a pref. > Not wildly so; the matching would always be case-insensitive after the '@'; the local-part (before the '@') would be either case-sensitive or case-insensitive per the pref. Now another question I have pertains to modularity -- where, correctly, should the issue be addressed and the preference applied? Does the issue pertain to matching in general? Or only to matching in service of collecting addresses? I believe it is the former, as it affects other things besides address collection, for example identifying the correct cert of keying material to associate with an e-mail address for S/MIME. So perhaps the preference should be set globally rather than with regard to address collection? mail.email_address_match_case_sensitive. Completely separately, do people think that "John Smith <john@foo.bar>" and "john@foo.bar" ought to match?

I use Thunderbird for my business mail and I am very glad with it, except the adress collection (as discussed here). My problem is (lots of other users surely have this as well): - I maintain my personal adressbook manually - when I send an email, the recipient address is collected to the collectedAdresses-Adressbook So far this is ok. My suggestions: 1) It would be great, if email-addresses are only added/collected if they are not already contained in any existing adressbook (personalAdressbook AND collected adresses) 2) I would appreciate a hidden about:config-flag like mail.email_address_match_case_sensitive_for_collectedadresses = 0/1 3) it would be great, if the setting "trust senders / do not junk mails from senders that are in the adressbook" could be assigned to more than one adressbook (this would enable users to trust all people they have sent emails to and to all people in their personal adressbook, too)

Everythign that "Markus Weis" said above. I badly need those options. And I cannot understand why this has not been addressed yet. Is it not abundantly clear that it is a problem? Lets take this one step further though, how about a nice little checkbox "Ignore Case" in the options under the existing "Automatically Add Out-Going..." Option. Or if all of this is too difficult could some one write an extension that will replace this feature and support all of the above requests? It is sad that it has come to the point that we are asking for someone to write what TBird already almost does. But we really need this fixed. None of the poeple I have using TBird can collect addresses in their primary addressbook because of this problem. And that is messing with the junkmail filter as well. Thank you SO much in advance for helping with this.

Bug 58769, Bug 446571 and Bug 446574 also have comments about collecting addresses and case sensitivity.

As a practical observation, anybody who has the technology to create addresses which differ only by case in the localpart are begging for trouble. E.g. pretty much any software from IBM which sends email will MALICIOUSLY UPPERCASE every address.

This tread is an embarrassment to mozilla! SEVEN YEARS!!! I am getting duplicate email addresses in my addressbook and Thunderbird is putting them there. Nevermind why it is happening, THAT *IS* a bug. So, to help Mozilla feel inclined to actually take some action. If this problem is not solved in the next version, I am going to start posting all over the net warning people not to use Thunderbird and this bug report is evidence that Mozilla cannot fix even the simplest of very annoying issues. Clearly after seven years they are not ABLE to fix it. The original RFC argument is a full blown cop-out. They should read the posts in this thread. The amount of human time dedicated to creating duplicate bug reports and posting into this one clearly runs into thousands of dollars in labor. This is just sickening. The amount of money they now stand to save by fixing this is going to be great. Because by the time myself and my group are done people will think twice before buying a Mozilla product. I would much rather they just fix the issue and then everyone could be happy. Thank you...

lol too right Merlin! seven years to add a "lower case" wrap around a duplicate email check is shocking. considering other popular email clients no longer care about case sensitivity (nor do users), why should thunderbird? its more of an inconvenience to stick so closely to the rules of yesteryear. (In reply to comment #51) > This tread is an embarrassment to mozilla! SEVEN YEARS!!! > I am getting duplicate email addresses in my addressbook and Thunderbird is > putting them there. Nevermind why it is happening, THAT *IS* a bug.

(In reply to comment #52) > lol too right Merlin! > seven years to add a "lower case" wrap around a duplicate email check is > shocking. > considering other popular email clients no longer care about case sensitivity > (nor do users), why should thunderbird? > its more of an inconvenience to stick so closely to the rules of yesteryear. > (In reply to comment #51) > > This tread is an embarrassment to mozilla! SEVEN YEARS!!! > > I am getting duplicate email addresses in my addressbook and Thunderbird is > > putting them there. Nevermind why it is happening, THAT *IS* a bug. Thank you for the support. I was worried I might come off sounding like too much of an A/hole. But something seriously needs to be done here. There is no reason why they could not take the advice of many of the posters here about adding a tick to turn on or off the case compatibility totally solving the problem while maintaining their RFC compliance. And since the solution was handed to them already and they chose to ignore it. We must now react accordingly. Soon I will call to all of those who have suffered at the hands of this bug to retaliate and the movement will begin!!!

Dude, you think that's bad... (Totally o/t here) I'm also waiting on Bug 66806 which has been around even longer, and is even more annoying in my opinion. It is disappointing to see development of this product slow to where it is today - T/bird used to be roaring along, and while the betas of 3.0 are nice, they just don't seem to represent (collectively) 8+ years of work! (I know, I know, it's had a bit of a bumpy history). Anyone seen Opera mail lately? But seriously, I'm not much of a developer but I'd love to help TB more. I've downloaded the source, R'd TFM, and tried making some changes myself but I just got a little overwhelmed by it. If anyone is willing to help me through the initial steps, I'm more than happy to give this (and Bug 66806) a shot. Anyone? (In reply to comment #53) > (In reply to comment #52) > ... > Thank you for the support. I was worried I might come off sounding like too > much of an A/hole. But something seriously needs to be done here. There is no > reason why they could not take the advice of many of the posters here about > adding a tick to turn on or off the case compatibility totally solving the > problem while maintaining their RFC compliance. And since the solution was > handed to them already and they chose to ignore it. We must now react > accordingly. Soon I will call to all of those who have suffered at the hands > of this bug to retaliate and the movement will begin!!!

Guys, I totally agree with you that it's taking far too long to get something as simple as this fixed. Ridiculous, really. It has been suggested that turning-off the "Automatically add outgoing e-mail address to my <Address Book>" option is a work-around, though it isn't really acceptable as then you have to manually add all addresses yourself. Rather than a smear campaign, though, could I suggest that you instead get everyone to Vote on this bug - it's only got 26 votes at the moment. Getting enough people to vote on it will help to raise its importance and perhaps actually get it fixed.

(In reply to comment #55) > Rather than a smear campaign, though, could I suggest that you instead get > everyone to Vote on this bug - it's only got 26 votes at the moment. Getting > enough people to vote on it will help to raise its importance and perhaps > actually get it fixed. seconded now to find the vote button...

@koonkii: the vote button is next to the vote count up in the headers, next to the label "Importance": (and just before "Target Milestone:"). So is there a consensus that the case significance for localpart can be ignored? I can see three distinct scenarios. 1. Case@example.org is valid, and added to the address book exactly as you typed it. 2. Case@example.org is misspelled (in case or otherwise) and Thunderbird cannot know this. It is added to the address book although ideally it shouldn't be. The argument that it is incorrect because of a case distinction is hardly relevant; it's an invalid address, and Thunderbird cannot do anything to fix it. 3. Case@example.org is valid, but different from the intended cAse@example.org. This is pathological in the extreme, and there is no evidence that any site creates addresses which differ only by case. Anybody who does is desperate for attention, rather than demonstrating sane practices on a net where the case distinction for localpart was long ago dropped in practice. In the light of this, does anybody really insist that there needs to be a preference to control this? Most users cannot know the reason for such a pref, and exposing it only invites new variations on this very bug report.

Era, thank you for taking the time to read this thread and become involved. It is appreciated. allow me to summarize this thread for you. We do not care or see a reason for the auto add to addressbook to use case sensitivity. There are I think 2 other area's that this applies to, based on the other duplicate tickets I have read. As it is stated that the developers feel that this follows the RFC standard and that is why it has not been fixed, totally ignoring the very poor results of this issue. We have proposed ticks (checkboxes) to toggle case sensitivity on and off to satisfy any developers while giving the users what they need and also giving the ability to support RFC compliances for that one ANAL ISP somewhere that is actually using 2 addresses that are the same but separate case.. where ever that may be in the world. In short... SEVEN YEARS! Please just put the patch into the core so I and everyone I know will stop getting duplicates.

@era: Speaking to case 3, I don't think it's the ISP's to blame for multiple representations of the same e-mail address differing only by case. As someone who monitors and acts on corporate Delivery Service Notifications on a daily basis, I can safely say the cause of this rests largely on the users. I have one user, for example, who chooses not to use address books but instead types e-mail addresses for everyone on his Cc lists - half the time he can't even spell his own mail domain name correctly, so getting him to type e-mail addresses in a case-consistent manner is something beyond him. More generally, however, it's safe to say today that there are a not-insignificant number of users today who have multiple MUA's to access their mail: one for home, one for work and one for their mobile appliance (iPhone, for example), all accessing a common mail store such as Gmail, IMAP or Exchange. It's also not uncommon for those same users to setup each of those MUA's in slightly different ways, so John Smith may have his Reply-To address at home setup as John.Smith@example.org, work as JOHN.SMITH@example.org and iPhone as john.smith@example.org. These all represent the same e-mail address so I don't think that it's unreasonable to have Thunderbird treat them as the same address. Thanks, Anthony.

@Anthony I totally agree with you. Another issue.. and this is what happens to me.. I tend to type eMail addresses in Proper Case because they are easier to read and well it is just how my mind seems to work. JohnDoe@Yahoo.com for me is easier then johndoe@yahoo.com. But when john sends me an eMail he has typed it in all lower or yahoo has configured it that way and then I start getting the duplicates. Or another common thing to happen is they redo their eMail client for some reason and type it slightly differently when setting it up the next time. So lets get the votes up on this thing and get it solved once and for all. So we can end this SEVEN YEAR curse!

(In reply to comment #57) > @koonkii: the vote button is next to the vote count up in the headers, next to > the label "Importance": (and just before "Target Milestone:"). Thanks era > In the light of this, does anybody really insist that there needs to be a > preference to control this? Most users cannot know the reason for such a pref, > and exposing it only invites new variations on this very bug report. As it seems to be an unspecific behaviour to ignore casing, I don't think there should be an option for it which is publicly visible. At most it should be a hidden variable set in the config editor.

(In reply to comment #61) > As it seems to be an unspecific behaviour to ignore casing, I don't think there > should be an option for it which is publicly visible. At most it should be a > hidden variable set in the config editor. Did I read that backward? Did you mean to say an unspecific behavior to require casing? I would think that thunderbird should ignore case by default and have a variable to switch that if needed. Correct?

(In reply to comment #62) > Did I read that backward? Did you mean to say an unspecific behavior to > require casing? I would think that thunderbird should ignore case by default > and have a variable to switch that if needed. Correct? Sorry if I made it vague, what I meant was to "make it ignore the case by default, but implement a hidden switch to revert back to case sensitive" IF they wanted to.

Having to deal with customer e-mail systems, I've seen USER@corp-that-shall-remain-nameless.com and user@corp-that-shall-remain-nameless.com resolve to two different users, so it does exist (no mater how asinine it is to have usernames that differ only in the casing). Hidden switches, on the other hand are a royal pain, particularly when they're created to revert a behavior change. I'm all for having a visible option called "case insensitive usernames" (right below the checkbox "Automaticaly add outgoing email addresses to my:"). Said option should be off by default, since it's bad form to change from a correct behavior (RFC compliant) to something that's "merely" practical. And yes, I'll set that option to "on" on my TB, with full understanding of why it is wrong (standardwise) and why I won't care.

This bug has nothing to do with standards or user preferences, it's about using a case-intensive search against an (apparently) case-sensitive list, adding a preference just re-activates the old bugs that do basically the same thing. With my limited coding experience, I really don't understand the bug, normally when you do a case-insensitive match BOTH sides of the expression are converted to the same case (temporarily), as in the RegExp (/User@example\.com/i). But apparently the address searched in the address database is not converted, it doesn't make sense to me; referring to bug 128535, comment 8 and the description "since the card was created with the non-modified email address we simply can't find the card", and bug 121478, comment 8. Certainly, the domain part cannot be case-sensitive. These three bugs all want the same thing, matching address book entries no matter what the case is. If there is any problem with special characters, then that is really a separate bug where perhaps a second case-sensitive search could be performed if there is an error, or perhaps do both a case-sensitive then case-insensitive search if not found.

(In reply to comment #65) @Ric Gates What was your point exactly? Your initial statement in the first paragraph is 100% NOT correct. I do not feel this contributes to a resolution or getting someone to put the resolution into the core code. This bug exists because of the standards therefor it has everything to do with the standards and we are asking for the ability to go against the standards to prevent the duplicates.

I read the other bugs that are linked to, it has to do with the way addresses are matched, not why. Changing from a case-insensitive match to a case-sensitive match fixed the other bugs, where you did make a comment but apparently didn't understand the problem that was fixed. We should stop arguing about standards and fix the actual bug that hasn't yet been fixed. I'm sorry I don't know enough about the core code to help fix it, but most of the other comments here are no help at all. See bug 128535, comment 14 "we've basically decided that passing in false is 'less-evil' than passing true. (both ways will have bugs)"

This is a deceivingly simple patch which corrects the main problem: Don't add duplicate addresses (that differ only in case) to the address book collection. Personally, I believe this should be considered for inclusion. As far as servers with case-sensitive user names (hard to find, but probably not impossible) there's always manual address book management! The difference is that it would impact far fewer users, and it would only be necessary to do far less work; 1) As it is now, collected address books require continual maintenance to remove duplicate addresses. 2) With this patch, that particular maintenance nightmare goes away, but it also produces a new one: If a user actually *wants* duplicate email addresses in the collected address book, they must add them manually, since Thunderbird will no longer collect them automatically. I have no data to support this claim, but here it is anyway: Adding duplicate [case-sensitive] entries to an address book on purpose is far less common than removing duplicate addresses which where added by accident. So that's why I dived in and came up with this simple one-liner patch!

Comment on attachment 427427 [details] [diff] [review] Example patch I believe this turns the lookup into an O(n) lookup, instead of a hash table lookup, because we have to iterate the whole address book to do a case-insensitive match on the secondary address field (but Standard8 would know more)

That sounds like a reasonable argument against it, but what other choices are there for case-insensitive string matches? Particularly, if there's a more efficient way to do case-insensitive lookups in the address book, that should be done in another bug?

what we do for the primary column is we store two fields in the ab, one that has the original case, one that's lower case, and do case-insensitive lookups by changing the search term to lower case, and doing a hash table lookup on the lower case column. We don't do that for the secondary e-mail address, though we certainly could. But I'm just a tourist in AB land - Standard8 or jcranmer could say more.

Comment on attachment 427427 [details] [diff] [review] Example patch Sorry for not getting back to this much earlier, I was never able to quite decide on the perf aspects of this. However, the perf aspects do worry me, although this is happening just after sending email, I wouldn't want to be hanging at that stage on large address books due to this. I've chatted with Joshua on irc, and we think it would be reasonable to set up a lower-case column for the secondary email address, in pretty much the same way as the primary email address column.

I think I have found the solution. Please see mailnews/addrbook/src/nsAbAddressCollector.cpp in function: CollectSingleAddress which is trying to find an existing card in this way: card = GetCardFromProperty(kPriEmailProperty, aEmail, getter_AddRefs(originDirectory)); // We've not found a card, but is this address actually in the additional // email column? if (!card) { card = GetCardFromProperty(k2ndEmailProperty, aEmail, getter_AddRefs(originDirectory)); if (card) emailAddressIn2ndEmailColumn = PR_TRUE; } If you look at: mailnews/addrbook/src/nsAbMDBDirectory.cpp you will see that the function can accept four parameters: NS_IMETHODIMP nsAbMDBDirectory::GetCardsFromProperty(const char *aProperty, const nsACString &aValue, PRBool caseSensitive, nsISimpleEnumerator **result) But the code above from CollectSingleAddress does not supply caseSensitive parameter when calling GetCardsFromProperty. Because in function: GetCardsFromProperty the following (proper?!) call is made: return mDatabase->GetCardsFromAttribute(this, aProperty, aValue, !caseSensitive, result); the assumed value of the non-specifed caseSensitive parameter might be resulting in an case sensitive search, which is not what we desire. Can someone please review this analysis and test a simple patch by explicitely providing caseSensitive in the calles from CollectSingleAddress to GetCardsFromProperty?

The source files used for the analysis above are identical in thunderbird-3.1.16 and thunderbird-8.0 Please fix this for Thunderbird versions 3, 7 and 8 before this bug is able to celebrate its tenth birthday.

(In reply to Pander from comment #75) > the assumed value of the non-specifed caseSensitive parameter might be > resulting in an case sensitive search, which is not what we desire. > > Can someone please review this analysis and test a simple patch by > explicitely providing caseSensitive in the calles from CollectSingleAddress > to GetCardsFromProperty? That proposed solution is basically exactly the same as the patch attached to this bug and would be rejected because of the perf concerns as already detailed in comments 69 - 74.

(In reply to Mark Banner (:standard8) from comment #77) ... > That proposed solution is basically exactly the same as the patch attached > to this bug and would be rejected because of the perf concerns as already > detailed in comments 69 - 74. Understood, but is the current implementation not having the same perf? In tht case, can the implementation be in two parts in order to gain some momentum on this bug? First fix the functionality as is proposed by the patch and later optimise the performance. This bug is providing me a lot of extra work in terms of housekeeping the address book. Personally, I'm willing to pay the extra CPU-cycles for the moment (which are used anyway?), in order to prevent collecting email addresses I already have in my address book. The best, of course, would be a patch solving both at the same time. Speaking of which, why isn't it possible to offer bounties on bugs like these?

Wow. Almost 10 years. The simplest problems are sometimes the hardest to fix! I have just read http://www.w3.org/Protocols/rfc822/#z8 and see nothing about case sensitivity - except for reserved address (postmaster@) which should be case insensitive. Has it been updated since this bug was opened? Maybe I did not read it correctly. Note: I just tried importing my Collected Addresses (full of dupes due to this issue) in to Gmail and it accepted the dupes. Not sure what that tells us! Note 2: Duplicate Contact Manager extension - https://addons.mozilla.org/en-us/thunderbird/addon/duplicate-contact-manager/

It's now rfc5322. I'm pretty sure we want this fixed, it's just a matter of making it happen.

(In reply to Pander from comment #79) > (In reply to Mark Banner (:standard8) from comment #77) > ... > > That proposed solution is basically exactly the same as the patch attached > > to this bug and would be rejected because of the perf concerns as already > > detailed in comments 69 - 74. > > Understood, but is the current implementation not having the same perf? No, case-sensitive lookups are done via a hash implementation and therefore don't suffer from the perf issue of a case-insensitive lookup. Which is why another column would be required.

Do you guys actually have any intention of fixing this issue or does ticket only exist purely to keep the duplicates in control?

Here's a hint regarding the likelihood of this bug ever being fixed: "I don't think we're going to get to this any time soon." That comment was written in 2002! Programmers do not like to fix bugs, they like to add new features. Fixing bugs is hard, and there's no glory in it. But don't give up hope. It could get fixed someday, as a side-effect to some new feature.

The reason might be a low importance (a low number of votes) of this thread/bug. Therefore: Vote, pls! See bug report for MailNews Core: https://bugzilla.mozilla.org/report.cgi?x_axis_field=bug_status&y_axis_field=votes&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&product=MailNews+Core&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_id=&bug_id_type=anyexact&votes=&votes_type=greaterthaneq&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&emailtype3=substring&email3=&chfieldvalue=&chfieldfrom=&chfieldto=Now&field0-0-0=noop&type0-0-0=noop&value0-0-0=&format=table&action=wrap

(In reply to Zroutik from comment #86) > The reason might be a low importance (a low number of votes) of this > thread/bug. Therefore: Vote, pls! Votes don't help, at all. See bug 250539 (82 votes) and https://getsatisfaction.com/mozilla_messaging/topics/font_markup_problems_in_the_compose_message_window (#2 problem!)

I'd like to have a dev feedback on this bug or on bug 446571 (which is a blocker for this one it seems). Maybe someone could feed us with how he sees the bugs being fixed. We could all work from there. By the way, how bad would the performances be hit by simply applying the simple proposed patch if no one is working on a real fix? If this can save me time in searching through duplicated entries created by Thunderbird and cleaning them up once in a while, I'd go with the patch first and revert it in due time.

A general note: Please remember to follow the etiquette when commenting on bugs. Lots of negative/random comments will actually make it harder for this to be fixed. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html This bug is marked as helpwanted and as wanted for Thunderbird, however it isn't a priority for the core devs to fix at the moment, but we'd support anyone who wants to help fix it. (In reply to Alexandre Demers from comment #88) > I'd like to have a dev feedback on this bug or on bug 446571 (which is a > blocker for this one it seems). I think I'd be fine with either of these being fixed. Although bug 446571 is the "strictly" correct case, I don't think that having different case on the user portion is really used in earnest these days. > Maybe someone could feed us with how he sees > the bugs being fixed. We could all work from there. Comment 74 already has the basics. This would need an additional lower case secondary email column working into the database by adjusting the code in nsAddrDatabase.cpp. It would probably need some sort of migration on first opening as well at a guess. There are unit tests for that code so they could be easily extended. > By the way, how bad would the performances be hit by simply applying the > simple proposed patch if no one is working on a real fix? If this can save > me time in searching through duplicated entries created by Thunderbird and > cleaning them up once in a while, I'd go with the patch first and revert it > in due time. The perf can be bad, depending on the size of your address book and I wouldn't want to compromise users with big address books.

For reference, RFC 5321, section 2.4, 2nd paragraph should be used if someone really wants to follow the book. But let's focus on the end of the paragraph: "However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. Mailbox domains follow normal DNS rules and are hence not case sensitive." So, as suggested, we'll consider the address as a insensitive whole (local-part@domain). First, in the case of collected AB, it doesn't matter really much and will simplify a lot its management. Second, since case sensitivity is discourages, we can't rely on the case of the local-part. Since the issue is not a priority, I'll try to work on this by myself. However, I'm not used to Thunderbird's code nor to Mozilla's in general, but with some help and a bit of elbow grease, I hope to be able to submit a patch at some point in the near future.

Any news?

(In reply to imraro from comment #91) > Any news? Not yet. I've been pretty busy, so I haven't had time to work on it. However, I'm beginning to have a bit of free time, so I should be able to begin working on it. As I said, if someone wants to jump in and do it, they are welcome.

I would appreciate some progress on this. It would help me promoting TB as an Outlook replacement (via DavMail <http://davmail.sourceforge.net/>).

Here is a small pinch of spice on a spiky and decade-old issue... :-) What about recent evolutions in domain names specifications? As far as I know, IDN (http://en.wikipedia.org/wiki/Internationalized_domain_name) as defined in RFC 5890 - 5894, are now supported by all major browsers. Does it means that some future (existing?) RFCs will also promote the use of internationalized email addresses? In fact, offering the possibility of case-sensitive *and* non-ASCII characters in email addresses would seem logical (I am not saying practical, because the same argument goes for IDN). Of course, this opens the door to the great topic of "meta-keyboard interfaces", which is another evolution to come... (For example, the US International keyboard layout is a meta-keyboard interface in the sense that it allows people to type non-existing letters on the keyboard, such as é with a combination of keys, such as CTRL + ' + e).

Adding the lower case index for the 2nd email too. There's a small behavior change in that previously we didn't set display name if missing (and preferred delivery format) in case we found it in the secondary email. (See the emailAddressIn2ndEmailColumn change). That seems like an odd thing to do, so i didn't add more code to check if the address we found was in primary or 2nd email now that it's a bit hidden.

Comment on attachment 8380875 [details] [diff] [review] proposed fix The general idea looks good, but I don't see anything that will migrate/update existing databases, which I think would be a good idea. If we didn't update them, then the way the patch is written it would mean that we don't find any secondary emails in pre-existing dbs.

Actually it does migrate/update, that's what the UpdateLowercaseEmailListName changes are about. Found aproblem there tough. This patch should fix that. At present we don't do further migration if a single lowercase column card is found. For secondary emails that won't work out as the second email is easily missing. So should we just check them all, like this?

Comment on attachment 8381634 [details] [diff] [review] proposed fix, v2 Review of attachment 8381634 [details] [diff] [review]: ----------------------------------------------------------------- Ok, looks great, thanks! ::: mailnews/addrbook/src/nsAbAddressCollector.cpp @@ +128,3 @@ > > nsCOMPtr<nsIAbDirectory> originDirectory; > + nsCOMPtr<nsIAbCard> card = (!aSkipCheckExisting) ? nit: trailing space ::: mailnews/addrbook/src/nsAddrDatabase.cpp @@ +984,5 @@ > else if (IsListRowScopeToken(rowOid.mOid_Scope)) > { > err = GetStringColumn(findRow, m_LowerListNameColumnToken, tempString); > + if (NS_SUCCEEDED(err)) // already set up > + continue; nit: trailing space

https://hg.mozilla.org/comm-central/rev/21be42582181 -> FIXED