Open Bug 1175051 Opened 5 years ago Updated 5 months ago

PAC/socks proxy not used for TB38 IMAP

Categories

(MailNews Core :: Networking, defect)

x86_64
macOS
defect
Not set

Tracking

(thunderbird_esr38? affected)

Tracking Status
thunderbird_esr38 ? affected

People

(Reporter: kistel, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file, 1 obsolete file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.81 Safari/537.36 OPR/30.0.1835.59

Steps to reproduce:

Install TB 38.0.1


Actual results:

The new version seems to make a direct network connection to the (IMAP) server, ignoring the proxy PAC (sock5 in my case) configuration. This breaks in my case as there's a firewall in between -- the only way to access the service is via an SSH tunnel and a socks proxy in that (dynamicforward).

The direct connection attempt is confirmed by a firewall warning (Little Snitch), and fails, as it should.

Changing / re-applying the network preferences did not solve the problem. Downgrading to the previous version (31.7.0) did.



Expected results:

The PAC settings should be used as before, and connections should be attempted according to the configuration defined therein.

For the record, my PAC file looks approximately like:


function FindProxyForURL(url, host)
{
  if( dnsDomainIs(host, ".example.net") || isInNet(host, "10.0.0.0", "255.0.0.0") ) {
    return "SOCKS localhost:8888";
  }

  return "DIRECT";
}

The above config works well in TB31 and also in FF38.
OS: Unspecified → Mac OS X
Hardware: Unspecified → x86_64
Severity: normal → major
Component: Preferences → Security
Keywords: regression
Summary: PAC/socks proxy not used in TB38 → PAC/socks proxy not used for TB38 IMAP
I wish there was a "networking" component as this belongs there much more than to security or preferences.
Component: Security → Networking
Product: Thunderbird → MailNews Core
This bug needs someone to test and confirm.
Stefano or Eddy, is this something you can test?
Flags: needinfo?(sf)
Flags: needinfo?(eddy_nigg)
Sorry but I can't test it
Flags: needinfo?(sf)
Is there something more I can do? Of course it wouldn't be an independent test.

How can I tell if TB even tries to load the PAC file, or if it's using it? Is there a way to make it log network connections it makes?
Is the PAC file on the computer or on the network? If networked, how is it written?
Attach a screenshot of your proxy settings if you can.

With foxyproxy that I work with, we had this reported http://forums.getfoxyproxy.org/viewtopic.php?f=4&t=1532
Are your addons close to something like that?
Flags: needinfo?(kistel)
(In reply to Jesper Hansen from comment #6)
> Is the PAC file on the computer or on the network? If networked, how is it
> written?
> Attach a screenshot of your proxy settings if you can.

I pasted the config into the original ticket (comment 0 I guess, it's on the top of this page)

> With foxyproxy that I work with, we had this reported
> http://forums.getfoxyproxy.org/viewtopic.php?f=4&t=1532

No, I'm not using foxyproxy (does that even work in TB?)

> Are your addons close to something like that?

The only extension I have is Enigmail, which is unlikely to interfere.
(In reply to Jesper Hansen from comment #6)
> Is the PAC file on the computer or on the network? If networked, how is it
> written?

I overlooked this question: it's a local file in $HOME, nothing special about it.
Flags: needinfo?(kistel)
For the record: the behaviour of 31.7.0 is also strange.

When starting up TB, it tries to connect directly to the imap server, ignoring the proxy.pac file contents. In my case that doesn't work (which is why this bug was opened in the first place)., so the connection times out, I get an error. But then, when pressing "get new messages" button, or just clicking on the inbox, everything works fine, the proxy IS used, and I get access to mail.

So it seems like that in 31.7 there's a race condition of some kind: upon startup connections are made while (or even before) the network settings are loaded. 

The original bug still exists in 38.1 -- the above workaround doesn't help, reloading the proxy file doesn't help, turning on the proxy and then back on again doesn't help either.
Possibly related to bug 351163
Yes, it's related and in fact may be the same issue. It's not fixed after *nine years* :-o
See Also: → 791645
I can confirm this. Tried using the same proxy.pac, which I already use (successfully) with Firefox, to no avail.

Inserted a debugging alert() into the function -- it is never brought up. Evidently, the function is never invoked. According to tcpdump, thunderbird attempts to talk to the IMAP-server directly instead of going through the proxy.

> It's not fixed after *nine years* :-o

Make that 10. Thunderbird, quite evidently, is an unloved step-child of the Mozilla Foundation...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(eddy_nigg)
This, what I use here with Firefox. I substituted the remote domain-name with "example", but that's it.

Trying to use the same to access imap.example.net does not work -- the function is never invoked.
Attachment #8802573 - Attachment is obsolete: true
See Also: → 351163
> See Also: → bug 351163

The other related problem is with connections to LDAP-directories. These connections also bypass proxy-settings: Bug 218909. I would've added it to "See Also" but don't seem to have sufficient permissions.

Only 13 years old, so can still wait. Interestingly, retrieving e-mail via SOCKS5 was working back then (and even in 2011, according to my own comment on that ticket)...
Severity: major → normal
Depends on: 351163
See Also: 351163

IIUC, this bug is about prefs/advanced/network/ "automatic proxy configuration", right?

You are using a local file, and a file:/// URL, right?

Does it make any difference if the proxy URL is file:/// or something else?

Is this bug specific to using automatic PAC configuration?
Does socks proxy work if you use a manual proxy configuration?

You need to log in before you can comment on or make changes to this bug.