Setup Postfix to Login to Your Email Account and Deliver Mail
Unless you're a sysadmin you don't generally have to worry that much about getting email delivered, you just hookup your GUI email client to your external email account and you're done. But what if your system tries to deliver mail, for example from cron? Normally, this just goes to root or perhaps some designated user on your system, but what if you'd like it to get delivered to your external email account?
The obvious answer is you setup your system to forward root's email to your external email account, eg change this line in /etc/aliases:
or you can change root's .forward file to accomplish the same thing.
So, what's the problem? The problem comes when your IP address (or your ISP's IP address) someday gets blacklisted and all of a sudden you're not getting any system mail anymore. This problem can also arise if you have scripts which deliver mail to somebody: at some point their email server may refuse to talk to your system because it thinks you're a spammer or something.
In these cases, assuming your email provider allows you to have SMTP access, one solution is to have your system deliver email to your email provider and let your email provider deliver it to the final destination. Your email provider is probably (hopefully) more likely to stay on top of problems related to their IP addresses and blacklists so your email has a higher probability of getting delivered (in the case of cron it's already at its destination).
Getting your system to deliver mail to an external email account, ie getting your system to relay mail via another server requires a bit of configuration. Few, if any, email providers allow their servers to be used as open relays, an open relay being an email relay that anyone can use. So one of the first things you have to do is tell your system how to login to your email account so that it can relay email. Furthermore you may also have to, or want to, configure your system to use TLS/SSL when it logs in so that your username and password are protected.
In this example, I'll show you how I set up my system to deliver mail to my fastmail account. I use openSUSE and therefore my system uses postfix to deliver email. If you use another Linux distro these steps may require modification, and if you use exim or some other system for email delivery this won't help at all.
First, if it's not already installed and running, install the SASL authentication daemon saslauthd and start it. Next edit the file /etc/postfix/sasl_passwd and add this line to the bottom of the file:
The values in this file determine the username and password that SASL uses when logging in to a particular server. Obviously, change these values for your external email account. You should be able to find the server name on your email provider's web site, although it usually takes some digging.
Now run postmap to convert the text password file to a .db file:
Next edit the file /etc/postfix/master.cf and uncomment the tlsmgr line:
tlsmgr unix - - n 1000? 1 tlsmgr
Now edit the file /etc/postfix/main.cf and add the following lines to the bottom of the file:
smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_type = cyrus smtp_sasl_mechanism_filter = PLAIN, LOGIN smtp_tls_security_level = verify smtp_tls_mandatory_ciphers = high smtp_tls_verify_cert_match = nexthop smtp_sasl_tls_security_options = noanonymous relayhost = [mail.messagingengine.com]:587 #debug_peer_list = mail.messagingengine.com
These options tell postfix to use SASL authentication when doing SMTP (ie delivering mail) and they also tell it to use TLS security when logging in. The relayhost option tells postfix the default server to use when relaying email, the :XXX value is the port number to use (another value you'll have to dig out of your email provider's help pages). The last option, the commented out one, debug_peer_list allows you tell postfix to show TLS related debug information on a per server basis. This is often useful when trying to diagnose TLS connection problems. In this case it turned out to be useful because postfix did not recognize the CA (certificate authority) that issued Fastmail's SSL certificate (Entrust). (Actually, I don't know if postfix recognizes any CA's out of the box.)
After some groping around on the Entrust site my SSL memory came back to me and I did a search for "root certificates" and got to a page where I could download a copy of Entrust's root certificate (you may need to start here).
Once you've downloaded the certificate, save a copy in /etc/postfix and remove group/other read/write access. Then add the following line to /etc/postfix/main.cf:
smtp_tls_CAfile = /etc/postfix/entrust_ssl_ca.cer
$ /etc/init.d/postfix restart
Now send a test email from the command line:
$ mail -s test email@example.com <<<test
And hopefully it will arrive in your external email account.
Mitch Frazier is an Associate Editor for Linux Journal.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Linux Kernel Testing and Debugging
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Returning Values from Bash Functions
- Raspberry Pi: the Perfect Home Server
- Rogue Wave Software's Zend Server
- Non-Linux FOSS: Caffeine!
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide