Dealing with /var/mail/root

Is there any automatic housekeeping on /var/mail/root or is it constantly appended to?

I'd like mail older than a month to be deleted automatically. Maybe there is some process which does this... perhaps a periodic script...
 
Sounds like handling mails as they were logfiles ;)

The housekeeping of a mailbox should be done by a mail user agent (mail program) - you should receive and read those mails (or prevent the sender from sending them).

The classic way of handling mails on a Unix system: mail/fetchmail fetches mails from your mail accounts and add them to/var/mail/yourusername; Your mail user agent is configured to read all mails from there (and not from the internet).

Without using fetchmail such a mailspool is just another mail account to your email program. But as you probably don't want to become root to read roots mails you may want to add a line
Code:
root:yourusername
to /etc/mail/aliases (and execute newaliases).
 
My experience only goes back to the mid/late 90s; Unix is older than that… How did people retrieve their emails before that? Read them via telnet?
 
How did people retrieve their emails before that?
mail(1) command. Still works that way.

Code:
   Reading Mail
       In normal usage mail is given no	arguments and checks your mail out  of
       the  post  office,  then	 prints	 out a one line	header of each message
       found.  The current message is initially	the first message (numbered 1)
       and can be printed using	the print command (which  can  be  abbreviated
       p).   You can move among	the messages much as you move between lines in
       ed(1), with the commands	+ and -	moving	backwards  and	forwards,  and
       simple numbers.
 
I wrote about receiving mails from your ISP etc. - I know the mail command only to handles the local mail spool (and that's where fetchmail came in). I vaguely remember that there was another way to access your mailbox at your ISP in order to "correct" something via "mail". But that wasn't common practice…
 
at the beginning there was no such thing as an ISP. internet was for higher govt and universities and some large businesses.
nodes that did not have tcpip were getting the mail via phone lines with uucp
 
My question was not about accessing it but whether it gets added to adinfiinittum.
/var/mail/* are the users mail spool (and not log files) - of course the operating system won't delete anything there. (But as already written you could use a MUA to delete them; also you could simply truncate the file - but your wish was to keep the last month…)
To sort out mbox files mail/procmail is a great tool, but I never saw a filter rule by date…
 
I wrote about receiving mails from your ISP etc. - I know the mail command only to handles the local mail spool (and that's where fetchmail came in). I vaguely remember that there was another way to access your mailbox at your ISP in order to "correct" something via "mail". But that wasn't common practice…
If mails from your 'public' mailaccount end up in /var/mail/root you are doing something *very* wrong...

To make system-generated mail to root a bit more organized, especially if you have several (dozen) hosts, just use forward(5) and point your mta (dma(8) by default, or something like mail/ssmtp) to either the mailserver of your mail ISP or better yet: set up a local minimal mailserver to collect all mail from your servers. e.g. postfix running on your workstation and pointing to your users maildir is perfectly fine for that.
 
My experience only goes back to the mid/late 90s; Unix is older than that… How did people retrieve their emails before that? Read them via telnet?
Yes. Or rlogin / rsh. Also pop is old and you could retrieve with with fetchmail, but that was, as far as I know, not standard.

My question was not about accessing it but whether it gets added to adinfiinittum.
Mails are there to be read. After reading them, you can delete them with 'd' in mail program.
 
You can delete all of them with d*
Or the first 10 with: d1-10

I really miss mail client for normal mail. But with html mail, attachments, imap, it is not anymore realistic.

Of course one can fetch everything with fetchmail, still use 'metamail', pass through a filter, perhaps w3m, etc.

But even heirloom mailx or snail are not very comfortable to use under such conditions.

What I never gave up is reading mail from the command line.
 
The root mail for all the servers in my basement is forwarded to a folder in my MH tree.

At $JOB-1 we sent root mail to a private USENET server. It saved and catalogued emails by server name. One would use a NNTP tool or browser (because browers supported NNTP at the time) to review root mail.

At $JOB root mail is simply left to rot in /var/spool/mail (the linux /var/mail). I've been an advocate of aliasing root to /dev/null too.
 
sh:
#!/bin/sh
DL=$(date -j -v -1m +%Y%m%d)

while true
do
did=0
D=""
D=$(head -100 /var/mail/root|grep ^Date: |head -1|sed -e 's/^Date: .*, //')
[ "X$D" = "X" ] && exit
DD=$(date -j -f "%d %b %Y %T %z" "$D" +%Y%m%d)
if [ "$DD" \< "$DL" ]
 then
     echo del msg from $DD
     echo -e "d1\npre"|mail >/dev/null
     did=1
 else
 echo "ND $DD $D"
 fi
 [ $did -eq 0 ] && break
done
this does what you want but it assumes a sorted mail box (which it normaly is).
 
Is there any automatic housekeeping on /var/mail/root or is it constantly appended to?
Unless you go to some effort to redirect it, the default setup is that mail for root is stored in that file. And, as SirDice already said, at least the output of the periodic jobs is added to it every day, week and month.

I'd like mail older than a month to be deleted automatically. Maybe there is some process which does this... perhaps a periodic script...
To my knowledge, there is no such script. It would be possible to write one, at worst by using expect and the default mail program.

Better idea: Actually read and understand those messages. That can prevent many problems.
 
To take a step behind the question - if the issue is the volume of messages you can shunt the periodic emails (daily, weekly, monthly) to a log file or /dev/null (which wouldn't likely be in your best interests). You can also tell it to only show the important stuff rather than the full informational messages (see man periodic)
 
Back
Top