Closed Bug 913785 Opened 11 years ago Closed 11 years ago

fqdn for smtp server name not accepted

Categories

(MailNews Core :: Account Manager, defect)

defect
Not set
normal

Tracking

(thunderbird25 fixed, thunderbird_esr2425+ fixed)

RESOLVED FIXED
Thunderbird 26.0
Tracking Status
thunderbird25 --- fixed
thunderbird_esr24 25+ fixed

People

(Reporter: bjoern, Assigned: aceman)

References

Details

Attachments

(1 file, 1 obsolete file)

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?
Status: UNCONFIRMED → NEW
Depends on: 80855
Ever confirmed: true
Flags: needinfo?(neil)
Seems reasonable to me.
Flags: needinfo?(neil)
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → acelists
Status: NEW → ASSIGNED
Attachment #804619 - Flags: review?(neil)
Comment on attachment 804619 [details] [diff] [review] patch Doesn't \.? work?
OS: Linux → All
Hardware: x86 → All
Attached patch patch v2Splinter Review
Yes it does.
Attachment #804619 - Attachment is obsolete: true
Attachment #804619 - Flags: review?(neil)
Attachment #804999 - Flags: review?(neil)
Attachment #804999 - Flags: review?(neil) → review+
Thanks.
Keywords: checkin-needed
Product: Thunderbird → MailNews Core
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 26.0
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 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?
See Also: → 916281
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+
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
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.

Attachment

General

Creator:
Created:
Updated:
Size: