If you are running RHEL, you are already running a mail server. It’s installed by default and setup to run. Of course, it only delivers mail locally, and only from sources within your own machine. Right now, there are no sources, so there is no mail. But the server is running.
The original Unix way of things was to use the mail server as the primary internal message system. RHEL is old fashioned in this respect, though by default, nothing is turned on which sends any messages to the root account. If you want to learn more about what’s going on in your system, install the logwatch package with Yum and you’ll start getting daily email messages to your root account with standard notifications of newly installed packages, who logged in when, and other significant events most system administrators track. You can adjust what sorts of things logwatch tells you about, but the defaults are pretty good.
The problem is, you’d have to figure out how to read that mail. By default the simplest way to do that is to install something called Mutt — as you might expect, the package name is in lower case. Yum will take care of it easily. Then, you could login as root every day and fire up Mutt, and read the logwatch messages. Or, you could tell the mail server to give root’s mail to someone else, such as your own user account. All you have to do is login as root, and:
gedit /etc/aliases
At the very bottom of the file, simply add a line which says:
root: username
The file itself explains the format; use a TAB between the colon and your username. Then close Gedit and run the command newaliases. Then you only have to open a Terminal window every day and run Mutt yourself. Mutt is not user friendly, particularly for folks moving from Windows. I don’t like it either; I use something called Alpine. I’ll give you a hint that any email client you use, including the default Evolution on RHEL, can be set up to read mail directly from the internal mail server.
My habit is to use the commandline environment (AKA the console) for as much as possible — all my email accounts, a lot of Internet surfing, most of my editing, and so forth. If you get tired of Gedit, try nano from the commandline for editing. It’s included in RHEL by default. Most of the keystrokes you learned in Windows tend to work the same, plus the window displays several important commands at the bottom.
Unless you are setting up a commercial grade operation, you really don’t have much chance to play with mail server administration. There was a time when most ISPs and such would tolerate a Linux user running their own mail server from home. That is, you could have your machine fetch mail from your accounts and pass it internally to your mail server. Then you could send mail from your server through the official servers where your accounts resided. Those days are gone. Very few mail servers out there will accept server connections from you, typically because your IP address is listed as non-server territory. They will only talk to your email client, not your server.
If you do have a genuine server connection to the Net, and you need to run a mail server operation, it’s hard for me to rewrite the instructions provided by Red Hat in their Deployment Guide. If you know what a mail server is supposed to do, it’s not that hard to plug in the values for the configuration files.
What I do want to explain is how RHEL lays out this operation. There are three programs you’ll be running in most contexts: Postfix, Dovecot and Procmail. Dovecot is the POP and IMAP server, what allows your users and clients to get their mail from your machine. Incoming mail is caught by Postfix, which passes it to Procmail for sorting. Procmail decides who gets what. You can also have Procmail filter for spam, by plugging in SpamAssassin. You’ll need to tell your mail system the various domains for which mail is accepted and handled, and where it goes. Postfix also handles your outgoing mail. As the system administrator, you would set up all the accounts for your users. Again, the RHEL Deployment Guide is not that hard to follow.
While the current crop of CentOS HOWTOs are somewhat dated, most of the details are still accurate. If you are serious about running a mail server, it’s a good place to start. You may want to consider using their Postfix and Dovecot with SASL for running the now standard secure login features for an organizational mail server.
There are some good tutorials from other sources, though some of them a little dated. One of the simplest, and missing instructions for Procmail, is at the CentOS website. Each of the three programs have their own website with more information than you can absorb: Postfix, Dovecot has a wiki, and Procmail has links at the bottom of their page to various tutorials.
You say RHEL is already configured as a mail server but then you talk about how you use Postfix, Dovecot and Procmail. In particular Postfix also handles your outgoing mail. Ok, but you have to manually install Postfix. Good article, but a little confusing. Also, Im trying to connect to a corporate mail server from my VM. How would I go about relaying the mail to the appropriate server?
Sorry about that, Alex. It seemed clear from where I was knowing it already, and I sometimes forget what it’s like not knowing. Postfix has instructions for this on their site, and the Red Hat Deployment Guide covers it very well, but sometimes it helps to use a search engine with the terms “postfix relay server” to get some really specific stuff. It depends on whether you need SSL and other features. I rather like this one for quick-n-dirty.