312818 - Thunderbird requires domain in addresses and doesn't always add default

Status: NEW

(Thunderbird :: Message Compose Window, defect)

Description

[Max Spicer]

Since the 1.5 betas, Thunderbird now insists that every recipient for emails has
a domain component.  If I type an email address into the to bar, it
automatically appends my default domain to it.  This is fine (although
unnecessary).  However, if I click on a mailto: link that does not include a
domain component (e.g. <a href="mailto:j.bloggs">Mail Joe</a>), Thunderbird does
not insert the default domain, and then refuses to send the email until I go
back and manually add the domain to _every_ address in the to/cc/bcc fields.  
Within my company it is perfectly valid to send emails to j.bloggs - sendmail
knows this is internal and is more than happy to deliver it.  Consequently, we
have many email links on our intranet etc that send emails to people with no
domain included.  This becomes a real pain with the new Thunderbird builds.  Why
are they insisting on an unnecessary domain component and, more importantly, how
do I make them stop?  I doubt I'm the only corporate user that's likely to get
hit by this one.  We're quite keen to upgrade people to Thunderbird (we
currently use Mozilla), but this would be a bit of a showstopper.

Comment 1

[Scott MacGregor]

just change the default value of:

mail.identity.default.autocompleteToMyDomain to true in your installation of
thunderbird before you deploy it and that will revert you to the old behavior. 

Comment 2

[Max Spicer]

I already have that value set to true.  The autocomplete behaviour does not
apply to addresses that have come in via mailto links.  Try it for yourself!

Comment 3

[Håkan Waara]

Can anyone else reproduce this bug ?

Comment 4

[Aaron Leonard]

Sure, I can reproduce it with little difficulty.

With mail.identity.default.autocompleteToMyDomain set to true,
then if I type a short form address (j.bloggs) into an address pane,
and if I linger with the cursor in that pane (for a much longer time
than I normally type, say 2.5 seconds), then autocompleteToMyDomain
does indeed automagically append "@cisco.com".

However, when I enter multiple addresses, without lingering between them:

To: j.bloggs,j.f.muggs

no appending is done ... and if I let the cursor linger after the "j.f.muggs",
autocompleting is never done.

One very simple way to replicate this problem would be simply to paste
in a buffer of short form addresses - e.g. copy "j.bloggs,j.f.muggs,j.doakes"
and paste it in.

I would like to caution against the temptation to treat this bug as being
resolvable by having autocomplete do its thing more vigorously.  Rather,
post short form addresses, hence rendering autocomplete unnecessary.

Comment 5

[Worcester12345]

Not sure what it was called in Outlook, but can't you have the address book verify or check the email address against what is in it? Not sure if that is any help or a workaround, or what. There should be the option of choosing what you want it to do.

Comment 6

[Aaron Leonard]

Sure, there are LOTS of ways that Thunderbird can use to flesh out email
addresses: address book entries, directory (LDAP) queries, and domain autocomplete.

Domain autocomplete (I assume) is intended to be the last ditch fallback
should the address be found neither in the address book nor in the 
directory.  

HOWEVER, the point of this bug is that domain autocomplete doesn't work 
reliably - and perhaps shouldn't even be necessary, as Thunderbird SHOULD
(optionally) be able to deliver to the mail server unqualified addresses
(and let the server do the qualification.)

Comment 7

[Graeme Bunyan]

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

Comment 8

[Jonathan Amir]

(In reply to comment #6)
In my opinion, there should be a UI option, or at least a hidden pref, to let thunderbird deliver to the mail server unqualified addresses and let the server do the qualification.
Not to mention that there should be a UI option for the mail.identity.default.autocompleteToMyDomain setting, but that's not the real topic of this bug.

I voted for this bug, because I think thunderbird should be able/allowed to send messages with unqualified addresses, although ... it probably should NOT be the default behaviour. I imagine there was a reason that this restricting behaviour was introduced in the first place.

Comment 9

[Carl]

Agreed - this is very annoying when you're using intranet mail. In our situation, even adding the domain on isn't good - our mail server, seeing that the address has a domain, will send it out through an external mail server rather than routing it internally. That leads to a 5-minute delay or so.
At the least, an Advanced Config flag would be good. At this point we are going back to 1.0.7.

Comment 10

[Scott MacGregor]

Carl, just set the pref to go back to the old behavior, problem solved. :)

