Rational Survivability

Interesting point, and certainly any time you're out in public – in country or abroad – you have to assume that any public network you're connected to is untrusted. Transparent hijacking can be carried out on any Wi-Fi network using simple ARP poisoning, so it's not just ISP's you have to watch out for, it's other client systems, too.
That said, most of the client VPN solutions out there today support some variation on "full tunnel" connections. This means that once the IPSec or SSL VPN tunnel is established, all traffic from the laptop is shoveled over it, including DNS. The all-or-nothing VPN mode prevents the local network from successfully carrying out MITM attacks, at least while the VPN client is connected, and also protects the office network from leap-frog attacks through the client machine.
PaulM

Yeah, the right way to support road warriors accessing internal services is to put them behind a firewall and only allow connections internally, including the VPN. So if the VPN fails, and VPN software WILL tell users about failed connections, the name can resolve to anything you want, but you can't actually do anything. You can also enforce authentication or mail over TLS. Lots of options.
Mike

When I'm feeling particularly paranoid on OS X (or OpenBSD) I not only tunnel, but I set up ipfw rules. They basically go like this:
Allow all to localhost
Allow any established connection
Allow the VPN or SSH port to my VPN/SSH concentrator's public IP
Deny all
Then, if my VPN or SSH fails, nothing leaves my laptop and nothing gets in, either. This is what I did at DefCon, for example. I also do this whenever I do business work from any public place (wired or wireless)

That's why I use Outlook with Exchange and RPC over HTTPS. I don't have to worry about VPN, my connection will automatically use SSL and fail to connect if it can't.

Well, whoever setup that IPsec connection was completely, and utterly brain dead I guess. As people have already (indirectly) mentioned if you're doing any sort of split tunnel with a corporate connection you should be fired from your security position to begin with — let alone even allowing clear text SMTP (WhoTF uses non SSL protected SMTP anymore anyway – what is this 1995???) out any interface from the laptop when you're not actually on the corporate LAN. There's lots of ways to avoid this easily — it just takes about 10 minutes of actual thought process.
–windexh8er

@windexh8er: I think you missed the premise.
Regardless of whether split-tunneling was on or off, the mail client was configured to access a non-resolvable (from the Internet) DNS name for the mail server as if it were inside the corporate network.
If you're inside the network (normally,) most companies don't want to impose additional load on the mail server or have to stand up an internal proxy by enabling SSL…they usually don't see the need/threat.
Thus, if you're outside, the only "normal" way you'd be able to resolve and internal DNS name is if your VPN was up and you could resolve against an internal DNS server, which is what the security/administrators obviously expected in this case.
In the case cited above, the VPN was blocked by the provider and the proxy simply spoofed the hostname to redirect SMTP to their $evil mail server. This had nothing to do with split tunneling, because quite frankly, even if split-tunneling were disabled, this still would have worked.
It's a case that most security folks probably wouldn't even think of.
The "encrypt everything, everywhere" is often unrealistic, no matter how good of an idea it may be.
Case in point, there's an obvious trade-off here with denying split tunneling and still allowing Internet access, which if you're using services that are Internet based (such as Salesforce.com, for example) where you need simultaneous access to both Internet and Intranet resources.
That trade-off is the scalability of whatever proxy you're using internally to forward Internet-destined traffic through as well as the size of the pipe(s) connected to the corporate network through which now all traffic has to pass (after going through the proxy.)
If you're a small SMB, this is probably still a non-issue.
If you're a global company with lots of roaming staff, the notion of SLA's and business pressures along with the the costs and support infrastructure that disabling split tunneling brings means that it's not quite as simple…
Now, I'm not arguing that what you're proposing isn't a good idea, I'm simply suggesting that the ol' "you should be fired for not being a good security professional argument" simply ignores the realities of the fact that you're squeezing the balloon; the problem simply shifts.
It's only going to get worse with all this cloud zaniness — your Intranet is likely to either be exposed to or may very well be based on the Internet…
Another good reason to think about thinner client alternatives…
As to the cleartext SMTP issue, the answer is probably in the high double digits…
/Hoff

I use a vpn to secure connectivity – this eliminates the need to expose internal systems to the whole wide world. Related to topic- proxy

owever, the Strong vpn server in New York that I use appears never to vary from a speed of between 4000 kb/s and 5000 kb/s. And with that kind of bandwidth, it's possible to watch not just streaming video, but to watch the hi-resolution version that many sites offer. StrongVPN seems almost too good to be true, and I think it will take me some time to lose my fear that the amazingly good bandwidth I've been getting might be just a fluke somehow. I'm sure it is not a fluke, though. I think StrongVPN's service will continue to be just as incredibly fast and dependable as it's been so far. To sum up: after the experience of having to cope with what a number of really shoddy companies offer elsewhere

If you love blogging then I am sure you heard about http://vpnomania.com/proxy-surf.html . There are many companies offering you some protection service for your data in the online world. Make sure that you choose the trustable company for it so you can safe your data