8. Handling remote mail

This section describes using POP or IMAP to handle remote mail.

Other options include nfs-mounting the spool partition on client machines (Danger Will Robinson! Is everyone using the same lock method?) or using a mail-to-web gateway (quite popular now).

8.1 History

On a workstation network, mail has always been a problem:

• Either you use "[email protected]" with problems when "computer" is down, making your network known to the people outside, having different addresses for a same person switching to another computer, ...
• Or you take a mail hub, "mailhost.foo.com" with rules for rewriting, so every user seems to post from the same address, even if they are on different computers.

But in that case, how can users read their mail?

Using a rsh with elm? :-)

It would overload our mail hub! One method was forwarding or UUCP, smtp, etc. but it's too complicated.

Then came POP/IMAP, both with security problems at the beginning, (now fixed using ssh on new versions): a mail program has sometimes to be set locally (like qmail, smail or vmail if, for example, you use elm, but mozilla will avoid that!) however, getting and sending Email is simpler.

8.2 Getting mail

Here come POP's main drawbacks:

• the password is sent as a clear text on the network,
• you must choose a POP-aware mailer; many do now (like Pine, Emacs, Mozilla, Netscape, Mutt, IE, Pegasus, Eudora, Claris...),
• when a user may roam (read mail from different machines) having e-mail popped on the computer used yesterday can be a nuisance,
• some POP servers (e.g. qpopper, ipop3d) on high-use servers can load the machine significantly. Consider controlling options (such as not leaving mail on the server) and/or changing the pop server (e.g. cucipop), as well as avoiding running it from inetd.

The password problem can be solved creating a crypted "channel" to have POP on it or using APOP or RPOP extensions. The mail reader problem can be solved either by changing mail reader (don't underestimate the effort required to re-educate users!) or by using a POP "mail sucker" with a local mail program.

IMAP can be preferable to POP in various situations like remote (and especially roaming) access, while you restrict POP to a LAN where snooping of passwords isn't so much of a concern. Mark Aitchison reported a solution here is to use hosts.deny and hosts.allow files (please see Net-3 HOWTO ; this assumes you are starting pop from inet).

The policy of leaving mail on the server or not has implications for server disk space and easier backup/security of the mail, as well as allowing roaming, so the best solution depends on the type of organization. Of course, this will not ensure your mail can't be read, but nobody will be able to delete it ; if all your mail is pgp encrypted this is a better solution.

Here are some pop programs worth trying:

• gwpop (a Good Way to POP) is very protected since it creates a crypted "channel" and puts mail directly in the "spool" ; however, it depends on Perl.
• popclient, simple to use: For example if your login is john and your password PrettySecret, you will run:

  
  $ popclient -3 -v mail.acme.net -u john -p "PrettySecret" -k -o JOHN-INET-MAIL
  

  It is strongly discouraged in case of multi-user machine; other user can see your password by, for example with "ps auxw"
• fetchmail, which is actively supported and incredibly simple to use: it is configured in ~/.fetchmailrc, so you only need to run fetchmail when you want to retrive your mail. Here's my .fetchmailrc:

  
  poll mail.server protocol pop3:
          forcecr
          password PrettySecret;
  

  Don't forget to "chmod 600  /.fetchmailrc" or fetchmail will ask for it. Please note that the forcecr option is needed to use fetchmail with qmail, which strictly respects RFCs.

8.3 Sending mail

For this, you must use smtp-aware mail software, like qmail, smail, vmail or mozilla (this one does everything: mail reader, POP receive, smtp send!)

Go to one of the previous sections to install and configure the one you like best. Then, when you will reach "Testing", try to send some mail to a local account on the mail hub.

8.4 Reading mail

If your program doesn't do everything itself, you can install elm, pgp, mush, pine ... many good programs are freely available for linux platforms!

8.5 Testing

To check whether your mail server has pop, try:

$ telnet mailhost 110

If it works, you will get something like "OK Pop server (...) starting": type "quit"!

To install a ssh crypted "channel", first test your mail server typing:

$ ssh mailhost date

If you get the date, you should be OK. Please note ssh will not ask for a password, therefore you must create a ".shosts" file on the mail server, containing client's name. To test ssh port redirection (which gwpop uses), type:

$ ssh -n -f -L 12314:localhost:110 mailhost sleep 30

then

$ telnet localhost 12314

Then will you hopefully see mail hub's pop banner. If you don't use ssh, don't forget to comment out $ssh on gwpop script. To check whether procmail is running, try "procmail -v"

8.6 Using

Now you can edit gwpop Perl script to check everything is ok, then run gwpop:

$ gwpop -v your-username
POP password on mailhost: yoursecretpasword

If gwpop "error messages" are normal, the mail from mail hub will be downloaded to your local machine wherever you told gwpop to put it. (please test with some mail!).

You can also use gwpop as a daemon:

$ gwpop -d $HOME/tmp your-username

gwpop messages are then sent to syslog and gwpop will run endlessly ; a "HUP" signal will force gwpop to get your mail.

You can get POP software here used on:

ftp://ftp.unina.it/pub/Unix/pkgs/network/mail/gwpop
ftp://ftp.informatik.rwth-aachen.de/pub/packages/procmail
http://www.cs.hut.fi/ssh/