Mail.app 3.6 won't connect to my POP3 server over a proxy

Question

I updated to 10.5.7 the other day, and now Mail.app will not connect to my POP3/SMTP server via my proxy. This is a big problem for me as I work remotely a lot.
My setup - I use Proxifier (www.proxifier.com) and an SSH proxy so I point my Mail.app at the 192.168.* local address of my POP3 server on my home network. Whether I'm physically on the 192.168.* network, or remote but running Proxifier, Mail.app 3.5/10.5.6 would work flawlessly, as would any other application that addressed my local network (e.g., RDC).
Since upgrading to Mail.app 3.6/10.5.7, however, Mail.app will not connect when I'm using the proxy, but works fine when I'm physically connected to that network; it thinks that the servers is offline (even when using the Connection Doctor). All other TCP/IP applications including RDC continue to work fine via proxy. In particular, I can still use "telnet 192.168.x.y 110" and connect correctly to my POP3 server (and interact with it using the POP3 command set), so the issue would appear to be in Mail.app rather than in the connection itselof.
Since Proxifier only proxifies TCP and not UDP connections, is it possible that Mail.app 3.6 now attempts a UDP connection to a mail server to check if it's alive before trying TCP? If that's the case, can it be disabled? I don't know of any requirement that POP3 servers must be able to respond to UDP. Or is there a way I can drop back to 3.5 which DID work?
Thanks. Jim.

Answer 1

OK, I understand this now (thanks to DHJ for help with experimentation).
1) Mail.app 3.6 appears to ignore /etc/hosts completely. Mail.app 3.5 honored definitions in /etc/hosts.
I tested this by putting the known IP address of pop.gmail.com into /etc/hosts and calling it foo - I could not receive mail by pointing Mail.app at the server foo.
If this is so, it needs to be documented. This is extremely unusual behavior for a network application. I can see why Apple may be trying to protect us from hosts-hijacking, but this non-standard behavior has eaten up a lot of our time trying to figure it out.
2) Mail.app 3.6 appears to use a system proxy if one is defined. Mail.app 3.5 did not.
I tested this by verifying that Mail.app 3.6 could receive my mail (modulo the problem in 1) above) when any system proxy was defined, regardless of whether Profixier was running.
Every other application I know that uses the system proxy gives you the option of doing this (e.g., Firefox, Adium, and so on). This is why my Proxifier application was seeing nothing - Mail.app was going right to the system proxy. (FYI, Proxifier is designed to support proxies for applications that have not already been written to support proxies explicitly.)
The combination of 1) and 2) presented as a totally wacky complex problem. Viewed separately they don't seem so difficult to diagnose. Either way, they are both surprising, unusual and, to my knowledge, undocumented.