Closed
Bug 913785
Opened 11 years ago
Closed 11 years ago
fqdn for smtp server name not accepted
Categories
(MailNews Core :: Account Manager, defect)
Tracking
(thunderbird25 fixed, thunderbird_esr2425+ fixed)
RESOLVED
FIXED
Thunderbird 26.0
People
(Reporter: bjoern, Assigned: aceman)
References
Details
Attachments
(1 file, 1 obsolete file)
3.70 KB,
patch
|
neil
:
review+
standard8
:
approval-comm-beta+
standard8
:
approval-comm-esr24+
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 2013081600
Steps to reproduce:
I see the smtp server DNS name being resolved with DNS search list. To stop this I tried setting the SMTP server in the settings as FQDN, e.g. not "smtp.gmail.com" but "smtp.gmail.com." (with trailing dot).
Actual results:
the trailing dot is not accepted and thunderbird says "Please enter a valid server name."
Expected results:
The FQDN "smtp.gmail.com." should be accepted and be used correctly so that smtp.gmail.com.dns.searchlist is not being tried.
same for imap server settings. editing the server in the advanced config editor works, just the gui refuses to accept the fqdn.
and even if the fqdn is entered in ther config editor the bug #134402 pops in and prevents certificate name matching. :-|
I do not really understand what you are trying to do. What is wrong with DNS resolving smtp.gmail.com ? Can you elaborate on that?
"smtp.gmail.com." does not seem to be a valid hostname per the RFC we implement (see bug 80855). Do you know any application that accepts such hostnames?
If this form is generally accepted in apps, and if it does actually work to be resolved in gecko core networking, we may allow it too.
Component: Preferences → Account Manager
if upstream nameserver is unreachable or has a failure then the DNS search list is being appended to the DNS name. If the search list contains "example.com mycompany.example.com" then smtp.gmail.com.example.com and smtp.gmail.com.mycompany.example.com would be looked up also.
The trailing dot/period at the end of the hostname prevents the DNS searchlist being appended to the DNS name because the host name with tailing dot is by definition an absolute FQDN. This still seems to be a not widely known fact though, there are some bugzilla bugs, where developers say that this is an invalid host name. This is actually a valid AND nonambiguous host name.
From RFC 1034:
--snip--
Relative names are either taken relative to a well known origin, or to a
list of domains used as a search list. Relative names appear mostly at
the user interface, where their interpretation varies from
implementation to implementation, and in master files, where they are
relative to a single origin domain name. The most common interpretation
uses the root "." as either the single origin or as one of the members
of the search list, so a multi-label relative name is often one where
the trailing dot has been omitted to save typing.
...
Since a complete
domain name ends with the root label, this leads to a printed form which
ends in a dot.
...
The most common interpretation
uses the root "." as either the single origin or as one of the members
of the search list, so a multi-label relative name is often one where
the trailing dot has been omitted to save typing.
--snap--
See also wikipedia:
--snip--
DNS root domain is unnamed, which is expressed by an empty label, resulting in a domain name ending with the dot separator. However, many DNS resolvers process a domain name that contains a dot in any position as being fully qualified
--snap--
Also Microsoft does it right (http://technet.microsoft.com/en-us/library/cc958812.aspx):
--snip--
The trailing period ( . ) denotes that this is an FQDN with the name relative to the root of the domain namespace. The trailing period is usually not required for FQDNs and if it is missing it is assumed to be present.
--snap--
I hope we can agree that the trailing dot in fqdn's is a standard now. To test this you can put "example.com" into your DNS search list. Then:
nslookup www (resolves www.example.com)
nslookup www.example.com. (resolves www.example.com)
nslookup www. (fails because it is fqdn and the search list is not used)
If I know programs that support this? Yes almost all programms do. "curl www" gets www.example.com while "curl www." gets nothing.
I don't say that Mozilla should put the period at the end by default in this case but if someone puts the FQDN dot there intentionally to prevent lookups like smtp.gmail.com.example.com then Mozilla should not say that this is not right but accept it.
Thanks for a great explanation. At least Firefox seems to support the trailing dot too. E.g. inputting www.google.com. works fine (on Win XP), the site even does the standard redirection to www.google.<country> .
It looks like there should be no harm in allowing this form.
Neil, what do you think?
Comment 8•11 years ago
|
||
Comment on attachment 804619 [details] [diff] [review]
patch
Doesn't \.? work?
Updated•11 years ago
|
OS: Linux → All
Hardware: x86 → All
Yes it does.
Attachment #804619 -
Attachment is obsolete: true
Attachment #804619 -
Flags: review?(neil)
Attachment #804999 -
Flags: review?(neil)
Updated•11 years ago
|
Attachment #804999 -
Flags: review?(neil) → review+
Assignee | ||
Comment 10•11 years ago
|
||
Thanks.
Keywords: checkin-needed
Product: Thunderbird → MailNews Core
Comment 11•11 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 26.0
Assignee | ||
Comment 12•11 years ago
|
||
Comment on attachment 804999 [details] [diff] [review]
patch v2
[Approval Request Comment]
Regression caused by (bug #): bug 80855
User impact if declined: some valid hostnames may be incorrectly rejected, mostly for enterprise users utilizing features of DNS.
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): none known
This is expected fallout from bug 80855. I propose we land tweaks like this also in the stable branch (24.0.x)
Attachment #804999 -
Flags: approval-comm-beta?
Attachment #804999 -
Flags: approval-comm-aurora?
Comment 13•11 years ago
|
||
Comment on attachment 804999 [details] [diff] [review]
patch v2
Already on aurora, so we'll land on beta, and get out onto 24 later.
Attachment #804999 -
Flags: approval-comm-esr24?
Attachment #804999 -
Flags: approval-comm-beta?
Attachment #804999 -
Flags: approval-comm-beta+
Attachment #804999 -
Flags: approval-comm-aurora?
Comment 14•11 years ago
|
||
status-thunderbird25:
--- → fixed
Comment 15•11 years ago
|
||
Comment on attachment 804999 [details] [diff] [review]
patch v2
I landed this on comm-esr24 now as we'll probably land it anyway, and I wanted to give the tree a bump to test some other things:
https://hg.mozilla.org/releases/comm-esr24/rev/f078c31148c3
Attachment #804999 -
Flags: approval-comm-esr24? → approval-comm-esr24+
Updated•11 years ago
|
status-thunderbird_esr24:
--- → fixed
tracking-thunderbird_esr24:
--- → 25+
Reporter | ||
Comment 16•11 years ago
|
||
did you actually try that this works? bug #134402 should be a blocker for this bug. At least with my test with Thunderbird 24 changing the server name to FQDN not via GUI but via config editor I was told by thunderbird, that the ssl certificate for *.google.com does not match the host "smtp.gmail.com."
Depends on: 134402
Assignee | ||
Comment 17•11 years ago
|
||
This patch does not fix bug #134402, that is a separate problem I can't fix.
But this patch should allow inputting FQDN in the UI. However the patch is not in TB24, will be in 24.0.1.
You need to log in
before you can comment on or make changes to this bug.
Description
•