Wandering Thoughts archives

2022-10-04

Our unusual traditional /var/mail setup for people's inboxes

We have been operating our Unix environment for a very long time now; at this point, the core of the environment goes back more than 30 years. One of the things that happens when you operate an environment for 30 years or more is that your setup winds up with things that exist in part because of historical compatibility, and that aren't necessarily how you would design things today. One of those things is how mail inboxes work in our environment.

If you go back 30 years ago, IMAP was not really very much of a thing. Most people read their email by logging in to our Unix servers and running various Unix programs, and these programs read people's mailboxes in traditional Unix format from /var/mail (or perhaps it was /var/spool/mail at the time). Because we had a multi-server environment even back then, this /var/mail lived on one server and was NFS-exported to all of the others. When a POP and IMAP server was added at some point, it had to play along with this environment and so it was configured so that the IMAP INBOX was your /var/mail inbox (although your other IMAP folders went in your home directory). And because people's inboxes were directly exposed as files, people could and did write procmail rules files that directly appended incoming email to them (with appropriate locking).

Today, almost everyone reads their email through IMAP and few people have procmail rules any more. If we were starting a new environment from scratch, we might well allow only IMAP (or POP3) access to your email and not store your INBOX in /var/mail (although we'd need to expose some sort of flexible per-user mail filtering). But we aren't starting from scratch (and 'few' isn't the same as 'zero'), so we still have our traditional /var/mail, complete with it being NFS mounted on all of our general use Ubuntu servers.

My strong view is that changing away from /var/mail isn't worth it for us. We're still small enough that we can get away with a single /var/mail for everyone's INBOX, so we don't actively need to change it. A change would be disruptive to some users and to many systems, and would probably take a significant amount of time and work simply to move inboxes around, never mind changing software configurations, monitoring, and everything else. And it's not clear what benefits we might get from such a change, especially since non-INBOX folders would continue to live in people's home directories on our NFS fileservers and so be available across our Ubuntu servers.

(Changing everything over to dedicated IMAP-only disk space would be a huge change with many implications, including policy ones.)

At this point, I suspect that the only way we're going to wind up moving away from our current /var/mail is if we have to completely discard our mail system for some reason and either start over from scratch or migrate everyone into the university's institutional email.

(Our use of a NFS mounted /var/mail is far from the only odd thing in our environment that has its origins deep in our history, but it's probably one of the more startling one to new people here.)

sysadmin/OurVarMailMailboxSetup written at 22:37:50; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.