Comment 11

[Aaron Leonard]

> ------- Comment #10 from [e-mail]  2006-02-01 10:36 PST -------
> Carl, just set the pref to go back to the old behavior, problem solved.  :) 

Nice joke Scott ... of course, there exists no such pref in 1.5 (as you
can see from the thread above, mail.identity.default.autocompleteToMyDomain
is useless here.)

I would like to point out that the 1.5 behavior is not only irksome, but
inconsistent ... if I put "j.bloggs,frobboz,blatz" in the To: panel,
I get the "j.bloggs,frobboz,blatz is not a valid e-mail address" popup.
I can then "correct" the addresss to "[e-mail],frobboz,blatz",
which will cause Thunderbird to send the following SMTP commands:

RCPT TO:<[e-mail]>
RCPT TO:<frobboz>
RCPT TO:<blatz>

So the irritating 1.5 behavior is unsuccessful even by its own lights,
in keeping me from using an unqualified address.

Comment 12

[Carl]

Hi Scott
Thanks - but I tried that - set mail.identity.default.autocompleteToMyDomain to true but I still get the evil "must be of the form user@host" message :-/
Aaron:
Hmm, I still had it...

Comment 13

[John Hupcey]

This is a major annoyance for me. Every intranet e-mail I get comes with unqualified addresses "joe schmoo" <schmoo> and so when I use REPLY with TB 1.5 I have to update EVERY address with the @cadence.com domain. This is a horrendous task when there are more than one or two recipients!   

PLEASE fix this!! Is there any hope that a fix will come soon, or should I regress to 1.06? 

Comment 14

[Tilmann Bubeck]

Here is a (trivial) patch to turn email checking off. Please apply this fix to thunderbird-1.5 as follows:

[root@loeffel ~]# cd /usr/lib/thunderbird-1.5/chrome/
[root@loeffel chrome]# jar xf messenger.jar
[root@loeffel chrome]# patch < turn-off-email-check
[root@loeffel chrome]# jar cf messenger.jar content
[root@loeffel chrome]# rm -rf content

Then restart thunderbird and evrything is fine... :-)

Comment 15

[Tilmann Bubeck]

Attachment: Patch for turning off e-mail address check

Patch to turn off email address checking and allows local e-mails to be send without attaching a domain name.

Comment 16

[Carl]

Tilmann -
Works great - maybe there'll be a toggle to disable these lines in a later release. Thanks a lot!
(I'm on windows, so I just commented the lines out in the jar file. I'd make an extension if I knew how.)

Comment 17

[Carl]

Attachment: Allow local emails extension for TB 1.5

Now that I know a bit more - here is a dirt-simple extension to remove the check for user@host. For TB 1.5 only.

Comment 18

[Carl]

Attachment: Allow local emails extension ver 0.2 for TB 1.5

