Securing POP mail access in MacOSX

How to Build a Secure SSH Tunnel for POP on Mac OS X

When a site runs a web server on a shared host, many services are handled by the provider for security. Mail, however, often remains exposed on the default POP3 port (110). For a Mac OS X user who needs to retrieve mail without exposing that traffic, tunneling POP through SSH is an elegant solution. It keeps the mail server unaware of the encryption and requires no root privileges or changes on the remote host. Below is a step‑by‑step walk through the process, including why each step matters and how to tailor it to your environment.

The core of the approach is an SSH local port forwarding command that tells the SSH client to listen on a chosen local port and forward any traffic arriving there to the POP3 port on the mail server. The syntax looks like this:

Let’s unpack each flag.

• -L 1110:pcunix.com:110 – This tells SSH to open port 1110 on the local machine. When data comes in on that port, SSH will connect to pcunix.com and forward the traffic to port 110 on that host. In the tunnel the data never leaves your local machine unencrypted.
• -l mylogin – This supplies the remote username you use to log in to the mail server. It avoids the prompt that would otherwise appear for the password or key passphrase.
• -N – Because we’re only forwarding ports and not executing a remote shell, this flag tells SSH not to run any commands after the connection is established. It keeps the session lean.

  Choosing the right local port is important. Ports below 1024 are privileged and require root to bind; that’s unnecessary and risky for a user‑level process. Any high port that’s not in use works fine. 1110 is arbitrary – you can use 5555, 2222, or any other free port. To verify a port is free, run lsof -i :1110 or simply try connecting with telnet localhost 1110 and see if you get a connection refused message.

  Once the tunnel is running, the mail client (Mail.app, Thunderbird, or any other) can be pointed to localhost and the chosen port. In Mail.app, open Preferences, go to the Accounts tab, select the account, and change the Incoming Mail Server to localhost. Then switch to the Advanced sub‑tab and enter the local port number. Even though the field looks like it only accepts three digits, you can safely type in a four‑digit port such as 1110. From that point forward, the client will open a socket to localhost:1110. SSH immediately forwards the traffic to pcunix.com:110 over an encrypted channel, shielding the username and password from eavesdroppers.

  Running the tunnel is easy, but a single‑shot command isn’t enough in a real environment. The POP server might terminate the connection after a period of inactivity, or the tunnel may drop if the local machine goes to sleep. When that happens, the SSH process terminates silently. The next time the mail client tries to connect, the local port will be unused, and the connection will fail. To avoid this, you need a small wrapper that keeps the tunnel alive and reconnects automatically.

  Below is a minimal shell script, named startmail, that does exactly that. Place it in a directory on your PATH or run it directly from your terminal.

  Prompt

  #!/bin/bash</p> <p>while true</p> <p>do</p> <p> ssh -L 1110:pcunix.com:110 -l mylogin -N pcunix.com</p> <p>done</p>

  The infinite loop ensures that if the SSH session exits for any reason - timeout, network glitch, or sleep state - the script immediately spawns a new tunnel. The script itself is lightweight and safe to run from the background. To launch it from a terminal, make it executable first:

  Prompt

  chmod +x startmail</p> <p>./startmail &

  Running it in the background with the & operator detaches the process from the terminal session. If you log out or reboot, the script will stop, so you’ll need to restart it after each session. For users who seldom log out, this manual approach is straightforward and gives full control.

  Automating the Tunnel with ssh‑agent for Password‑Free Reconnection

  While the previous script solves the reconnection problem, it introduces a new inconvenience: every time the SSH process starts, it prompts for the user’s password or key passphrase. On a MacBook that stays on most days, typing a long password repeatedly is undesirable. Fortunately, the SSH protocol includes an ssh-agent daemon that holds decrypted private keys in memory, allowing the SSH client to authenticate without user interaction after the first prompt.

  Setting up ssh-agent is a two‑step process. First, start the agent and tell the shell to load your keys. Second, modify the shell’s startup routine to load the agent automatically whenever you open a new terminal or log in.

  The first step can be wrapped in a small helper script called agent:

  Prompt

  #!/bin/bash</p> <p>ssh-agent /bin/bash --init-file ~/.ssh_bash_start</p>

  This command starts ssh-agent and launches a new Bash session that reads a custom initialization file. That file, ~/.ssh_bash_start, should contain the following two lines:

  Prompt

  . ~/.bashrc</p> <p>ssh-add</p>

  The first line loads any custom shell configuration you might already have. The second line, ssh-add, prompts for the passphrase of your private key (e.g., ~/.ssh/id_rsa). After you enter it once, the agent holds the decrypted key in memory for the duration of your login session. Subsequent SSH connections - including the repeated tunnel launches by startmail - will use that key without another prompt.

  After you have configured the agent, you can start it in a single step and launch the tunnel:

  Prompt

  ./agent</p> <p>./startmail &

  Now you’ll only need to type the key passphrase once, at the beginning of the session. Every time the tunnel dies, the script restarts it using the agent‑held key, so the mail client stays connected with minimal manual intervention.

  There are other options for automation that you might consider. Commercial tools such as Tunnelblick or SSH Tunnel Manager provide graphical interfaces and “keep‑alive” features, but they introduce an additional dependency and may not feel as lightweight as a simple Bash loop. The Bash‑plus‑ssh‑agent approach keeps everything on the command line, respects Mac OS X’s standard user environment, and requires no root privileges.

  When you’re comfortable with the setup, you can add a startup script that triggers both agent and startmail automatically whenever you log in. Place a small wrapper in ~/.login or ~/.profile that checks whether the tunnel is already running before launching a new instance. That way, even if you log out and back in, the tunnel will be ready without manual steps.

  Finally, remember that the SSH tunnel is only as secure as the key you use. Keep your private key protected with a strong passphrase, store it in ~/.ssh with permissions set to , and consider rotating keys annually. By combining an SSH tunnel with ssh-agent, you achieve a robust, automated, and fully encrypted POP connection on a Mac OS X system without relying on server‑side changes or extra software.