Hide Forgot
Steps 1. Log into the system and connect to a corporate network 2. Start Thunderbird (configured with kerberos, not sure if it makes a difference) 3. Check mail - works fine 4. Close a lid and go to a coffee shop that requires you to accept wireless connection via a browser. 5. Log in offline. 6. Establish wireless connection 7. In the browser accept the connection (you might have to restart FireFox - which IMO is a FF bug. 8. Establish VPN connection 9. Start using the Thunderbird again Expected: Thunderbird continues to work fine Actual: You have to restart Thunderbird as it seems to fail to resolve the name of the server. Observation: It seems to cache names in some way and but the DNS server provided by the coffee shop and by organization usually not related to each other. May be it is the bug in the underlying DNS resolution layer.
Since RHEL 6.3 External Beta has begun, and this bug remains unresolved, it has been rejected as it is not proposed as exception or blocker. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
Does it affect Thunderbird only? Because Firefox and Thunderbird shares the same code. Which package versions do you use?
(In reply to comment #4) > Does it affect Thunderbird only? Because Firefox and Thunderbird shares the > same code. Which package versions do you use? Well, I do in fact suffer this issue in Firefox. Which is why within Firefox I use the DNS Flusher add-on. If I had found a similar plugin for Thunderbird, I would have installed it as well :) Cliff
Does it help if you swith offline/online mode? In File/Offline. It should reload the network settings.
My initial report in step 7 mentions that I have to restart FF. So yes FF has the same issue. Thunderbird/3.1.18 on RHEL6 Firefox/3.6.26
Still exists on thunderbird-24.7.0-1.fc20.x86_64. Slightly simpler scenario I got a call on: Thunderbird was connected to smtp.example.com with an internal IP (10.) onsite. Going offsite (residential cable modem), connections to smtp.example.com fail (verified with packet dump), as it's trying to connect to the internal address still. Even after four days, no DNS expiration happneed. Quitting Thunderbird and restarting it immediately cleared up the problem. For an unknown reason the connection to imap.example.com for inbound mail did not suffer the same symptom. Perhaps there's a check in the IMAP code that got accidentally omitted from the SMTP code? I notice that Thunderbird is savvy about network changes (guess: dbus messages?) so perhaps that's where/when it's fixing up its IMAP DNS?
Reporter, after the DNS change, can you try to clear it? in Menu Tools -> Clear Recent History... and select "Cache". You can also set those values in about:config: network.dns.disablePrefetch = true network.dnsCacheExpiration = 0
Note: The about:config values in Thunderbird can be found in Menu, Edit -> Preferences -> Advanced -> General tab -> Config Editor button.
(In reply to Martin Stransky from comment #14) > Reporter, after the DNS change, can you try to clear it? in Menu Tools -> > Clear Recent History... and select "Cache". > > You can also set those values in about:config: > > network.dns.disablePrefetch = true > network.dnsCacheExpiration = 0 The work around I use is turning "work offline" on and then "work offline" off and the DNS seems to be re-read and things usually start working again. Sometimes I need to do it couple times but it is probably because I am inpatient and it takes time to figure out what DNS server is the right one in the resolv.conf.
(In reply to Martin Stransky from comment #14) > Reporter, after the DNS change, can you try to clear it? in Menu Tools -> > Clear Recent History... and select "Cache". > > You can also set those values in about:config: > > network.dns.disablePrefetch = true > network.dnsCacheExpiration = 0 I do not see dnsCacheExpiration I see dnsCacheExpirationGracePeriod is this the same thing?
You need to add the "network.dnsCacheExpiration" as a new integer value, it's not exposed by default. Default DNS expiration time is 120 sec now. You can also lower the dnsCacheExpirationGracePeriod.
(In reply to Martin Stransky from comment #18) > You need to add the "network.dnsCacheExpiration" as a new integer value, > it's not exposed by default. Default DNS expiration time is 120 sec now. > > You can also lower the dnsCacheExpirationGracePeriod. Apparently Dmitri won't be replying any time soon: "I am now used to getting offline and online and this fixes the problem pretty fast. Sometimes I need to restart TB. Overall IMO TB should detect network changes itself like SSSD does and adjust accordingly. .... I just do not have time to test, sorry." Flipping preferences is rather trivial - most unfortunate it won't be tested.
This Bugzilla has been reviewed by Red Hat and is not planned on being addressed in Red Hat Enterprise Linux 6 and therefore will be closed. If this bug is critical to production systems, please contact your Red Hat support representative and provide sufficient business justification.