Posts

Root email notifications with postfix

Now that Ubuntu 18.04 is out and stable, we are busy building servers to the latest and greatest. One of the most important parts of new servers builds is root notifications. This is a common way for the server to contact you if anything goes wrong. Postfix is a popular piece of email software, alternatively you can use exim or sendmail. I will be guiding you through a Postfix install on an Ubuntu 18.04 server.

“I wanna scream and shout and let it all out”.
– will.i.am & Britney Spears

Postfix set up

Install the postfix email software:

sudo apt-get install postfix mailutils

The following screen will pop up. I am setting up a Internet site where email is sent directly using SMTP.

Next enter the server hostname.

If you want to change these settings after the initial install you can with sudo dpkg-reconfigure postfix. There are a number of other prompts for different settings, but I have found the default values are all sensible out of the box.

Now to configure where email notifications are sent to:

sudo vim /etc/aliases

In this file you should already have the “postmaster” alias set to root.  This means that any emails to postmaster are sent on to the root user, making it even more important root emails are seen.

It is good practice to set up a few other common aliases. “admin” and your admin username (In my case this was “ubuntu”).

Finally we need to send root email somewhere.  Your file should end up looking like this…

postmaster: root
admin: root
ubuntu: root
root: replaceme@example.com

Obviously “replaceme@example.com” should be an email address you have access to and check regularly.

These new aliases need to be loaded into the hashed alias database (/etc/aliases.db) with the following command:

sudo newaliases

Finally send an email to the root user (which should be sent onto the email you configured above) testing our setup is working:

echo "Testing my new postfix setup" | mail -s "Test email from `hostname`" root

Sending Problems?

If you have done the above and are still having problems sending email there are two first points of call I would check.

This command shows all queued email that is waiting to be sent out by the server. If an email is stuck it will show up here.

sudo mailq

 

All postfix actions are logged into /var/log/mail.log. You will want to look specifically at the postfix/smtpd messages as that is the process which is talking out of your server to others.

A useful tip for debugging is to use tail -f to monitor a log file for any updates. Then in another terminal session, try to send another email. You can then watch for the corresponding log entries in the original terminal. This way you can be sure which log entries you need to be focusing on.

tail -f /var/log/mail.log

 

Another thing to consider is that your server is part of the bigger internet where spam is a serious issue.

Your servers reputation is important in effecting how email is received, there are technologies you can set up to improve reputation.

Some providers have their own anti-spam protection that could be affecting you such as Google Cloud blocking all traffic on port 25, 465 and 587 & AWS throttling port 25.

Now email is working

Make sure your server scripts and crons are set up to send alerts, and not fail silently. With crons there is a variable to manage this for you, just add MAILTO=root at the top of your cron file.

Lastly, don’t fall victim to alert fatigue. It is easy to send all email to root but this will quickly become tiring. You should only get emails if something goes wrong, or if something needs to be actioned. This way, when a new email comes in you know you need to look at it.

 

Need help setting up email? Struggling with emails failing to send? Want someone else to receive and manage server notifications? Contact us and see how we can help today!

 

Feature image background by tejvan licensed CC BY 2.0.

The Dark Art of Email Deliverability

We often get questions over the technologies which help get your legitimate email delivered.  There are three main ones:

  • SPF – Used to lock down email sources to your servers
  • DKIM – To authenticate your sent emails
  • DMARC – For real world email reporting and DKIM enforcement

Email is vital to any organisation. Ensuring your emails are delivered can seem like a dark art. There are many systems at play to cut down on spam and other fraudulent emails. Over 80% of the email we receive at Dogsbody Technology is filtered out as SPAM. It can be hard for a system to recognise your legitimate email.

This makes email one of the more difficult technologies to get right.

“The Dark Arts are many, varied, ever-changing, and eternal”.
– Professor Severus Snape

 

Foreword

Our example features three characters: Alice, Bob and Sybil.

  • Alice is sending emails to Bob.
  • Bob receiving emails through Google’s Gmail.
  • Sybil is sending emails to Bob pretending to be Alice.

SPF, DKIM and DMARC is checked by the receiving email system and will affect how it handles the email. Larger email providers: Gmail, Hotmail, Yahoo, etc., are more likely to check the use of these technologies as they suffer from more SPAM than smaller hosts.

EmailBlogPost4

Sender Policy Framework; SPF

SPF is a DNS record which identifies all email sources permitted for your domain.

When an email is received the SPF record is looked up by the receiving mail server and the source IP from the email is then cross-referenced to check that it is in the SPF record.

Example SPF record for Alice’s server, example.com:

example.com. IN TXT "v=spf1 ip4:198.51.100.13 ~all"

