DMARC |

VPOP3 v7.8 adds DMARC checking support, so this post is to give you more information about DMARC.

Note that to have VPOP3 check incoming messages using DMARC, it must receive messages using direct incoming SMTP (not via a third party’s SMTP server, and not from a POP3 mailbox) and you must have either VPOP3 Enterprise or an active VPOP3 Spamfilter subscription.

Email message authentication is an important issue, because a lot of email attacks are performed by sending messages pretending to be from someone else. For instance, it is not uncommon for a fraudster to send a message claiming to be from a supplier asking to transfer money to the fraudster’s bank account, or claiming to be a bank asking to verify bank login details.

The subject of message authentication is not a trivial one, and it needs a degree of understanding of what is going on behind the scenes. Doing it badly can lead to messages going missing for no apparent reason. So, this article will try to explain, in basic terms, what is happening and what needs to be done.

Message Authentication

Two main methods of email message authentication have been developed over the years. These are SPF and DKIM.

SPF

SPF works by looking at the domain of the ‘return path’ of the message, and seeing which IP addresses are authorised to send messages from that domain. This is done via DNS records, because only the owner of the sending domain can set those.

For instance, the owner of the example.com domain, could create an SPF DNS record saying that messages from anyone@example.com can only come from the IP address 11.22.33.44. Then, when a mail server receives a message from that domain, it can check the DNS record and the sending IP address, and reject (or otherwise filter) the message if the sending IP address is not 11.22.33.44

This would be done by the owners of the example.com domain, creating a TXT DNS record for example.com with these contents:

v=spf1 ip4:11.22.33.44 -all

This indicates that it is an SPF rule (v=spf1) that IPv4 address 11.22.33.44 is allowed (ip4:11.22.33.44), and mail from all other IP addresses should be rejected (-all)

One problem with this is that people are still using email forwarding nowadays, so if that message from anyone@example.com is sent to bob@mydomain.com and mydomain.com‘s mail server forwards the message on to gmail, then gmail will see the message as coming from the mydomain.com mail server, not from 11.22.33.44. So, gmail may then reject the message, and, worse, may mark the mydomain.com mail server as being a spamming mail server, causing other messages from that server to be rejected as well.

Another problem is that often people don’t know all the places that their mail may come from, for instance, while people at a company may send mail through a particular mail server, their website may send mail through a different mail server, and they may use third party accounts or payroll software that sends mail on their behalf, but through other mail servers, or they may use a mail service provide (eg MailChimp or SparkPost) which sends mail from their domain as well.

A third problem is that SPF validates the Return Path of the message, but that is often invisible to the recipient. There is no need for the Return Path to match the From header (which is what the recipient usually sees), and, in fact, there are may good reasons for it not to match.

To set up SPF authentication for your outgoing messages, you just need to create a TXT DNS record for your domain. The sending mail server does nothing special.

DKIM

DKIM works in a totally different way from SPF. In this case, rather than authenticating where a message comes from, it authenticates the message itself. Again, this uses DNS because that is only configurable by the sending domain’s administrators.

A public key/private key pair is generated by the administrators. The private key is configured into the mail server and the public key is stored in a DNS record for the domain. You choose a name called the ‘selector’, eg ‘s1’ and then create a DNS TXT record as s1._domainkey.example.com and put the public key into that TXT record.

Now, the sending mail server will extract key parts of the sent message – the subject, sender, recipients, message content and create a digital signature of that data using the private key. This digital signature is inserted into the message header, eg:

DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
	s=xzr7cjj46bvb5ib4fyyv5hcqwj7o5lx2; d=amazon.co.uk; t=1539000354;
	h=From:To:Message-ID:Subject:MIME-Version:Content-Type:Date;
	bh=cfr74rA220F+BvvXw66U2JSysUkjInxZeuVq2vr47SA=;
	b=cEEjW3tFTmDX9XBFOcjzPuLLvNn37FObJZpGm40azYHIab3lnhdmGAdnniGq9+RP
	7Dyi/5AhANOPhHU6zJ+FHzsULQVny8kfWjHNW/t4CQWigni5efoD9rIX8BAsi35Cbor
	JMKmBFBjncBeo6U0XGLPONgMCQEr9hYNj/oKe6M4=

(This is an example of a message from amazon.co.uk, with the selector ‘xzr7…’. The bh= and b= fields are the digital signatures of the headers and data respectively, and it is signing the From, To, Message-ID, Subject, MIME-Version, Content-Type and Date headers, as well as the message content.)

If you look for a DNS TXT record at xzr7cjj46bvb5ib4fyyv5hcqwj7o5lx2._domainkey.amazon.co.uk you will find the public key which is used to verify the digital signatures:

