Difference between revisions of "Email on Shell"

From XMission Wiki
Jump to: navigation, search
 
(14 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== 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.
 
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.
  
Line 10: Line 8:
  
 
One option is to forward all your email to your shell account.
 
One option is to forward all your email to your shell account.
 +
 +
Your account MUST be on the new mail system for this to work. If you have received an email informing you of a pending migration to the new mail system, please wait until AFTER the migration has occurred to set this option up. You may also email support@xmission.com and request that forwarding be setup along with the migration of your email account.
  
 
You can do this by logging into [https://webmail.xmission.com 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 can do this by logging into [https://webmail.xmission.com 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".
Line 15: Line 15:
 
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".
 
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.
+
Enter your shell username@shell.xmission.com in the text box labeled "Address(es) to forward to", and click save.
  
 
Your email will now be forwarded to shell.xmission.com.
 
Your email will now be forwarded to shell.xmission.com.
Line 23: Line 23:
 
== Using Fetchmail / Maildrop ==
 
== 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.
+
You can set up fetchmail on its 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.
 
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...
+
Here are some sample .fetchamilrc files...
  
Standard fetchmail, sends to local meta:
+
Standard fetchmail, sends to the mta:
  
<pre>poll mail.xmission.com protocol pop3 uidl username "your_username_here" password "your_password_here" no keep</pre>
+
<pre>poll mail.xmission.com  
 +
protocol pop3  
 +
uidl username "your_username_here"  
 +
password "your_password_here"  
 +
no keep
 +
flush</pre>
  
 
Fetchmail, sends directly to maildrop:
 
Fetchmail, sends directly to maildrop:
  
<pre>poll mail.xmission.com protocol pop3 uidl username "your_username_here" password "your_password_here" no keep mda "/usr/bin/procmail -f %F"</pre>
+
<pre>poll mail.xmission.com  
 +
protocol pop3  
 +
uidl  
 +
username "your_username_here"  
 +
password "your_password_here"  
 +
no keep  
 +
flush
 +
mda "/usr/bin/maildrop"</pre>
  
 
Fetchmail, sends directly to procmail:
 
Fetchmail, sends directly to procmail:
  
<pre>poll mail.xmission.com protocol pop3 uidl username "your_username_here" password "your_password_here" no keep mda "/usr/bin/procmail -f %F"</pre>
+
<pre>poll mail.xmission.com  
 +
protocol pop3  
 +
uidl  
 +
username "your_username_here"  
 +
password "your_password_here"  
 +
no keep  
 +
flush
 +
mda "/usr/bin/procmail -f %F"</pre>
 +
 
 +
Note that the "no keep" and "flush" are optional. Remove "no keep", and fetchmail will leave messages it downloads on the server. Remove flush, and fetchmail will leave all already-downloaded messages on the server.
  
 
== Configuring IMAP ==
 
== Configuring IMAP ==
  
<stuff here>
+
Here are some sample configurations for Pine and Mutt that you can use to connect via imap.
 +
 
 +
Regardless of what email client you use, you will always want to connect to mail.xmission.com with your xmission username and password to use either IMAP or POP.
 +
 
 +
=== Pine Instructions ===
 +
 
 +
You may want to backup your .pinerc file before making these changes.
 +
 
 +
At Pine's mail menu, hit "S" to go to the Setup menu.
 +
On the setup menu, hit "C" to go to the Config menu.
 +
Change the "inbox-path" variable to {mail.xmission.com/user=your_username_here}INBOX
 +
Hit "E" to exit, and say "Yes" to commit changes when it asks.
 +
Quite pine and restart.
 +
 
 +
We do not have passwordfile support in our copy of pine, so you will need to type your password in every time you start pine.
 +
 
 +
=== Mutt Instructions ===
 +
 
 +
For mutt, create a .muttrc file containing the following options:
 +
 
 +
<pre>
 +
mailboxes 'imap://your_username_here@mail.xmission.com'
 +
set spoolfile='imap://your_username_here@mail.xmission.com/Inbox'
 +
set folder='imap://your_username_here@mail.xmission.com'
 +
</pre>
 +
 
 +
If you want mutt to automatically login to the imap server for you, you can also add the following variables to .muttrc:
 +
 
 +
<pre>
 +
set imap_user=your_username_here
 +
set imap_pass=your_password_here
 +
</pre>
 +
 
 +
=== Offline IMAP ===
 +
 
 +
Though we cannot provide any support for it, you may also be interested in Offline IMAP:
 +
 
 +
http://software.complete.org/software/projects/show/offlineimap
 +
 
 +
It is essentially a two-way synchronization between IMAP and a set of Maildirs. One could either cron offlineimap, or run it continually in a screen, and use a maildir-aware console client to read their mail with direct file access and such, without sacrificing the ability to use POP and IMAP. It would also be possible to forward to a shell account (without keeping a copy), process with procmail into the maildirs that are being synchronized with the IMAP server, creating a setup that essentially mimicks direct mail spool access to mailboxes that are still accessible via POP, IMAP and Webmail.
 +
 
 +
== Other Options ==
 +
 
 +
Unfortunately, there is no way to directly access the mail spool used by our "new" mail system from shell, but if you prefer to use shell to access your mail, I hope you can find a method of accessing your mail here that fits your own preferences. If you use another imap-capable mail client on shell, you should be able to configure it in a manner similar to mutt and pine. You may also want to look into either using webmail, or switching to a mail client that runs on your own computer. Using IMAP (which is what webmail uses behind the scenes), you can access your mailbox from multiple email clients easily, all keeping your email in a consistent state, and avoiding the numerous problems that come with POP.
 +
 
 +
[[Category:XMission_Email]]

Latest revision as of 14:52, 27 January 2014

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.

Your account MUST be on the new mail system for this to work. If you have received an email informing you of a pending migration to the new mail system, please wait until AFTER the migration has occurred to set this option up. You may also email support@xmission.com and request that forwarding be setup along with the migration of your email 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@shell.xmission.com 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 its 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 .fetchamilrc files...

Standard fetchmail, sends to the mta:

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

Fetchmail, sends directly to maildrop:

poll mail.xmission.com 
protocol pop3 
uidl 
username "your_username_here" 
password "your_password_here" 
no keep 
flush
mda "/usr/bin/maildrop"

Fetchmail, sends directly to procmail:

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

Note that the "no keep" and "flush" are optional. Remove "no keep", and fetchmail will leave messages it downloads on the server. Remove flush, and fetchmail will leave all already-downloaded messages on the server.

Configuring IMAP

Here are some sample configurations for Pine and Mutt that you can use to connect via imap.

Regardless of what email client you use, you will always want to connect to mail.xmission.com with your xmission username and password to use either IMAP or POP.

Pine Instructions

You may want to backup your .pinerc file before making these changes.

At Pine's mail menu, hit "S" to go to the Setup menu. On the setup menu, hit "C" to go to the Config menu. Change the "inbox-path" variable to {mail.xmission.com/user=your_username_here}INBOX Hit "E" to exit, and say "Yes" to commit changes when it asks. Quite pine and restart.

We do not have passwordfile support in our copy of pine, so you will need to type your password in every time you start pine.

Mutt Instructions

For mutt, create a .muttrc file containing the following options:

mailboxes 'imap://your_username_here@mail.xmission.com'
set spoolfile='imap://your_username_here@mail.xmission.com/Inbox'
set folder='imap://your_username_here@mail.xmission.com'

If you want mutt to automatically login to the imap server for you, you can also add the following variables to .muttrc:

set imap_user=your_username_here
set imap_pass=your_password_here

Offline IMAP

Though we cannot provide any support for it, you may also be interested in Offline IMAP:

http://software.complete.org/software/projects/show/offlineimap

It is essentially a two-way synchronization between IMAP and a set of Maildirs. One could either cron offlineimap, or run it continually in a screen, and use a maildir-aware console client to read their mail with direct file access and such, without sacrificing the ability to use POP and IMAP. It would also be possible to forward to a shell account (without keeping a copy), process with procmail into the maildirs that are being synchronized with the IMAP server, creating a setup that essentially mimicks direct mail spool access to mailboxes that are still accessible via POP, IMAP and Webmail.

Other Options

Unfortunately, there is no way to directly access the mail spool used by our "new" mail system from shell, but if you prefer to use shell to access your mail, I hope you can find a method of accessing your mail here that fits your own preferences. If you use another imap-capable mail client on shell, you should be able to configure it in a manner similar to mutt and pine. You may also want to look into either using webmail, or switching to a mail client that runs on your own computer. Using IMAP (which is what webmail uses behind the scenes), you can access your mailbox from multiple email clients easily, all keeping your email in a consistent state, and avoiding the numerous problems that come with POP.