Last Comment Bug 312818 - Thunderbird requires domain in addresses and doesn't always add default
: Thunderbird requires domain in addresses and doesn't always add default
Status: NEW
:
Product: MailNews Core
Classification: Components
Component: Composition (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 13 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
https://tools.ietf.org/html/rfc5321#s...
: 316720 328843 361962 551668 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-18 02:21 PDT by Max Spicer
Modified: 2016-01-30 21:06 PST (History)
20 users (show)
mscott: blocking‑thunderbird2-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch for turning off e-mail address check (853 bytes, patch)
2006-02-06 23:23 PST, Tilmann Bubeck
no flags Details | Diff | Splinter Review
Allow local emails extension for TB 1.5 (4.18 KB, application/octet-stream)
2006-02-07 08:14 PST, Carl
no flags Details
Allow local emails extension ver 0.2 for TB 1.5 (1.72 KB, application/octet-stream)
2006-02-07 09:15 PST, Carl
no flags Details
Patch of localdomain.xpi to allow compatability with TB > 1.5 (1.72 KB, application/octet-stream)
2006-04-20 12:04 PDT, Will Taillac
no flags Details

Description Max Spicer 2005-10-18 02:21:23 PDT
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 2005-10-18 09:04:45 PDT
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 2005-10-18 12:59:05 PDT
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 2005-11-07 08:54:42 PST
Can anyone else reproduce this bug ?
Comment 4 Aaron Leonard 2005-11-07 09:53:11 PST
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 2005-11-08 10:11:26 PST
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 2005-11-08 10:32:10 PST
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 2005-11-17 04:04:33 PST
*** Bug 316720 has been marked as a duplicate of this bug. ***
Comment 8 Jonathan Amir 2006-01-16 20:34:53 PST
(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 2006-02-01 10:35:12 PST
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 2006-02-01 10:36:32 PST
Carl, just set the pref to go back to the old behavior, problem solved. :)
Comment 11 Aaron Leonard 2006-02-01 10:48:57 PST
> ------- Comment #10 from mscott@mozilla.org  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 "j.bloggs@cisco.com,frobboz,blatz",
which will cause Thunderbird to send the following SMTP commands:

RCPT TO:<j.bloggs@cisco.com>
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 2006-02-01 10:51:44 PST
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 2006-02-01 13:07:43 PST
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 2006-02-06 23:21:40 PST
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 2006-02-06 23:23:58 PST
Created attachment 210983 [details] [diff] [review]
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 2006-02-07 06:21:38 PST
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 2006-02-07 08:14:24 PST
Created attachment 211012 [details]
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 2006-02-07 09:15:52 PST
Created attachment 211017 [details]
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 2006-02-08 05:19:15 PST
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 2006-02-08 06:30:43 PST
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 2006-02-08 14:11:05 PST
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 2006-02-08 21:54:37 PST
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 2006-02-08 22:21:21 PST
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 2006-02-28 12:09:43 PST
*** Bug 328843 has been marked as a duplicate of this bug. ***
Comment 25 Will Taillac 2006-04-20 12:04:33 PDT
Created attachment 219174 [details]
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 2006-04-20 12:09:59 PDT
I'm new to this bugzilla thing, so please pardon the bit of email spam due to my edits. :)
Comment 27 Tilmann Bubeck 2006-09-24 04:53:25 PDT
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 2006-09-25 08:57:02 PDT
> 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 2006-09-25 22:02:06 PDT
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 2006-09-25 23:57:35 PDT
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 2006-09-26 05:35:57 PDT
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 2006-09-26 08:48:46 PDT
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 2006-11-27 11:56:58 PST
(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 2007-10-11 12:54:11 PDT
Is there a version that will install on Thunderbird 2.0.0.6? 
Comment 35 Carl 2007-10-12 06:19:11 PDT
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] 2009-11-29 22:28:45 PST
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 37 Ludovic Hirlimann [:Usul] 2010-03-12 00:40:11 PST
*** Bug 361962 has been marked as a duplicate of this bug. ***
Comment 38 Ludovic Hirlimann [:Usul] 2010-03-12 00:41:42 PST
*** Bug 551668 has been marked as a duplicate of this bug. ***
Comment 39 Karsten Düsterloh 2010-03-12 11:26:16 PST
It's not useful to dupe Core bugs against TB bugs. :(
Comment 40 Karsten Düsterloh 2010-03-19 13:28:25 PDT
Moving to Core as 361962 already was (despite the patch here which tries to fix it in forked file).
Comment 41 Worcester12345 2010-07-27 19:23:17 PDT
Can we add the next release as a milestone?

Note You need to log in before you can comment on or make changes to this bug.