xzr7cjj46bvb5ib4fyyv5hcqwj7o5lx2._domainkey.amazon.co.uk. 900 IN CNAME xzr7cjj46bvb5ib4fyyv5hcqwj7o5lx2.dkim.amazonses.com.
xzr7cjj46bvb5ib4fyyv5hcqwj7o5lx2.dkim.amazonses.com. 718 IN TXT "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoXXbwsbFrOLoiYLjkxW2VqIHN5XtlimenJYBMryjIcBBoyEFoyjD6LfThjlmmlLYB8PzKsWaCukDWKQv0jBxalFxfHJblvFkE
R30SVfHoqkrnkCjb+rFm1cR1Iyv2Rig2CM5ebFulpXcIQtHFgvYq0WSzelDypxFd488b+lXA5QIDAQAB"

So, the receiving mail server can verify that the From, To, Subject and message content is exactly the same as it was when the sender sent it. That sounds great because the recipient will know that what they received was exactly what was sent through a valid mail server.

One problem with this is that the digital signature breaks if something changes the message. So, if something adds ‘Virus scanned by ….’ to the bottom of your message, that will break the DKIM signature, or if your message goes to a mailing list which adds a signature or alters the subject line, that will break the DKIM signature, etc.

Another problem is that there is no ‘policy’ associated with the message. If a message arrives without a digital signature, the receiving mail server will accept it as normal, because it won’t know that it should contain a signature, and if the signature doesn’t work, the receiving mail software doesn’t know what to do, so it may warn about it, but probably not, because there are many legitimate ways that the digital signature can be broken.

So, what is DMARC?

DMARC is not a new method of method authentication. In fact, it builds on both the SPF and DKIM methods and adds policy and feedback mechanisms to it.

Like SPF and DKIM, a DMARC policy is created by publishing a DNS record for the sending domain – but this time it is the domain of the FROM header field, not the domain of the Return Path, so it validates what the recipient can see.

So, the sending domain owner will create a TXT DNS record like _dmarc.example.com with content like

v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com

This sets a policy where if a message fails authentication it should be quarantined, and the domain owner wants ‘aggregate feedback reports’ to be sent to the email address dmarc-feedback@example.com.

When a message is received using SMTP by a mail server which supports DMARC, that server will do both SPF and DKIM checks on the incoming message using the mechanisms based above. Then, if it can find a valid SPF or DKIM result using the same domain as the FROM header field, the message will be deemed to have passed the DMARC check. So, that means that either the Return-Path or the DKIM header need to match the FROM header domain, and need to have passed the SPF or DKIM validation.

If the message doesn’t pass the DMARC validation, then the policy of the DMARC record indicates what should happen. This can either be none – the message is processed as normal, quarantine – the message should be quarantined, or reject – the message should be rejected. (These policies can be overridden by the receiving mail server, they’re just ‘recommendations’).

Also, if an rua record is present in the DMARC record, then a DMARC aggregate report will be sent to the specified email address(es) showing how many messages passed or failed DMARC verification and which IP addresses they came from. These aggregate reports are in a structured XML format, so aren’t easily human-readable, but there are tools such as DMARCIAN which can be used to process the aggregate reports to make something more user-friendly. Note that if the email address(es) specified are not in the same domain as the DMARC policy, then you need to perform extra steps (to avoid people publishing DMARC records asking for reports to be sent to someone else’s email address without their permission).

You can set up DMARC with a ‘p=none’ policy just to get the aggregate reports which can be used to evaluate whether a stricter policy can be used, by checking to see where legitimate mail from you is coming from. It may also show which mail systems need reconfiguring, for instance, to sign messages using DMARC, or need to be added to an SPF record.

Checking DMARC in VPOP3

In VPOP3, to enable DMARC checking, you do this in Services -> SMTP Server -> Spam Reduction and turn on Check DMARC policies. To use this you must have either VPOP3 Enterprise or a VPOP3 Spamfilter subscription. Turning on DMARC checking will automatically enable SPF and DKIM checking as well, as those are required.

Sending DMARC compliant mail using VPOP3

You need to enable DKIM signing in VPOP3 and create your SPF and DMARC DNS records, and then VPOP3 will be sending messages which should pass DMARC checks

TL;DR

To use DMARC for your outgoing emails, you need to set up SPF and DKIM and create a DMARC DNS record. Most of this is done outside of VPOP3, but DKIM signing is enabled inside VPOP3.

If you need help setting up DMARC, then we can help, but as it is not a VPOP3 issue, it will be charged at £40 + VAT per hour (1 hr minimum).

news and info

DMARC

Message Authentication

SPF

So, what is DMARC?

Checking DMARC in VPOP3

Sending DMARC compliant mail using VPOP3

TL;DR

Further reading

Post a Comment Cancel reply