Rev 0.2 - Revised to only modify CheckValidEmailAddress rather than all of GenericSendMessage - less chance of extension conflicts (I'd imagine).

Comment 19

[Cindy Schott]

Oh how I vexed for this bug to be fixed in my corporate environment!
I (like all other corporate intranet users) had to roll back to TB 1.0.7 which lets the MTA set the intranet domain for all internal email.

TB 1.5 is just not usable in a corporate intranet setting due to this bug.

The problem stems from the fact that TB 1.5 seems to think (erroneously of course) that all corporate users in a sendmail environment actually wish to type in the domain name to every single email address.

That means (hundreds of times a day):
- They repeatedly type the same domain name for every NEW mail recipient
- They repeatedly type the same domain name for every REPLY mail recipient
- They repeatedly type the same domain name for every NEW alias recipient list
- They repeatedly type the same domain name for every REPLY alias recipient list
- They repeatedly type the same domain name for every mailto responded to
etc.

This is just crazy. Especially since they are typing the SAME domain name every time! Hundreds of times a day. Obviously these sendmail based corporate users simply roll back to Thunderbird 1.0.7 or some other usable MUA which doesn't insist on the domain name being set (at least Eudora has the capability to set the domain name and be done with it!). 

Sure, modifying BOTH settings in prefs.js somewhat alleviated the torture:
user_pref("mail.identity.default.autocompleteToMyDomain", true); 
user_pref("mail.enable_autocomplete", true);

But, there is no setting in the Configuration to just set the default domain.
Tools -> Options -> Advanced -> General -> Config Editor 

Luckily, the "patch for turning off e-mail address check" works for me:
a. https://bugzilla.mozilla.org/attachment.cgi?id=211017&action=view
b. Save localdomain.xpi anywhere on your disk
c. Start Thunderbird 1.5 & go to Tools -> Extensions -> Install
d. Select the saved localdomain.xpi extension
Voila!

For the first time since about October 2005, a sendmail user in a corporate domain who has never had to type the domain address in any MUA in 20 years finally can use move from Thunderbird 1.0.7 (which worked correctly) to Thunderbird 1.5! 

By the way, this bug also disallows setting the domain to something other than your local domain. Why would you want this? Assume you're a sales person on domain1 whose customer is a large account on domain2 (or assume you're a yearbook administrator whose students are all on domain2) - the default domain always defaults to YOUR domain which is ridiculous at best.

Fundamentally, two changes should occur:
1) There should be a way to turn OFF insistence on fully qualified addresses:
user_pref("mail.identity.require.fully.qualified.email.address", false); 

2) There should be a setting for _any_ default domain if so desired:
user_pref("mail.identity.default.domain.for.unqualified.addresses", "domain"); 

Every MUA on the planet performs the first task (they let the MTA handle the default domain); and the good MUAs perform the second (e.g., Eudora).

In summary, THANK YOU very much for this patch which now makes Thunderbird 1.5 finally (after months of aggravation to millions of corporate users) usable!

Comment 20

[Cindy Schott]

I should have also noted that even after modifyting BOTH settings in the prefs.js, the REPLY and MAILTO and MULTIPLE COMMA SEPARATED ADDRESSES were _still_ not usable. The two mandatory prefs.js settings alleviated the torture *only* for new emails where the line also only contained ONE item per line.

Also, some folks seem to think that an address lookup server will alleviate the pain but many address servers don't have local or even intranet NIS aliases (they normally just have user names and logins) so the lookup idea is not a viable workaround in a corporate intranet sendmail environment. And, there are many foibles in a lookup server when, exasperatingly, you know the email address but not the proper spelling of the user's name). A ton of wasted time ensues just to get the MUA to figure out the recipient whose email address you knew and typed correctly all along. AuuuurgggghhhH!

Comment 21

[Scott MacGregor]

The problem with the pref not working for everyone who wants this turned off is being tracked in Bug #326280.

re-closing this one. 

Comment 22

[Cindy Schott]

Regarding the closing of this bug in favor of bug 26280 I'm just fine with the localdomain.xpi extension from Carl that turns off the check for a fully qualified domain name (FQDN) but I would like to comment that bug 26280 seems related to autocomplete while this bug (312818) has nothing, per se, to do with autocomplete. 

The problem in this bug (312818) is that TB 1.5 wasn't allowing unqualified (i.e., local addresses) to get to the MTA. This really has nothing to do with autocomplete (or with sendmail). Autocomplete is just a workaround to the problem that didn't exist in the first place if the TB 1.5 MUA would just pass the MTA the address as it was entered by the user. 

Note that the MTA will normally check to see if the address or alias is valid and will properly elicit an error so mistakes can't be made (e.g., when you type junk in the address field such as "abcdefg" assuming that is not a valid login or alias).

In summary, this problem has nothing to do (IMHO) with autocomplete; it has all to do with allowing an unqualified address to be sent to the MTA.

Comment 23

[Joal Taylor]

I agree completely with Cindy's post. The referenced bug is unrelated. Even if if turning off autocomplete was 100% reliable, you would still get an error insisting that the mail address contain '@host'. Frustrating if you know perfectly well that this is unnecessary.

There is a workaround, so I understand if it's low priority. But it's not fixed.

Sample error message: 'fred is not a valid e-mail address because it is not of the form user@host. You must correct it before sending the email'.

Cindy's suggested changes seem reasonable.

