Reading CSLab e-mail on NAS sandbox machines such as cogitate

Normally, your e-mail "inbox" is the file /var/mail/username (e.g. mine is /var/mail/flaps). This directory cannot be mounted on the NAS sandbox machines because it includes the inboxes of all CSLab users, not just NA members.

So if you type "mail" or "pine" or similar commands on an NAS sandbox machine, you will be told that you have no mail (because there's nothing in /var/mail/yourname).

There is, however, a work-around. The work-around is to configure (via procmail) your CSLab mail to be delivered to a different file instead: one which can be mounted on the NAS sandbox machine. Specifically, we will deliver it to a file in a subdirectory of your home directory.

I can do the conversion of your account with you if you like. Or if you would like to do it yourself, or to know what's happening, here is a recipe.

But note that overall, I do not recommend this. I think that unless you really want to use an NAS sandbox machine to read your e-mail for some reason, it's best to keep it in the normal place at CSLab. You can run X-Windows programs over an ssh connection, e.g. instead of typing "thunderbird" you type "ssh apps0.cs thunderbird" (and you can put this in an alias, of course).

1. Choose a directory to put it in

You might already have a directory named "mail" or "Mail". Let's stick with whichever of these you already have. I recommend against having both; this gets confusing fast, especially over samba which is case-insensitive. I'll assume below that you are using the directory named "mail"; change as applicable.

On the other hand, if you don't already have a directory named "mail" nor one named "Mail", you should probably create one at this point. Make sure to chmod it so that no one other than you can see into it (e.g. "chmod 700 mail").

2. Modify your .procmailrc and maybe .forward, but don't save yet

To move from using the old file to using the new one with a minimal time window, we will get your new .procmailrc ready but not save changes in the editor, then move your inbox, then save changes to your .procmailrc. It's important to move the inbox before you start delivering to the new inbox file name. This way, if any mail does get delivered during the window of inconsistency, it will be delivered to /var/mail/username while you're already using your new file, which won't result in any mail loss (we'll just have to check /var/mail/username as a separate step at the end).

I'll assume here that you already have a .procmailrc. If you don't, and you don't have a .forward either, you can edit and save your .procmailrc freely, and put in a .forward at the last minute rather than saving changes to your .procmailrc at the last minute.

We'll call your new inbox file "csinbox", to avoid confusion with the name which imap clients present as your "real" inbox.

Your .procmailrc probably ends with a recipe to deliver your e-mail to your normal inbox, most likely by mailing to username+@postbox.cs.toronto.edu (with the '+' in there). We will replace it with the following recipe, substituting your user name for the name "username" below (and possibly changing "mail" to "Mail" if applicable):

:0:
/u/username/mail/csinbox

Most of your recipes have "*" lines, so this one will look strange. It's unconditional.

Note that the first line needs to be ":0:" rather than ":0", so that file locking is done. (The difference is the colon at the end. Your current final .procmailrc recipe probably lacks the colon because it is writing to a pipeline rather than saving to a file.)

Alternatively, perhaps your .procmailrc achieves delivery to your normal e-mail inbox by "falling off the end". In this case, you will want to append the above recipe to your .procmailrc without removing any existing recipes.

Remember not to save yet. If you did save changes to your .procmailrc, you can proceed with the following and just hope there's no mail loss (the probability is fairly low), or you can put it back first, or you can ask me for assistance...

3. Move your existing inbox

Type something like this, changing "username" to your user name:

mv -i /var/mail/username /u/username/mail/csinbox

4. Activate your new .procmailrc

Now, save changes in your editor, to make the mail start going to your new file.

Or, if you didn't have a .procmailrc or .forward before, get your .procmailrc all ready and then activate it by creating a .forward file which says:

"|/usr/bin/procmail -f-"

(Various more-complicated invocations are no longer necessary. Amusing details upon request.)

5. Read your mail in the new place

If you set the environment variable MAIL to /u/$USER/mail/csinbox, then the "mail" command-line program (mailx) will read that file instead. (This works better than using "mail -f mail/csinbox", in terms of how it detects new messages.)
I.e. put in your .cshrc:

setenv MAIL /u/$USER/mail/csinbox

and remove any other settings of this variable. Also, if you set the "mail" variable in (t)csh to notify you of new mail, you will want to change "/var/mail/$USER" to "/u/$USER/mail/csinbox" in that setting as well.

pine will see "csinbox" as a mail "folder", if you put it in the "mail" subdirectory of your home directory, and you can read it there.

An imap client such as Thunderbird will also see "csinbox" as a mail folder if it is in the mail subdirectory. (Of course, there's no point following the above recipe if you're going to read your mail with Thunderbird, but you can do so if you want to be able to read your mail both ways.) Then you can tell it that it is your inbox (for better new-message handling).

CSLab's webmail will look for Mail by default. You can change this in the preferences setting.

On the other hand, if you did use the directory name "Mail", then you can get pine to look there with a symlink ("ln -s Mail mail", assuming you don't have a "mail" directory).

As always, please feel free to ask me for help with any of the above.

6. Check for mail which arrived just while you were moving stuff around

You should check /var/mail/username, at least two minutes subsequent to when you activated your new .procmailrc, to see if any mail made it in to that file. There may be a window of up to about a minute where mail will be delivered to the old location because of caching of your .forward (or caching of the fact of the absence of your .forward).

An optional extra re "oldmail"

The CSLab "oldmail" feature will still be in place for you. However, you can only read the "oldmail" mail on a CSLab machine -- just as we can't mount /var/mail on NAS sandbox machines, we can't mount /var/oldmail, for the same reason (that is, it's not only NA people's mail).

If you would like an oldmail facility to be available from an NAS sandbox machine, you can create it in a similar way to the above procedure for your normal inbox.

First, put a recipe near the top of your .procmailrc, before any spam filtering etc (assuming that the whole point here is that you want the ability to look for mail which might have been wrongly discarded). It will look something like this:

:0c:
$HOME/mail/oldmail

This will copy all mail to your new "oldmail" file. Then, to "age" oldmail on a regular basis (so that it does not accumulate indefinitely), add a "crontab" entry to your personal crontab on apps0. I strongly recommend doing this on apps0, for a number of reasons; most of all, every machine (potentially) has a different crontab, and you don't want to have this running on two different machines, so let's standardize on apps0.

To add a crontab entry, type "crontab -e", which edits your crontab using your usual editor from the EDITOR environment variable. If you don't have a crontab (and if you didn't create one explicitly, you don't), it will start you off with a file containing only a comment reminding you of the order of the fields. Add this line:

0 4 * * Sun /p/na/bin/rotate-mailbox oldmail

The fields are minutes, hours, day of month, month, weekday, command. So this is 04:00 every Sunday.

More about crontab: Type "crontab -l" to see your crontab. As above, type "crontab -e" to edit it. To remove it, type "crontab -r".

This does not affect the CS oldmail facility. The CS oldmail facility will still be there for you too.