Open Bug 351163 Opened 14 years ago Updated 10 months ago

Thunderbird bypasses proxy.pac for first connection to IMAP

Categories

(MailNews Core :: Networking, defect)

1.9.1 Branch
x86
All
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: raghu1111, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [workaround: comment 20])

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060808 Fedora/1.5.0.6-2.fc5 Firefox/1.5.0.6 pango-text
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.6) Gecko/20060808 Fedora/1.5.0.6-2.fc5 Firefox/1.5.0.6 pango-text


I have a 'auto proxy configuration (PAC file)' set up for for IMAP server. It retuns a SOCKS proxy running on localhost.

The problem is that for the first connection to IMAP when I start up, TB tries to connect to IMAP directly bypassing PAC file. I have checked tcpdump to confirm this. It fails with 'timeout connecting to server'. Next attempt succeds and TB works normally. It looks as though TB tries to connect before it loads the pac file.

This problem exists both on Linux and XP.



Reproducible: Always

Steps to Reproduce:
1. Set a proxy (for socks proxy you can use 'ssh -D 1080 server')
2. Set up pac file (e.g. " function FindProxyForURL(url, host)
 { return "SOCKS 127.0.0.1:1080"; }
3. Start up TB. It fails to conenct to the server.



Expected Results:  
TB should not bypass pac file.

Let me know if you need more info.
OS: Linux → All
Does this happen every time you start up TB? I'm not sure what causes us to try to load the PAC file but I thought it was in the core networking code.
This happens every time. Also IMAP config is set to use SSL, not sure if SSL is part of core networking. The problem does not exist if I set the proxy directly without using pac file.
This happens to me too. I'm using PAC file, IMAP, but no SSL. Every time I start Thunderbird (2.0.0.4) I get an error box saying it couldn't connect to the imap server (connection refused, firewall actively refuses connections). Any connection after that works fine.
Reproduced with:
Thunderbird 3.0a1pre (2007082104)

This is indeed a very annoying error.
This also affects SMTP.

IMHO the fact that Thunderbird potentially bypasses a SSH tunnel (for IMAP or SMTP) makes this a SECURITY PROBLEM allowing an MITM attack on data which would normally run through the secure tunnel.
I have created a workaround for this bug which I attach here. Use at your own risk (it works for me). It is a simple oneliner which reloads proxy.pac after startup, which seems to solve the problem.
Mostly it is a simple oneliner which reloads proxy.pac after
startup, which seems to solve the problem.
Duplicate of this bug: 318872
Assignee: mscott → nobody
I don't use a pac file. I just put in the proxy directly (localhost / 8099 which is an SSH tunnel). This proxy works fine in Firefox, but not Thunderbird. It always tries to connect to my mailboxes by directly connecting to the internet, even though I have "use this proxy for all  checked.

I had this problem a few months ago which is why I uninstalled Thunderbird. The proxy dialog simply doesn't work or do anything at all for me. I recently tried again with the same problem.

Version: 2.0.0.19 (20081209) / WinXP
Can someone follow the instructions at https://wiki.mozilla.org/MailNews:Logging and provide the imap.log file as an attachment to this bug ?
Component: General → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: general → networking.imap
Version: unspecified → 1.9.1 Branch
Whiteboard: DUPME
Attached file IMAP log (level 5)
I set NSPR_LOG_MODULES=imap:5
I also cleaned my e-mail address from the log. 
There's not much in the log. It should be using a localhost proxy at port 8099. Is there another module I should enable for network traffic/connections?
I switched to a SOCKS v4 Proxy and Thunderbird works fine now. I should have known better: You can't tunnel IMAP over an HTTP proxy.
This should be filed under Networking, not Networking:IMAP, since it affects SMTP as well. (did not check POP3)
(In reply to comment #13)
> This should be filed under Networking, not Networking:IMAP, since it affects
> SMTP as well. (did not check POP3)

Care to attach smtp logs to the bug too ?
Component: Networking: IMAP → Networking
QA Contact: networking.imap → networking
Attached file SMTP log
Here's a log file with NSPR_LOG_MODULES=smtp:5

Since it only logs information on protocol level, it seems to me that this is not much use in diagnosing problems at the connection/proxy level.
Hint: people working on this bug can easily reproduce it on their own Windows or Linux machine with a local SOCKS proxy, for example Proxymini from http://aluigi.org/mytoolz.htm
Duplicate of this bug: 358216
Whiteboard: DUPME
xref bug 457377
Status: UNCONFIRMED → NEW
Ever confirmed: true
hello, why does this bug still exist?
The updated version of the workaround for this bug (small extension for Thunderbird and SeaMonkey) is now available from AMO: https://addons.mozilla.org/de/thunderbird/addon/reloadpac/

Hopefully this bug will be fixed real soon now, so this workaround will no longer be necessary.
Cannot confirm on TB 38.2.0. Has been fixed?
I do confirm this bug on TB 38.2. Actually, It's worse on 328 than it was on 31.7 -- in 31.7 the second try works (i.e. start up TB, it fails, then trying get new mail works) whereas in 38.x it fails constantly, in my experience.
Trying to keep this alive: this 9+ years (!) old bug keeps me from upgrading from 37.x because I'd no longer be able to read mail. I doubt I'm the only one.

What's an acceptable time-to-fix? Is it ok if I wait a year more then celebrate 10 years by whining again? 

Of course "Hopefully this bug will be fixed real soon now" :-)
It's worse in version 38 because of bug 1175051
Whiteboard: [workaround: comment 20]
See Also: → 1175051
Blocks: 1175051
See Also: 1175051
You need to log in before you can comment on or make changes to this bug.