> It allows you to have a secure connection between two endpoints on the
> internet that might not otherwise be able to connect.  I use it to
> grab my pop mail from a heavily firewalled server when I'm on the
> road.  Just crank up my ssh session to the main machine (with a tunnel
> from port 119 on the local machine to port 119 on mail.foo.ba), then
> tell my pop client to go to localhost instead of mail.foo.ba.  ssh can
> be configured to disallow connections to that port from outside of my
> machine, so I have a high degree of confidence that no one else is
> using that connection if I'm the only one on the machine.

This is pop over ssh and so tcp over tcp.
I also run it though (fetchmail over ssh) and experienced some problems.
But for lack of ipsec compatibility on the pop server site this is the
only way to go. However .... sometimes i really doubt the use of it.
By default i negociate via apop with the popserver where the password
is md5'd. So they'll be able to sniff my username and contents of the mail
fine. When i'd go by pop over ssh ppl wouldnt be able to simply sniff and
see the content which is very nice of course.
However, when mail is send, it's done over smtp which is plain text as well
and so ppl'll see the mail when arriving on the mailserver itself anyway.
Only thing to remedy that is gpg or smtp over ssh.
So basically using apop is good enough for me considering the above.
However, i still use pop over ssh. I guess only reason is that i have more
confidence that ssh provides better encryption (which is indeed true)
and authentication then apop, so ppl wont be able to grap my password that
easily.
Bye,

Mipam.