Closed Bug 1159448 Opened 5 years ago Closed 5 years ago

Thunderbird ignores proxy settings on POP3S protocol


(Thunderbird :: Preferences, defect)

Not set


(thunderbird38+ fixed, thunderbird39 fixed, thunderbird40 affected, thunderbird41 fixed, thunderbird_esr31 unaffected)

Thunderbird 41.0
Tracking Status
thunderbird38 + fixed
thunderbird39 --- fixed
thunderbird40 --- affected
thunderbird41 --- fixed
thunderbird_esr31 --- unaffected


(Reporter: brovkin_ufo, Assigned: rkent)




(2 files)

Attached file full clean profile
User Agent: Mozilla/5.0 (Windows NT 5.2; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150427090451

Steps to reproduce:

Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:40.0) Gecko/20100101 Thunderbird/40.0a1
OS: Windows 2012 Server x64 Datacenter

1. Clean install Thunderbird from nightly (trunk).
2. Open preferences and setup proxy. Same proxy for all protocols.
3. Setup e-mail account for testing.
4. See in firewall that Thunderbird IGNORES (!) proxy setup and connect to POP3S server directly.

This bug does not exist in Thunderbird 31.6.0.
There is no plugins or addons, just CLEAN install and CLEAN profile. There is no any settings in about:config.

user_pref("network.proxy.http", "");
user_pref("network.proxy.http_port", 9050);
user_pref("network.proxy.no_proxies_on", "");
user_pref("network.proxy.socks", "");
user_pref("network.proxy.socks_port", 9050);
user_pref("network.proxy.ssl", "");
user_pref("network.proxy.ssl_port", 9050);
user_pref("network.proxy.type", 1);

Actual results:

Thunderbird skips proxy settings and connect to POP3S server directly.

Expected results:

Thunderbird connect to POP3S server via socks 5 proxy.
OS: Unspecified → Windows
Hardware: Unspecified → x86_64
Thanks for reporting this. There were changes in proxy management in Thunderbird 38 due to changes in the Mozilla core code, but the expectation is that it continues to work. Not working would be a significant regression.

I would appreciate if someone could confirm if this is indeed an issue.
There are a number of new proxy bug reports in the past year
I set the SSL proxy to and the Socks to

Result: POP3(S) reception still works, IMAP(S) fails, sending SMTP(S) fails.
Ever confirmed: true
Summary: Thunderbird ignores proxy settings on POP3S and SMTPS protocols → Thunderbird ignores proxy settings on POP3S protocol
So the issue is this. The POP3 service is running a URL with the scheme pop3: but the registration of the protocol handler of the service is registered as pop: in


nsIOService looks up the protocol handler, which is supposed to have the ALLOWS_PROXY flag, here:

        contractID += scheme;

        rv = CallGetService(contractID.get(), result);
        if (NS_SUCCEEDED(rv)) {
            CacheProtocolHandler(scheme, *result);

When the lookup fails, the protocol handler defaults to the external protocol handler which does not allow proxies.

What I don't know is if this is a recent regression, or if this problem has existed for a long time.
Now in MsgExamineForProxy (Called by nsPop3Protocol.cpp) we pass use the underlying URL for the scheme:

    nsCOMPtr<nsIProxyInfo> proxyInfo;
    rv = MsgExamineForProxy(this, getter_AddRefs(proxyInfo));
    if (NS_FAILED(rv)) proxyInfo = nullptr;

Previously we passed in explicitly a scheme to use:

    nsCOMPtr<nsIProxyInfo> proxyInfo;
    rv = MsgExamineForProxy("pop", hostName.get(), port, getter_AddRefs(proxyInfo));

This is all a regression from bug 791645 which was one of those cases where we had to workaround changes in the core code.

I wonder what workarounds others would accept? Previously it seems like the code created URLs specifically for the purpose of looking up proxyInfo. I think that is probably the best thing to do, mapping the actual URL to the lookup URL in MsgExamineForProxy.  I at least need to map pop3 -> pop, I'll have to check SMTP because previously it had a similar issue between mailto and smpt.

I don't really understand why in the first place the code uses pop3: urls but registers pop:  I don't do that in ExQuilla, there is just exquilla: and exquilla-message: My opinion is that trying to fix that at this point in time is too risky, but the "fix it" could include either 1) registering pop3 instead of pop or 2)registering both pop: and pop3: pointing to the same implementation.
    if (NS_FAILED(rv)) proxyInfo = nullptr;

So that is where the "pop" came from instead of "pop3" which is the scheme of the URL.
Blocks: 791645
I don't really have a way to test POP3 proxies other than doing what Jorg did, which was to put bogus entries for the proxy, and make sure that proxies fail for POP3 when enabled.

This patch passes that "test" and in addition I can confirm in the debugger that DeprecatedBlockingResolve is properly returning the protocolInfo from the POP3 service, including the ALLOWS_PROXY flag.

I like this approach because 1) It seems to me to be fairly low risk, which we need for a late fix to the upcoming Thunderbird 38, 2) it does not introduce any new kludge. Long-term I think that a better fix would be to change the protocol name everywhere to either "pop" or "pop3" but I am not sure of the regression potential for that, hence I am hesitant.
Assignee: nobody → rkent
Attachment #8603481 - Flags: review?(neil)
Comment on attachment 8603481 [details] [diff] [review]
Register pop3 as a synonym for pop

Seems reasonable to me.
Attachment #8603481 - Flags: review?(neil) → review+
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 41.0
Comment on attachment 8603481 [details] [diff] [review]
Register pop3 as a synonym for pop

Landed on comm-beta THUNDERBIRD_38_VERBRANCH
Attachment #8603481 - Flags: approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.