Examples

Domain Names

The second level domain name, facebookhots, looks a bit dubious, a classic phishing domain name as we're clearly meant to mistake this for a Facebook-related domain name. A "typo" of hots instead of host and a top-level domain of biz instead of com [1].

whois says:

...
Technical Contact Name:                      Heinrich W.
Technical Contact Organization:              N/A
...
Technical Contact City:                      Dusseldorf
Technical Contact State/Province:            Nordrhein-Westfalen
...
Technical Contact Country:                   Germany
Technical Contact Country Code:              DE
...
Domain Registration Date:                    Sun Jun 14 16:35:23 GMT 2015

ie. registered in Germany only a couple of months ago (at time of writing).

CheckHelo

They all passed CheckHelo tests which suggests we need to reveal a little more about the connections made and then poke about in the DNS. Here's some PolicyD output:

host=213.108.222.158, helo=hauriantf.facebookhots.biz, from=sillandarp@hauriantf.facebookhots.biz,
host=31.41.117.5, helo=hazardousnessx.facebookhots.biz, from=forsythiasc@hazardousnessx.facebookhots.biz,
host=71.180.95.48, helo=gushinglyv.facebookhots.biz, from=parathormoneq@gushinglyv.facebookhots.biz,

Let's nose about with hauriant (as it's our new favourite word) and the following is similar for all three:

$ host hauriantf.facebookhots.biz
hauriantf.facebookhots.biz has address 213.108.222.158
hauriantf.facebookhots.biz mail is handled by 10 mail.facebookhots.biz.
$ host 213.108.222.158
Host 158.222.108.213.in-addr.arpa. not found: 3(NXDOMAIN)

ie. the HELO string is a FQDN and has an associated A record in the DNS. There isn't a reverse lookup (but that's not checked for by CheckHelo).

$ host 71.180.95.48
48.95.180.71.in-addr.arpa domain name pointer static-71-180-95-48.tampfl.fios.verizon.net.

As we never saw these hosts again, CheckHelo's multiple HELO string behaviour wasn't triggered.

CheckSPF

What's the SPF record? The mail claimed to be from sillandarp@hauriantf.facebookhots.biz so we need to check that domain, hauriantf.facebookhots.biz, and its SPF record in the DNS:

$ host -t txt hauriantf.facebookhots.biz
...
hauriantf.facebookhots.biz descriptive text "v=spf1 mx a ip4:213.108.222.158/28 ~all"

A couple of things we should note:

1. The record nominally includes the sending host's IPv4 address within the entry, ip4:213.108.222.158/28.

   Technically, though, the sending host's IP address, 213.108.222.158 is one of the broadcast addresses of the /28 subnetwork. Should CheckSPF have failed?

2. the default result is a soft fail, ~all. Which means we must pass it.

DKIM

We can't usefully probe for DKIM as we didn't get the body of the email from which we could extract the d tag from the DKIM-Signature header.

As a stab in the dark, it might be directly under the sender's domain, ie. under the _domainkey subdomain in turn:

$ host _domainkey.hauriantf.facebookhots.biz
Host _domainkey.hauriantf.facebookhots.biz not found: 3(NXDOMAIN)

So we can't really say much here.

(The problem being that the d tag in the DKIM-Signature header can be an arbitrary sub domain of the sender domain.)

DMARC

What's the DMARC record?

$ host -t txt hauriantf.facebookhots.biz
hauriantf.facebookhots.biz descriptive text "v=DMARC1\; p=none\; rua=mailto:postmaster@hauriantf.facebookhots.biz"
...

Technically, this is an incorrect record as the DMARC record should be at _dmarc.hauriantf.facebookhots.biz.

Hmm. Given that we're moderately confident the domain is a spam domain then here it is advertising that the recipient should monitor the emails if SPF and/or DKIM fail and that they should send reports to the given email address.

That sounds like the very gaming of the system mentioned before.

dmarcian provides a useful web fronted to much of this.

Finance

Commerce

Third-Party Hosted Mailing Lists

Mailing lists are one of the great banes of email change. In particular, many anti-spam techniques involve just the email envelope, ie. none of the regular email headers.

As an example, I received a legitimate email from a cash back site (I know, I know) which uses a commercial messaging organisation to deliver its emails. PolicyD can see the following envelope information:

host=91.211.243.36, helo=pmta43036.emarsys.net, from=e3-30990275343-c17eii2ea363ii3@e3.emarsys.net,

None of that information allows me, the recipient, to determine if the email is from an expected source. In the body of the email, it correctly states:

From: Cash Back <cashback@e.cashback.com>

But we don't have the body headers in our hands. There's nothing to do but pass it on to later (more expensive) processing. Ultimately, a pair of human eyes.