Email on Shell

Email on Shell

A number of users, particularly accounts that date back to our older mail system (which keeps inboxes on shell in /var/mail and /var/spool/mail), use or have used shell.xmission.com to access their mail, through mail clients such as mutt or pine. Other users may still use POP/IMAP, but filter their mail through shell using a program such as procmail.

Starting in 2005, we moved our mail system over to a much more robust system using Cyrus. As Cyrus only serves POP and IMAP clients, it was not directly compatible with these users using shell.xmission.com to manage their mail, and the old mail system has remained for years, serving fewer than 100 users. As the time of this writing, we are on the verge of decommissioning this server.

As most users have either been moved to the new mail system, or will be in the near future, here are a few different options to preserve or regain the ability to use shell.xmission.com, in some capacity, for email.

Forwarding to Shell

One option is to forward all your email to your shell account.

You can do this by logging into webmail, expanding the "mail" section on the left, and clicking "Filters". On the right, in the main pane of webmail, click on "Show Detailed Filter Rules".

You will now see your webmail filters, including the built-in forwarding filter. Make sure that the forwarding filter is enabled. There should be a green checkbox on the same line indicating that it's enabled. If there is a red "X" on the same line as the forwarding filter, click on the "X", and it should become a green checkbox. Now click on "Forward".

Enter your shell username in the text box labeled "Address(es) to forward to", and click save.

Your email will now be forwarded to shell.xmission.com.

You can also check or uncheck "Keep a copy of messages in this account". If it is checked, all messages will be both forwarded to your shell account, and stored within our new mail system. This will enable you to also check mail via POP, IMAP or Webmail if you desire. However, your read/unread messages will not be synchronized, nor will any filtering or messages introduced on shell.xmission.com (such as an outbox folder propagated by a mail client on shell). Also, messages on the new mail system will be subject to quota restraints if mail is never deleted via POP, IMAP or Webmail. If you are over quota on the new mail system, this will prevent forwarding from occurring.

Using Fetchmail / Maildrop

You can set up fetchmail on it's own, in which case it will send mail to the local mail transport agent (Exim on shell.xmission.com), or using Maildrop. Fetchmail uses the configuration ".fetchmailrc" in your home directory. Once you have it configured, you can just run the command "fetchmail" on shell.xmission.com, and it will retreive your mail. You can cron this, or set up a shell script that runs in right before running your mail client, and have delivery to your shell account become automated.

If you choose the latter option (shell script running both), this has the advantage that you can check your mail via webmail.xmission.com (or pop, leaving on server, or imap) from locations where you don't have shell access, seeing all the mail that's queued up, but still have the mail automatically delivered to shell once you're ready to read it there, avoiding the quota maintenance problems present with simple forwarding / keep on server.

Here are some sample .fetchamilrcs...

Standard fetchmail, sends to local meta:

poll mail.xmission.com protocol pop3 uidl username "your_username_here" password "your_password_here" no keep

Fetchmail, sends directly to maildrop:

poll mail.xmission.com protocol pop3 uidl username "your_username_here" password "your_password_here" no keep mda "/usr/bin/procmail -f %F"

Fetchmail, sends directly to procmail:

poll mail.xmission.com protocol pop3 uidl username "your_username_here" password "your_password_here" no keep mda "/usr/bin/procmail -f %F"

Configuring IMAP

<stuff here>