Comment 24

[Magnus Melin [:mkmelin]]

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

Comment 25

[Will Taillac]

Attachment: Patch of localdomain.xpi to allow compatability with TB > 1.5

Patch of localdomain.xpi to allow compatability with FF > 1.5.
This is Carl's work, I simply modified the install.rdf's <em:maxVersion> to 1.6 to allow compatability with the 1.5.0.2 release (and beyond).

Comment 26

[Will Taillac]

I'm new to this bugzilla thing, so please pardon the bit of email spam due to my edits. :)

Comment 27

[Tilmann Bubeck]

I wonder, why this bug is closed as "FIXED"? Everybody on this bug entry agrees, that this is a bug and that the bug could not be resolved by changing any preferences.

There are two solutions attached to this list but both are not included in the official thunderbird.

Why are the attached solutions not applied?

Is there anybody agreeing with me or is there anybody disagreeing? Should the bug entry "re-opened"?

Thanks for any additional comments.

Comment 28

[Aaron Leonard]

> Is there anybody agreeing with me or is there anybody disagreeing? Should the
> bug entry "re-opened"?

I agree; this bug was never fixed and should be reopened.  I guess the
urgency has been mitigated by the availability of the localdomain.xpi
extension.

Comment 29

[Tilmann Bubeck]

localdomain.xpi is nice but no real solution:
 * it has to be applied manually (instead of being part of Thunderbird)
 * I did not manage to use --install-global-extension with this plugin
   so in a multi user environment (linux) every user has to apply this
   patch on his own (which is impossible for a "normal" user).

So, if there are a few more users seeing the current Thunderbird as "buggy", please enter your comment!

Comment 30

[Max Spicer]

Adding endless comments to this bug will not help, I'm afraid.  All it will do is make people less likely to monitor this bug.  I do agree that this bug should be fixed, but bugzilla is not the place to do the campaigning.  A much better place would be the Mozillazine forums - http://forums.mozillazine.org/.

Comment 31

[Max Spicer]

This bug is not fixed in 1.5.07 so I'm reopening it again (apologies if it's fixed in the trunk).

To reproduce:
- enter mailto:j.bloggs in your browser and press enter
- click Send in the resulting Thunderbird compose window

You are forced to enter a domain component.  No amount of fiddling with mail.identity.default.autocompleteToMyDomain will change this situation.  In order to use Thunderbird 1.5, our organisation had to rewrite all our mailto links to include our domain - this is clearly not the way forward.

Reopening this bug is all I can do in bugzilla to get people's attention.  Please avoid comment spam - it will only hinder!

Comment 32

[Mike Cowperthwaite]

Max Spicer, was it ever a problem for you that the domain was required (as Carl talked about back in comment 9, which is when this bug got derailed) or only that it didn't get auto-appended when you clicked a mailto with a nonqualified address?  Did you ever see any other means of getting the nonqualified address in place?

Comment 4 -- failure to autocomplete when entering multiple addresses on a single line -- is a known issue, but I can't find the bug at this time.  The widget does not handle multiple addresses well; instead of typing a comma, type Return and go to the next field.

Comment 33

[Mike Cowperthwaite]

(In reply to comment #32)
> Comment 4 -- failure to autocomplete when entering multiple addresses on a
> single line -- is a known issue, but I can't find the bug at this time.  

Bug 348825

Comment 34

[John Hupcey]

Is there a version that will install on Thunderbird 2.0.0.6? 

Comment 35

[Carl]

This bug report is not an up to date source for the workaround extension. To get the xpi, go to https://addons.mozilla.org/en-US/thunderbird/addon/2030

Comment 36

[[:Aureliano Buendía]]

Confirmed also here on

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091129 Lightning/1.0b1pre Shredder/3.0.1pre ID:20091129032743

with mail.identity.default.autocompleteToMyDomain = true when use a mailto link.

Comment 39

[Karsten Düsterloh]

It's not useful to dupe Core bugs against TB bugs. :(

Comment 40

[Karsten Düsterloh]

Moving to Core as 361962 already was (despite the patch here which tries to fix it in forked file).

Comment 41

[Worcester12345]

Can we add the next release as a milestone?