In my early experience with Linux, I learned The Way for email was to run an MTA (Mail Transfer Agent) in the background, a fetching service, and did email from the commandline. My preferred setup was Postfix, Fetchmail and Pine. For those who loved, and still prefer Sendmail, feel free to chain yourself to hours of esoteric scripting on a system designed by developers who genuinely hate humans. I ran this trio off and on for years, and recently resurrected it on my CentOS box.
Postfix is still one of the simplest to configure, with lots of examples in the documentation (even for dialup connections), and even more scattered across the Net. It’s easy and secure, and I still like it best. The number one piece of information you need for using Postfix through your favorite mail service is how to establish your relayhost.
For some reason, Fetchmail doesn’t draw the same “let me help you” crowd. Recent changes in Fetchmail itself seem aimed it making it difficult enough for home users to be discouraged. For some time now, most users have learned you really need to put nodns in your configuration, because otherwise Fetchmail will download, then promptly reject mail from servers hosting multiple domains. A newer complaint from Fetchmail is regarding all those messages you get from mailing lists which don’t specifically put the precise “envelope” in the headers preferred by the Fetchmail developers. You now get warnings about “envelopes” and “multidrop” which will make no sense to the average users invoking Fetchmail from the commandline. If you read the documentation, you will find it’s carefully written to confuse you. If you ask for help on forums where Fetchmail experts hang out, you’ll get rude responses about “RTFM!” from people who know beyond all doubt you won’t understand it. All it really requires is you add no envelope to shut up the warnings. Here’s my own .fetchmailrc (obviously some details have been changed to protect my privacy):
poll mail.example.org protocol POP3 nodns no envelope
user me@example.org is user me here
password "0x0x0x0!"
The only other significant change was in Pine: It’s now Alpine, and it’s open source. Instead of settling for the version 1.0 offered by my third party repos, I chose to hunt down a RedHat-based source RPM for building 2.0. One of the newest features of no real significance is a wider array of colors for enhancing the display of Alpine on the Xterm. You can now elect to build with 256 color capability. I’m too old fashioned to care much, so I still use the original 16 colors. Still, that’s just a silly example of some changes in user configuration options and the way it works under the hood.
Aside from some minor security advantages there is no particular reason for doing things this way. It’s just that I enjoy it. I’ve configured Alpine to use Joe as the editor for composing and replying. I’m comfortable with this setup, having used it for years.
As a side note, things are not all peace and joy in CentOS Land. You really do want solid security in the server room, but on the desktop, it can be a nuisance. Some security settings simply aren’t justified for common users. The standard permission settings for users on CentOS are just a little too tight. Even without enabling SELinux, I still run into too many places where I have to login as root. For example, I cannot review any part of the system logs. It’s probably a simple matter of adding my user name to some obscure group in the system, but I haven’t worked it out yet. I may be shifting back to SUSE 11.0 (because 11.1 is too badly broken in too many places). While I don’t think 3 years is really long enough for supporting a distro release, it may be the best I can get right now.
For all you Ubuntu fanboys, forget it: No version of Ubuntu or its clones will read the detection signature of my monitor, and I have to fight like Hades to get bigger than 800×600 on a monitor designed for twice that. This is a pretty standard Dell hand-me-down CRT. Even after I install the nVidia drivers, the Ubuntu hardware recognition module ignores my monitor. The entire Debian chain of products offers no simple path to adding enough details to xorg.conf to get a reasonable display out of the box. I have to add, not only the monitor freqs, but the modelines by hand. That I know how to fix it has no bearing on the question; none of my clients should have to experience that. I am working toward supporting one or two best distros for the quickest and simplest deployment for home users.
