{"id":953,"date":"2011-01-11T15:01:19","date_gmt":"2011-01-11T20:01:19","guid":{"rendered":"http:\/\/blog.timeoff.org\/rick\/?p=953"},"modified":"2011-05-05T16:01:11","modified_gmt":"2011-05-05T20:01:11","slug":"communicating-with-the-outside-world","status":"publish","type":"post","link":"https:\/\/blog.timeoff.org\/rick\/2011\/01\/11\/communicating-with-the-outside-world\/","title":{"rendered":"Communicating With The Outside World"},"content":{"rendered":"

I recently set out to upgrade a virtual host server from VMware Server to Oracle’s VirtualBox. The upgrade was a huge success. This is one of several articles where I talk about various aspects of that upgrade, hopefully helping others along the way. You might want to go back and read the introductory article Virtualization Revisited<\/a>. Added 5-May-2011: Originally written using Ubuntu Server 10.04, this configuration also works without change on Ubuntu Server 11.04.<\/em><\/p>\n

One of the things that I wanted from the new VM host was alerts for anomalous situations. Manually polling for trouble begins as a noble effort but trust me – after a while you’ll stop looking. About a year ago I was almost caught by a failing hard drive in a RAID array. Even after that incident, within a month or two I had pretty much stopped paying regular attention.<\/p>\n

While setting up monitor\/alert mechanisms on an old Windows server is quite the pain in the ass it’s a snap on Linux. Delivery of alerts and status reports via email is just perfect for me. All I wanted was the ability to have the system generate SMTP traffic; no messages would ever be received by the system. To prepare for that I set up a send-only email account to use the SMTP server on one of my domains solely for the VM host’s use as a mail relay. Then I got on with configuring Postfix<\/a>, the standard Ubuntu\u00c2\u00a0mailer – one of several excellent sendmail alternatives.<\/p>\n

Now maybe I’m just a dummy, but I found various aspects of the Postfix and related configurations to be a little tricky. Hence this article, which details what worked for me – and should work for you, too.<\/p>\n

(In the stuff that follows, my example machine is named foo<\/em> and it’s on an internal TLD called wan<\/em>. My example machine’s system administrator account is sysadmin<\/em>. My SMTP server is on mail.example.com<\/em> listening on port 1212<\/em>. The SMTP account is username<\/em> with a password of yourpassword<\/em>.)<\/p>\n

Getting Started – Basic Configuration<\/h4>\n

Begin by installing Postfix, as you would any package.<\/p>\n

$ sudo apt-get install postfix<\/code><\/p>\n

For now, just hit Enter through the install questions. We’ll configure it properly following the install. You’ll be asked for the general type of mail configuration<\/em> and Internet Site<\/span> will be the default. Accept that by pressing Enter. You’ll be asked for the System mail name<\/em> and something will probably be pre-filled. Accept that, too.<\/p>\n

Now, go back and do a proper basic configuration.<\/p>\n

$ sudo dpkg-reconfigure postfix<\/code><\/p>\n

Several questions will follow. Here’s how to respond.<\/p>\n

For the general type of mail configuration<\/em> choose Internet Site<\/span>.<\/p>\n

Set the domain name for the machine. The panel provides a good explanation of what’s needed here, and chances are good that it’s pre-filled correctly. By example, foo.wan<\/code>.<\/p>\n

Provide the username of the system administrator. The panel provides a good explanation of what’s needed here. Use the name of the account that you specified when you installed Ubuntu. By example, sysadmin<\/code>.<\/p>\n

Provide a list of domains<\/em> for which the machine should consider itself the final destination. The panel provides an OK explanation and it’s probably already pre-filled more-or-less correctly. But look carefully at the list that appears in the panel and edit it if it has obvious errors like extra commas. Again, using my example machine, a list like this is appropriate:<\/p>\n

foo.wan, localhost.wan, localhost<\/code><\/p>\n

You’ll be asked whether or not to force synchronous updates<\/em> on the mail queue. Answer No<\/span>, which is likely the default.<\/p>\n

Next, specify the network blocks<\/em> for which the host should relay mail. This entry is pre-filled based on the connected subnets. Unless you’ll be using an external SMTP server that requires it, you can simply remove all of the IPv6 stuff that appears here, leaving only the IPv4 entry which will probably look something like this:<\/p>\n

127.0.0.0\/8<\/code><\/p>\n

Specify the mailbox size limit. The default is zero, meaning no limit. Accept that. Remember, all we’re planning to do is send mail, not receive it.<\/p>\n

Set the character used to define a local address extension<\/em>. The default is +<\/span>. Accept it.<\/p>\n

Choose the Internet protocols to use. Again, keeping with our earlier IPv4 decision select ipv4<\/span> from the list and accept it.<\/p>\n

That’s it for the basic Postfix configuration! Next you’ll configure Postfix to do SMTP AUTH using SASL (saslauthd).<\/p>\n

SMTP AUTH using SASL (saslauthd)<\/h4>\n

Since there are several commands to issue as root it’s convenient to sudo<\/code> yourself as root to save some typing. Good practice dictates you should logout the root account just as soon as you’re finished.<\/p>\n

Be careful. In this list of commands there is one – it sets smtpd_recipient_restrictions – that is quite long and may have wrapped on your display. Be sure to issue the entire command.<\/p>\n

$ sudo -i
\n# postconf -e 'smtpd_sasl_local_domain ='
\n# postconf -e 'smtpd_sasl_auth_enable = yes'
\n# postconf -e 'smtpd_sasl_security_options = noanonymous'
\n# postconf -e 'broken_sasl_auth_clients = yes'
\n# postconf -e 'smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination'
\n# postconf -e 'inet_interfaces = all'
\n# echo 'pwcheck_method: saslauthd' >> \/etc\/postfix\/sasl\/smtpd.conf
\n# echo 'mech_list: plain login' >> \/etc\/postfix\/sasl\/smtpd.conf
\n<\/code><\/p>\n

Then press ctrl-D to logout the root account.<\/p>\n

The next step is to configure the digital certificate for TLS.<\/p>\n

Configure the Digital Certificate for TLS<\/h4>\n

Some of the commands that follow will ask questions. Follow these instructions and answer appropriately, modifying your answers to suit your situation. As earlier, sudo<\/code> yourself to root and logout from root when finished.<\/p>\n

$ sudo -i
\n# openssl genrsa -des3 -rand \/etc\/hosts -out smtpd.key 1024<\/code><\/p>\n

You’ll be asked for the smtpd.key passphrase<\/em>. Enter one and remember it. You’ll need to type it twice, as is customary when creating credentials. Then continue.<\/p>\n

# chmod 600 smtpd.key
\n# openssl req -new -key smtpd.key -out smtpd.csr<\/code><\/p>\n

You’ll be asked for your smtpd.key passphrase. Enter it.<\/p>\n

Next you’ll be asked a series of questions that will make up a Distinguished Name, which is incorporated into your certificate. There’s much you can leave blank by answering with a period only. Here’s a sample set of responses (underlined) based on my US location and example system.<\/p>\n

Country Name (2 letter code) [AU]:US<\/span>
\nState or Province Name (full name) [Some-State]:Texas<\/span>
\nLocality Name (eg, city) []:.<\/span>
\nOrganization Name (eg, company) [Internet Widgits Pty Ltd]:.<\/span>
\nOrganizational Unit Name (eg, section) []:.<\/span>
\nCommon Name (eg, YOUR name) []:Rick<\/span>
\nEmail Address []:sysadmin@foo.wan<\/span>
\nA challenge password []:some-challenge-password<\/span>
\nAn optional company name []:.<\/span><\/code><\/p>\n

Then continue.<\/p>\n

# openssl x509 -req -days 3650 -in smtpd.csr -signkey smtpd.key -out smtpd.crt<\/code><\/p>\n

You’ll be prompted for your smtpd.key passphrase. Enter it.<\/p>\n

Then continue.<\/p>\n

# openssl rsa -in smtpd.key -out smtpd.key.unencrypted<\/code><\/p>\n

You’ll be prompted for your\u00c2\u00a0smtpd.key passphrase. Enter it.<\/p>\n

Then continue.<\/p>\n

# mv -f smtpd.key.unencrypted smtpd.key
\n# openssl req -new -x509 -extensions v3_ca -keyout cakey.pem -out cacert.pem -days 3650<\/code><\/p>\n

You’ll be asked for a PEM passphrase<\/em>. Enter one and remember it. You’ll need to type it twice, as is customary when creating credentials.
\nLike earlier, you’ll be asked a series of questions that will make up a Distinguished Name, which is incorporated into your certificate. There’s much you can leave blank by answering with a period only. Here’s a sample set of responses (underlined) based on my US location and example system.<\/p>\n

Country Name (2 letter code) [AU]:US<\/span>
\nState or Province Name (full name) [Some-State]:Texas<\/span>
\nLocality Name (eg, city) []:.<\/span>
\nOrganization Name (eg, company) [Internet Widgits Pty Ltd]:.<\/span>
\nOrganizational Unit Name (eg, section) []:.<\/span>
\nCommon Name (eg, YOUR name) []:Rick<\/span>
\nEmail Address []:sysadmin@foo.wan<\/span><\/code><\/p>\n

Next, issue the remaining commands.<\/p>\n

# mv smtpd.key \/etc\/ssl\/private\/
\n# mv smtpd.crt \/etc\/ssl\/certs\/
\n# mv cakey.pem \/etc\/ssl\/private\/
\n# mv cacert.pem \/etc\/ssl\/certs\/<\/code><\/p>\n

Then press ctrl-D to logout the root account.<\/p>\n

Whew! We’ll continue by configuring Posfix to do TLS encryption for both incoming and outgoing mail (even though we’re only planning on sending mail at this point).<\/p>\n

Configure Postfix to Do TLS Encryption<\/h4>\n

As earlier,\u00c2\u00a0sudo<\/code> yourself to root and logout from root when finished.<\/p>\n

$ sudo -i
\n# postconf -e 'smtpd_tls_auth_only = no'
\n# postconf -e 'smtp_use_tls = yes'
\n# postconf -e 'smtpd_use_tls = yes'
\n# postconf -e 'smtp_tls_note_starttls_offer = yes'
\n# postconf -e 'smtpd_tls_key_file = \/etc\/ssl\/private\/smtpd.key'
\n# postconf -e 'smtpd_tls_cert_file = \/etc\/ssl\/certs\/smtpd.crt'
\n# postconf -e 'smtpd_tls_CAfile = \/etc\/ssl\/certs\/cacert.pem'
\n# postconf -e 'smtpd_tls_loglevel = 1'
\n# postconf -e 'smtpd_tls_received_header = yes'
\n# postconf -e 'smtpd_tls_session_cache_timeout = 3600s'
\n# postconf -e 'tls_random_source = dev:\/dev\/urandom'<\/code><\/p>\n

This next configuration command sets the host name, and this one uses my example machine’s host name. You should use your own instead.<\/p>\n

# postconf -e 'myhostname = foo.wan'<\/code><\/p>\n

Then press ctrl-D to logout the root account.<\/p>\n

The postfix initial configuration is complete. Run the following command to start the Postfix daemon:<\/p>\n

$ sudo \/etc\/init.d\/postfix start<\/code><\/p>\n

The Postfix daemon is now installed, configured and runing. Postfix supports SMTP AUTH as defined in RFC2554. It is based on SASL. It is still necessary to set up SASL authentication before you can use SMTP.<\/p>\n

Setting Up SASL Authentication<\/h4>\n

The libsasl2-2 package is most likely already installed. If you’re not sure and want to try to install it you can, no harm will occur. Otherwise skip this command and simply continue.<\/p>\n

$ sudo apt-get install libsasl2-2<\/code><\/p>\n

Let’s continue the SASL configuration.<\/p>\n

$ sudo mkdir -p \/var\/spool\/postfix\/var\/run\/saslauthd
\n$ sudo rm -rf \/var\/run\/saslauthd<\/code><\/p>\n

Create the file \/etc\/default\/saslauthd<\/code>.<\/p>\n

$ sudo touch \/etc\/default\/saslauthd<\/code><\/p>\n

Use your favorite editor to edit the new file so that it contains the lines which follow. Just to be clear, the final line to add begins with “MECHANISMS=<\/code>“.<\/p>\n

# This needs to be uncommented before saslauthd will be run
\n# automatically
\nSTART=yes<\/code><\/p>\n

<\/code><\/p>\n

PWDIR=\"\/var\/spool\/postfix\/var\/run\/saslauthd\"
\nPARAMS=\"-m ${PWDIR}\"
\nPIDFILE=\"${PWDIR}\/saslauthd.pid\"<\/code><\/p>\n

<\/code><\/p>\n

# You must specify the authentication mechanisms you wish to use.
\n# This defaults to \"pam\" for PAM support, but may also include
\n# \"shadow\" or \"sasldb\", like this:
\n# MECHANISMS=\"pam shadow\"<\/code><\/p>\n

<\/code><\/p>\n

MECHANISMS=\"pam\"<\/code><\/p>\n

Save the file.<\/p>\n

Next, update the dpkg state<\/em> of \/var\/spool\/portfix\/var\/run\/saslauthd<\/code>. The saslauthd init script uses this setting to create the missing directory with the appropriate permissions and ownership. As earlier,\u00c2\u00a0sudo<\/code> yourself to root and logout from root when finished. Be careful, that’s another rather long command that may have wrapped on your display.<\/p>\n

$ sudo -i
\n# dpkg-statoverride --force --update --add root sasl 755 \/var\/spool\/postfix\/var\/run\/saslauthd<\/code><\/p>\n

Then press ctrl-D to logout the root account.<\/p>\n

Test using telnet to connect to the running Postfix mail server and see if SMTP-AUTH and TLS are working properly.<\/p>\n

$ telnet foo.wan 25<\/code><\/p>\n

After you have established the connection to the postfix mail server, type this (substituting your server for mine, of course):<\/p>\n

ehlo foo.wan<\/code><\/p>\n

If you see the following lines (among others) then everything is working perfectly.<\/p>\n

250-STARTTLS
\n250-AUTH LOGIN PLAIN
\n250-AUTH=LOGIN PLAIN
\n250 8BITMIME<\/code><\/p>\n

Close the connection and exit telnet with this command.<\/p>\n

quit<\/code><\/p>\n

We’re almost there, promise.<\/p>\n

Setting External SMTP Server Credentials<\/strong><\/p>\n

Remember, we set out to use an external Internet-connected SMTP server as a mail relay and this is how that is set up. I mentioned at the beginning of the article that I had set up a dedicated account on one of my domains. You might use one on your ISP. I would not, however, use your usual email account.<\/p>\n

You’ll need to manually edit the \/etc\/postfix\/main.cf<\/code> file to add these lines:<\/p>\n

smtp_sasl_auth_enable = yes
\nsmtp_sasl_security_options = noanonymous
\nsmtp_sasl_password_maps = hash:\/etc\/postfix\/saslpasswd
\nsmtp_always_send_ehlo = yes
\nrelayhost = [mail.example.com]:1212<\/code><\/p>\n

Of course, you’ll modify the relayhost = line to specify your external SMTP server. If you don’t need a port number then simply leave off the colon and port number following the closing bracket. I included the port number as a syntax example in case you needed to use one.<\/p>\n

Did you notice the hash file mentioned in the lines you just added to\/etc\/postfix\/main.cf<\/code>? It holds the SMPT server logon credentials, and it’s time to create it.<\/p>\n

$ sudo touch \/etc\/postfix\/saslpasswd<\/code><\/p>\n

Use your favorite editor to edit the file, adding the credentials with a line like this:<\/p>\n

mail.example.com username@example.com:yourpassword<\/code><\/p>\n

The components of the line you’re putting in the new file should be obvious.<\/p>\n

(Before you cry foul… Yes, I’m well aware of the risk of storing credentials in the clear. It’s a manageable risk to me in this case<\/em> for the following reasons. The physical machine is under my personal physical control. The credentials are dedicated to this single purpose. If the server becomes compromised\u00c2\u00a0I can disable the credentials from anywhere in the world I can obtain an Internet connection. If I’m dead and can’t do that, well, I guess it’s SEP and my incremental contribution to the SPAM of the world will torment my soul until the end of time. Your situation may be different and I leave it to you to secure the credentials.)<\/p>\n

Anyway, before postfix can use that horribly insecure file it needs to be hashed by postmap:<\/p>\n

$ sudo postmap \/etc\/postfix\/saslpasswd<\/code><\/p>\n

With that done, restart postfix.<\/p>\n

$ sudo \/etc\/init.d\/postfix restart<\/code><\/p>\n

Applications that know how will now be able to generate mail but it’ll be convenient to be able to do it from the command line. Besides making testing of this configuration easier you’ll then be able to have your own scripts send messages with ease. For that you’ll need just one more package.<\/p>\n

Installing the mailutils Package<\/h4>\n

Simple. Install the mailutils package.<\/p>\n

$ sudo apt-get install mailutils<\/code><\/p>\n

That’s it!<\/p>\n

Try test sending some email from the command line. Substitute the address at which you usually receive mail for my example youraddress@yourserver.com<\/code>.<\/p>\n

$ echo \"body: outbound email test\" | mail -s \"Test Subject\" youraddress@yourserver.com<\/code><\/p>\n

Check your inbox.<\/p>\n

Wrapping Up<\/h4>\n

Well, that wasn’t so bad.<\/p>\n","protected":false},"excerpt":{"rendered":"

I recently set out to upgrade a virtual host server from VMware Server to Oracle’s VirtualBox. The upgrade was a huge success. This is one of several articles where I talk about various aspects of that upgrade, hopefully helping others along the way. You might want to go back and read the introductory article Virtualization … Continue reading Communicating With The Outside World<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[4],"tags":[82,84,8,83,7,81],"_links":{"self":[{"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/posts\/953"}],"collection":[{"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/comments?post=953"}],"version-history":[{"count":0,"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/posts\/953\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/media?parent=953"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/categories?post=953"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.timeoff.org\/rick\/wp-json\/wp\/v2\/tags?post=953"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}