Let's see how ssh addresses some of the scenarios outlined above. The simple case of password exposure over the network is handled by the encryption used by ssh; when you're typing through the encrypted tunnel your passwords aren't flying over the Ethernet in the clear. Of course, this requires that you have ssh available where you're initiating the login; if you plan on using this method to secure yourself while doing system administration from offsite, make sure you are tying into an ssh session directly without any intervening insecure network. Another solution to the remote login problem is to use a one-time password system, such as a digital token card or the Bellcore S/Key system.
The remote mail access problem is also fixed by ssh, since it encrypts the mail contents going over the login session. You can use ssh under a POP session, forwarding the TCP endpoint through an encrypted tunnel to the remote end if you don't go the command-line-interface route. Similarly, problems with IP and DNS spoofing are addressed by host authentication. If you have a known key for the remote host, you may be detoured by bogus routing, IP, or name information but won't actually complete an ssh connection to the other side.
The X session protection is handled through features built into ssh to transparently erect X-aware tunnels. Instead of forwarding X authority information over the network, the ssh client creates dummy authorization information that is forwarded to the server. The server creates a fake X11 server that is used to intercept X requests. The server side forwards the X traffic back to the client, where the dummy authorization information is checked. If it matches, the client forwards the request on to the real, local X server. The local authorization information is never sent over the network, reducing the possibility of opening a window of attack from another host that would use a non-encrypted channel to the local X server.
As with all encryption tools, ssh is not a perfect or complete solution. If you can't trust the contents of your home directory, you'll have trouble putting absolute faith in the key management system used by ssh. NFS traffic in general isn't protected by ssh, so you need to worry about mail spools exported via NFS across untrusted networks. You must be consistent about implementing data integrity policies -- if you are worried about executives reading mail over insecure channels, you should also focus on how the mail is delivered. There's no point in using an encrypting shell for forwarding POP connections if the incoming SMTP traffic waltzes across your network to the common mail spool without any protection at all. The first order of defense is to perform a careful analysis of all of the paths over which your traffic travels, determine which of them are likely to produce inappropriate access to your bits, and then act to protect your data while it's exposed.