All system processes that send notifications via email have been configured to use /bin/mail, rather than sendmail, as the delivery agent. This allows the system to deliver mail reliably with or without an SMTP agent like sendmail, postfix, etc. being installed. The optional Pine package may be installed as a mail client. The system admin may read mail locally using Pine or configure the included imap or pop3 daemons to read mail across the network.
Some of the processes that run on the system will periodically send email notifications about their status. For example, the cron daemon will send an email about each scheduled command it runs. The mdadm program can also be configured to monitor RAID arrays and email alerts about any change in status. These automated email messages are sent using /bin/mail which is actually a symbolic link to procmail. The procmail program delivers the message to the root mailbox in the /var/spool/mail directory.
Eventually the system admin is going to want to read the mail that has been sent. There are several ways to do this. The most primitive method is to simply read /var/spool/mail/root directly with vi. An alternative is to use the pine mail client to view and manage messages. Both of these methods involve logging onto the host. It is also possible to read mail from a different host on the network using the IMAP or POP3 protocol. Both imapd and ipop3d are installed as part of the pine package. However, because of security concerns, the imapd and ipop3d programs are written so as to not allow root logins.
Only non-root users can read mail remotely with IMAP or POP3. A simple way to let root read automated messages via these protocols is to forward mail to a non-privileged user account's mailbox. For example, if the system admin's name is Jo, create a jo account and forward root's mail to it. Mail is forwarded by creating a rule in the /root/.procmailrc file similar to the example below.
Example 1 -- .procmailrc configured to forward mail
:0 |/bin/mail jo
This simple rule tells procmail to take the contents of the message and pipe it to the /bin/mail program with the addressee being the user jo. See the procmail(1) and procmailrc(5) man pages for details.
Even though the mail system is not very complex, there are still many things that can go wrong. Here are a few tips on getting things working.
Log into the system. Send a message to a user with /bin/mail. For example, '/bin/mail testuser </etc/fstab' should append the contents of /etc/fstab to /var/spool/mail/testuser.
Use 'tail /var/spool/mail/testuser' to verify message delivery. If the message didn't make it, check that the permissions on /var/spool/mail are correct. The directory should be owned by root:root and have permissions of drwxrwxrwt (1777). /usr/bin/procmail should also be owned by root:root and have permissions set to -rwsr-xr-x (4755). The procmail program will take care of creating the individual mailboxes and setting proper ownership and permissions.
As long as mail is making its way to /var/spool/mail, users should be able to read it with pine. If mail can be read with pine, but is not accessible from IMAP or POP3, the problem may lie with the system's network configuration.
The inet daemon is responsible for starting the ipop3d and imapd when connections are made. Verify that inetd is running and that /etc/inetd.conf is configured properly. In the example below pop3 is configured to start, but imap is commented out and as such will ignore any connection attempts.
Example 2 -- inetd.conf
pop3 stream tcp nowait root /usr/sbin/ipop3d ipop3d #imap stream tcp nowait root /usr/sbin/imapd imapd
imapd must be restarted if any changes are made to its configuration file. kill -HUP $(pidof inetd) will usually do the trick. See the inetd man page for more information.
If everything looks okay up to this point, but remote mail still is not working, there may be a problem with network connectivity. Check the connection with ping. After that, try connecting to the host by using telnet on the appropriate port. For example, 'telnet neuromancer 110' will connect to the pop3 daemon on the host named neuromancer. See the example below for the expected result.
Example 3 -- response from pop3d
+OK POP3 myhost.mydomain.net 2004.89 server ready
If ping works, but telnet does not it may mean that iptables is configured to block the traffic on port 110 (pop3) and/or port 143 (imap).