Like SSH, IMAP is a client/server protocol. Your email program (e.g., Pine) is the client, and an IMAP server process (e.g., imapd ) runs on a remote machine, the IMAP host, to control access to your remote mailbox. Also like SSH, IMAP generally requires you to authenticate before accessing your mailbox, typically by password. Unfortunately, in some cases this password is sent to the IMAP host in the clear over the network; this represents a security risk (see Figure 11-8).^[148]

Figure 11-8. A normal IMAP connection

There’s no longer any good reason for this. Years ago, security options were rarely available in IMAP software; these days, however, they’re common and should be used! There are standard ways to secure IMAP traffic using SSL or Kerberos. With SSL, the entire IMAP session is protected, so even plain password authentication can be used relatively securely. Kerberos can provide secure authentication and single-signon with or without session encryption; for example, the Apple Mail client implements both. Pine uses Kerberos only for authentication, not encryption—but you can combine Kerberos with SSL to get both single-signon and privacy. Note the power of having multiple independent and standards-based options available!

Nonetheless, it is still all too common to encounter IMAP servers with no security features; here, we show you how to address this problem with SSH.

If your mail server is sealed--that is, your only access to it is via the IMAP protocol—then there’s nothing you can do to improve security using SSH. However, if you can also log into the IMAP server host via SSH, you have options. Because IMAP is a TCP/IP-based protocol, one approach is to use SSH port forwarding between the machine running Pine and the IMAP host (see Figure 11-9). [9.2.1]

Figure 11-9. Forwarding an IMAP connection

However, this technique has two drawbacks:

Fortunately, we can address both of these drawbacks and run Pine over SSH securely and conveniently.

11.3.1.1 Pine and preauthenticated IMAP

There are two broad types of Unix-based IMAP servers, exemplified by the University of Washington (UW) imapd and the Carnegie Mellon Cyrus software. Cyrus is a self-contained system: it uses an internal database to hold user mail, and the only access to it is via the IMAP protocol or particular programs for mail delivery or administration. In particular, there is no relationship between Unix accounts on the server host, and IMAP accounts; they are completely separate.

The UW imapd, on the other hand, is a lighter-weight affair: it simply provides an IMAP view of the traditional Unix mail store: files in /var/spool/mail or elsewhere, owned by the Unix accounts of the mail recipients. Thus, its notion of user account and access control is tied to that of the host. If your mail is stored in a spool file owned by you, and you can log into the host via SSH, then you’ve already proven you have access to that file—why should you have to prove it again to the IMAP server? In fact, with the UW server, you don’t have to. We now discuss how to do this with UW imapd, or another IMAP server with similar behavior.

The IMAP protocol defines two modes in which an IMAP server can start: normal and preauthenticated (see Figure 11-10). Normally, imapd runs with special privileges to access any user’s mailbox (as when started as root by inetd), and hence it requires authentication from the client.

Figure 11-10. Pine/IMAP over SSH, preauthenticated

Here’s a sample session that invokes an IMAP server, imapd, through inetd so that it runs as root:

    server% telnet localhost imap
    * OK localhost IMAP4rev1 v12.261 server ready
    0 login res password'
    1 select inbox
    * 3 EXISTS
    * 0 RECENT
    * OK [UIDVALIDITY 964209649] UID validity status
    * OK [UIDNEXT 4] Predicted next UID
    * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
    * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags
    1 OK [READ-WRITE] SELECT completed
    2 logout
    * BYE imap.example.com IMAP4rev1 server terminating connection
    2 OK LOGOUT completed

Alternatively, in preauthenticated mode, the IMAP server assumes that authentication has already been done by the program that started the server and that it already has the necessary rights to access the user’s mailbox. If you invoke imapd on the command line under a nonroot uid, imapd skips the authentication phase and simply opens the mailbox file of the current account (which must be accessible via the existing Unix permissions structure). You can then type IMAP commands and access your mailbox without authentication:

    server% /usr/local/sbin/imapd
    * PREAUTH imap.example.com IMAP4rev1 v12.261 server ready
    0 select inbox
    * 3 EXISTS
    * 0 RECENT
    * OK [UIDVALIDITY 964209649] UID validity status
    * OK [UIDNEXT 4] Predicted next UID
    * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
    * OK [PERMANENTFLAGS (\* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags
    0 OK [READ-WRITE] SELECT completed
    1 logout
    * BYE imap.example.com IMAP4rev1 server terminating connection
    1 OK LOGOUT completed

Notice the PREAUTH response at the beginning of the session, indicating preauthenticated mode. It is followed by the command select inbox, which causes the IMAP server implicitly to open the inbox of the current user without demanding authentication.

Now, how does all this relate to Pine? Pine has a built-in feature whereby, instead of using a direct IMAP connection, it logs into the IMAP host using ssh and runs a preauthenticated instance of imapd directly. If this succeeds, Pine then converses with the IMAP server over the SSH connection, and has automatic access to the remote inbox without further authentication.

    ssh-path=/usr/bin/ssh

    "%s %s -l %s exec /etc/r%sd"

    /usr/bin/ssh imap.example.com -l smith exec /etc/rimapd

    ssh-command="%s %s -l %s -o BatchMode=yes -axq exec /usr/sbin/imapd"

    /usr/bin/ssh imap.example.com -l -o BatchMode=yes -axq exec /usr/sbin/imapd

    ssh-path=/usr/bin/ssh
    ssh-command="%s %s -l %s -o BatchMode=yes -axq exec /usr/sbin/imapd"
    ssh-open-timeout=15

    {hostname/user=jane}mailbox

Pine uses IMAP to read mail but not to send it. For that, it can either call a local program (such as sendmail) or use an SMTP server. Pine can also be a newsreader and use NNTP (the Network News Transfer Protocol, RFC-977) to contact a news server.

An ISP commonly provides NNTP and SMTP servers for its customers, but obviously does not want to allow arbitrary people to use them. Modern extensions to the NNTP and SMTP protocols include authentication, and ISPs are starting to use and require them. Before such mechanisms were available, however, the usual method of restricting access to these services was via network address: the ISP would allow access from addresses within its own network (and hence hopefully only from its customers). Many ISPs have not yet switched to direct authentication for these services, and are still using address-based authorization; so, if you’re connected to the Internet from elsewhere and try to use your ISP’s mail server, the attempt might fail. Access to your usual servers might be blocked by a firewall, or the mail server might reject your mail with a message about “no relaying,” and the news server rejects you with a message about “unauthorized use.”

You are authorized to use the services, of course, so what do you do? Use SSH port forwarding! By forwarding your SMTP and NNTP connections over an SSH session to a machine inside the ISP’s network, your connections appear to come from that machine, thus bypassing the address-based restrictions. You can use separate SSH commands to forward each port:

    $ ssh -L2025:localhost:25 smtp-server ...
    $ ssh -L2119:localhost:119 nntp-server ...

Alternatively, if you have a shell account on one of the ISP’s machines running SSH but can’t log into the mail or news servers directly, do this:

    $ ssh -L2025:smtp-server:25 -L2119:nntp-server:119 shell-server ...

or neatly automate it this way:

    [~/.ssh/config]
    Host mail-news-forwarding
      Hostname shell-server
      LocalForward 2025 smtp-server:25
      LocalForward 2119 nntp-server:119

    $ ssh mail-news-forwarding

This is an off-host forwarding, and thus the last leg of the forwarded path isn’t protected by SSH. [9.2.4] But since the reason for this forwarding isn’t so much protection as it is bypassing the source-address restriction, that’s OK. Your mail messages and news postings are going to be transferred insecurely once you drop them off, anyway. (If you want security for them, you need to sign or encrypt them separately, e.g., with PGP or S/MIME.)

In any case, now configure Pine to use the forwarded ports by setting the smtp-server and nntp-server configuration options in your ~/.pinerc file:

    smtp-server=localhost:2025
    nntp-server=localhost:2119

Even if your ISP uses direct authentication, you might choose to use SSH anyway if it does so poorly. For instance, some badly deployed services require password authentication but do not provide encryption for the connection! In this case, you would forward over SSH in order to protect your password.

One possible complication: the SSH feature has a global on/off switch, applying to every remote mailbox. That is, if ssh-open-timeout is nonzero, Pine tries to use this style of access for every remote mailbox. If you have multiple mailboxes but only some of them are accessible via SSH/imapd, this leads to annoyance. Pine falls back to a direct TCP connection if SSH fails to get an IMAP connection, but you have to wait for it to fail. If the server in question is behind a firewall silently blocking the SSH port, this can be a lengthy delay. If you’re in this situation, you can disable SSH access for specific mailboxes using the /norsh switch, like this:

    {imap.example.com/user=smith/norsh}inbox

That’s not a typo: the switch is /norsh rather than /nossh. This is just an historical artifact of the software: originally, Pine supported this style of mailbox access via rsh. In fact, there are still configuration variables--rsh-path, rsh-command, and rsh-open-timeout--that function entirely analogously; so much so, that in the first edition of this book, we described how to use SSH with older versions of Pine by simply setting rsh-command to “ssh”. Anyway, /norsh turns off the use of both the ssh or rsh features of Pine for the mailbox in question.

The Pine configuration option ssh-path can point not only to ssh, but also to any other program: most usefully, a script you’ve written providing any needed customizations. If your needs are complex, you might have to do this. For example, the ssh-path setting is global to all mailboxes, but perhaps the imapd executable is in different locations on different servers you want to access. You can solve this problem with a script which takes the four ssh-command arguments from Pine, and does the right thing depending on which server is specified:

    ssh-path=/home/smith/bin/my-pine-ssh-script
    ssh-command="%s %s %s %s"

where the script my-pine-ssh-script is:

    #!/bin/sh

    ssh=$1
    server=$2
    user=$3
    method=$4

    prefix="exec $ssh -qax $user@$server exec"

    case $server in
        mail.work.com) $prefix /usr/sbin/imapd ;;
         imap.isp.net) $prefix /usr/local/sbin/imapd ;;
                    *) exit 0
    esac

The default action of exit will cause Pine to skip SSH access quickly for servers other than the two mentioned.