RHEL 6 for the Clueless: the Mail Server

By Ed Ed | Posted at 0:38

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. The problem is we don't have time and space for me to teach you all my peculiar tastes. 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 because 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 SpamAssasin. 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.

Re: RHEL 6 for the Clueless: the Mail Server

Alongside going about as a web server, email is one of the essential employments of a Red Hat Enterprise Linux 6 based framework, especially in business situations. Given both the significance and ubiquity of email it is shocking to a few people to discover how complex the email structure is on a Linux framework and this many-sided quality can regularly be a bit of overpowering to the RHEL newcomer. The uplifting news is that a significant part of the intricacy is there to permit experienced email heads to accomplish muddled arrangements for vast scale endeavor establishments. The truth of the matter is that for most Linux clients it is generally straight forward to set up an essential email framework with the goal that they can send and get electronic mail.

Posted by best essay writing service - Mar 9, 2017 | 6:52

Please enter your comment entry below. Press 'Preview' to see how it will look.

Sign In to Your Account
User Name:
:mrgreen: :neutral: :twisted: :arrow: :shock: :smile: :???: :cool: :evil: :grin: :idea: :oops: :razz: :roll: :wink: :cry: :eek: :lol: :mad: :sad: :!: :?:
Home About Connect: Twitter Facebook RSS
© 2001-2012 Universal Networks, All Rights Reserved. Some content rights may be held by Universal Networks' providers and used under license. Powered by ServerForest and SAFARI. Learn about our privacy policy here.