First, you need to set up .forward files for the system accounts that just don't need to be receiving email. A .forward file that dumps email to /dev/null can be as simple as this:
If you've ever tried this and found that it didn't work, you might not have taken into consideration how fussy sendmail can be about file permissions. If sendmail thinks the permissions on your .forward file aren't proper and secure, it ignores them and might or might not write messages into your syslog file complaining about the problem.
You also need to make sure that the .forward files are owned by the appropriate user. For example, listen might have /usr/net/nls as its home directory. A /usr/net/nls/.forward file should look like this:
# ls -l /usr/net/nls/.forward -rw------- 1 listen other 12 Oct 13 14:24 /usr/net/nls/.forward
Too bad we have to do things like this, but it beats using up the space in /var/mail with spam and it beats collecting files in /var/spool/mqueue as our too polite mail service tries to return undeliverable messages to their senders.
If, for some reason, you expect one of these administrative accounts to actually receive meaningful email, you should probably use a more sophisticated approach, such as a procmail filter, to separate the spam from the legitimate email and send it to /dev/null.
This simple approach is likely to run into a snag when it comes to adm. Since adm's home is usually /var/adm and this directory needs to be group writable, sendmail is likely to ignore any .forward files placed in this directory, complaining that "/var/adm/.forward is a "Group writable directory". One option is to redefine adm's home to some other directory. If you opt for this, make sure this has no effect on your /var/adm log files, both before and after a reboot.
Sending spam addressed to system accounts may seem like a small deal but on one system that I implemented the .forward files on, the ls /var/spool/mqueue directory went from building up to thousands of files to generally being empty. Spam addressed to real users still arrives, but that's a job for another tool. Maybe next week we'll look at procmail.
This article is published as part of the IDG Contributor Network. Want to Join?