e.g. when Alice sends an email from her domain (example.com) to Bob, Gmail receives this email and gets the source IP (198.51.100.13). Gmail then looks up the SPF record for ‘example.com’ which lists ‘198.51.100.13’ as an authorised server. Gmail knows Alice has allowed this and passes the email onto Bob.

When Sybil emails Bob as ‘example.com’ (Alice’s domain), Gmail receives the SPAM email and gets the emails source IP (203.0.113.37). When Gmail looks up the SPF record for ‘example.com’ it doesn’t list ‘203.0.113.37’ so Gmail will flag the email as SPAM.

This means that all sources sending email for your domain needs to be listed. This may include Mandrill, Google Apps for business, Socket labs, AWS SES, FreeAgent, etc.

DomainKey Identified Mail; DKIM

DKIM is a signature added to the header of an email before it is sent into the public internet. This signature shows that you are taking ownership of your email and allows any recipients to prove that.

The DKIM signature is generated with a private key and is based on the email’s contents, this make it unique to you and your email. For the receiving server to authenticate the signature a public key related to the private key is published in a DNS record. With the public key the receiving server can confirm that the DKIM signature was generated by your key. If the public key doesn’t match the signature the email will be considered as SPAM.

Example DKIM record for Alice’s server, example.com:

selector._domainkey.example.com IN TXT "v=DKIM1; p=MIGfMA0GCSq..."

For example when Alice sends an email to Bob, her server will generate and add a DKIM header to it. When Gmail receives this email it sees the DKIM header and looks up the DKIM public key record. It will check the DKIM signature against the public key. Since the email was sent through Alice’s servers the signature matches and gmail will pass the email onto Bob.

When Sybil emails Bob as Alice, Sybil’s server can generate a DKIM header, but when Gmail receives it and looks up the Signature against example.com (Alice’s) DKIM public key it will not match and Gmail will flag the email as spam. This also means that if Sybil intercepts a signed email before it reaches Gmail and changes its contents, the signature will no longer match which will flag Gmail that it had been changed.

Note that DKIM is only checked reactively, when the header is seen in an email. This is unlike SPF records which Gmail will check pro-actively.

 

Domain-based Message Authentication, Reporting & Conformance; DMARC

DMARC is a DNS record containing information regarding which anti-spam technologies the sending domain is using, and telling receivers to report back what they see.

When an email is received the receiving server looks up the DMARC record for the sender. This record includes flags detailing if SPF and/or DKIM are in use. The receiving server is then able to use this extra information to ensure that the received email is authenticated as the sender intended. If an email comes in which doesn’t meet the SPF and DKIM information provided by the DMARC record, the DMARC record also specifies guidance of how the receiver should act in the case of an authentication failure. e.g. If the message should be let through, put in junk or rejected completely.

Additionally, each ISP that supports DMARC is encouraged to send a report to the contact specified in the DMARC record. The report shows totals of email received and how the ISP dealt with these emails. The ISP can send a report at any time after it starts receiving emails, this is often daily.

Example DMARC record for Alice’s server, example.com:

_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com;"

e.g. When Alice sends an email to Bob, Gmail will receive her email and look up the example.com DMARC record. Gmail will then check that the email it received uses DKIM and SPF to authenticate as set in the DMARC record. It does and Gmail will pass it onto Bob.

If Sybil sends an email as example.com to Bob, Gmail will receive it and look up the DMARC record for example.com. It then checks that SPF and DKIM were used to authenticate the email and it will fail as neither SPF or DKIM will match the DMARC record. Gmail may then follow the DMARC policy ‘quarantine’ and put Sybil’s email into Bobs Junk mail folder. Gmail can then report to Alice that it received an email from the server ‘203.0.113.37’ (example.net) spoofing example.com, and that it failed SPF and DKIM checks.

DMARC reports will come from each receiving server and a spammer can easily send thousands and thousands of emails in an instant. These reports can quickly build up. Dmarcian is a tool which will break down these report into usable graphs and summaries helping you understand them.

dmarcian

These reports show all sources of emails sent from the domain and if DKIM and/or SPF was used to authenticate them, providing real world information on how your domain’s emails are being received out on the internet. It shows if there are any unknown sources impersonating the domain. All of this helps to understand the domain’s email reputation and how deliverable emails are.

DMARC gives you information. Information is power.

Conclusion

Globally SPAM has been going down and it will continue to do so only if more email systems implement these technologies. These have been just one example of how SPF, DKIM and DMARC can protect a domain. There are many more implementations that have their own specific requirements. If you want to improve the deliverability or want more information on how your emails looks to others, these technologies will give you this advantage. Don’t let Sybil spoof you.

Let us build your perfect email infrastructure.

 

Icons in used in images made by Freepik from www.flaticon.com is licensed by CC BY 3.0.
Feature image made by Christian Barmala licensed CC BY 2.0.