In the New E-Mail Account Setup wizard, the e-mail address field is autofilled with <username>@<domainname>. However, on unix systems the domainname used is the YP/NIS domainname, which may not be set for systems not using YP/NIS. The YP/NIS domainname is also not necessarily related to the e-mail address. Currently, xpfe/appshell/src/nsUserInfoUnix.cpp is calling uname to obtain the domainname. It is probably more appropriate to use the DNS domainname, which can be obtained by calling gethostbyname(2) on the result of gethostname(2).
sspitzer owns that file, it seems - or does most work on it. CCing him. Seth - what do you think? Gerv
Created attachment 13248 [details] [diff] [review] Patch to get domain name from DNS lookup rather than NIS/YP domain name
I've been meaning to comment in this for a while. the domainname you get back from uname() is the correct domainname. if your site has configured this to be the same as your NIS domain name, your machine is misconfigured. uname() is not aware of NIS domains, it just so happens that some linux configurations default the system's domainname to the NIS domainname I have a machine at Netscape where the system's dommainname is netscape.com, but our NIS domainname is mcom.com. I'm pretty sure this service defaults the domainname to netscape.com not mcom.com. cc'ing ninoschka to see if she can confirm this (I don't have access to a Linux box right now) to confirm: - type uname -n to confirm that your hostname ends in netscape.com - start mozilla and create a mail account. confirm that the default e-mail address ends in @netscape.com
Mozilla currently uses two results from the call to uname. First it checks utsname.domainname (or __domainname). This value is the value set by setdomainname (as documented in setdomainname(2)). It is also the value returned by domainname(1), which is documented in the man page as being "the systems NIS/YP domain name". This may be a Linuxism. Second, utsname.nodename is checked. This is the value returned by uname -n, and is set in /etc/HOSTNAME on RedHat Linux. This will typically be the fully qualified domainname, but i've seen it set to just the hostname. On the particular configuration I tested on, the domainname wasn't set (__domainname was blank) and the node name was set to the short hostname. In this particular (mis-)configuration, calling gethostname/gethostbyname works, and the others don't. Note that on all Solaris boxes I've seen, utsname.domainname and utsname.__domainname don't exist, so it always falls back on the node name. Finally, its worth noting that the gethostname/gethostbyname also works on Win32, so it could be added to nsUserInfoWin.cpp, where GetDomain is stubbed.
Build 2000-08-17-09M18: Linux 6.0 - I ran "uname -n" and it reports 'laboheme.mcom.com' - Created a new profile, opened Mai, the Wizard opens, Other ISP or email provider is selected, select Next and the Identity panel shows 'firstname.lastname@example.org'
so is this bug Invalid?
Are we still seeing this bug in the latest daily builds?
taking this from alecf, since it is an account manager bug.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I can't test this, the email address is no longer filled in in the account wizard.
Depends on: 59379
*** Bug 59379 has been marked as a duplicate of this bug. ***
actually giving to sspitzer, since he claimed to take it above :)
Assignee: alecf → sspitzer
Status: ASSIGNED → NEW
Ignore my comment above. The account wizard works -- it just doesn't fill in the email address if it doesn't find a domain name or a node name with a dot in it.
marking WONTFIX based on comments above (comment 6, comment 9, comment 12).
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → WONTFIX
On a typical Fedora Core 2 install not using NIS, uname returns __domainname = "(none)" and nodename = "slytherin.foo.com". The current code will use "username@(none)" instead of email@example.com. I think it would make more sense to use nodename before __domainname (I suspect NIS is used in a minority of systems and nodename will be equally valid), or at least ignore a domainname of "(none)".
You need to log in before you can comment on or make changes to this bug.