Wandering Thoughts archives

2017-05-21

A 'null MX' is also useful for blocking forged senders from non-email domains

When I first considered the use of a 'null MX', I was only thinking of it as a way of blocking email to hosts that don't get email (I had a special case that made some dedicated spammer behavior unusually irritating). However, there is another useful case, and that's domains that don't send email but do get forged on spam.

A while back I wrote about a persistent phish spammer that consistently sends email using the forged sender email address of 'codewizard@approject.com'. As it happens approject.com seems to be a parked domain, with a 'this domain may be for sale' website and nothing else visible. If this is true, the owner of approject.com could cut off much of this forgery by publishing a suitable 'null MX' record in their DNS (especially now that it's an official standard, as I found out when doing research for this entry). Other owners of other parked domains could similarly cut off spam being forged in their names, and frankly there's a lot of it; spammers seem to love forging email as from domains like 'confirmation.com', 'verification.net', 'system.com', and so on.

(Some of those are not parked domains, mind you.)

Even without the new(-ish) null MX RFC, you can sort of get there today for some sites through a suitable DMARC policy and SPF records, but I think that probably requires more DNS fiddling than a simple 'MX .' entry. Plus, it only applies to people who actually use DMARC or SPF to reject message, which is not that many people right now (partly because turning on DMARC or especially SPF rejection has various often unpleasant side effects). The good news is that using DMARC probably will insure that GMail and a few other big places will reject the spammer email that is claiming to be from you.

(The more DNS fiddling is required, especially the more fiddling that must contain the domain name or the like, the less likely it is that owners of parked domains and similar things will go to the bother. One attraction of 'MX .' is that it's completely generic.)

I don't know why this use for a null MX standard didn't occur to me back then. Probably I was too close to my specific little issue and not thinking generally. Spammers have certainly been abusing generic-word domains for advance fee fraud and phish spams for years.

NullMXToBlockSending written at 00:28:11; Add Comment

2017-05-20

We now have an officially standardized 'null MX' record

Years ago, I wrote about how I wished for an official 'null MX' standard so that I could clearly advertise that some of my hosts should never be sent email although they had an A record and there was a mailer listening on that IP address. In the process of writing another entry on this, I decided to look up the current state of the draft RFC from 2013. Imagine my pleased surprise to find RFC 7505: A "Null MX" No Service Resource Record for Domains That Accept No Mail.

RFC 7505 was issued June 2015, which gives me some time to have not noticed it. The official standard is a 0-preference MX to '.' (the zero-length DNS label), which is probably slightly stricter than previous interpretations but is also probably what people have been doing anyways. Since this essentially standardizes existing practice, at least some mailers have been implementing RFC 7505 since the moment it was published; others undoubtedly don't support it yet and will either fail the mail message with an unclear error, ignore the MX entry, or consider it a temporary DNS error.

Postfix apparently picked up official support for RFC 7505 in version 3.0 (released February 2015, while the RFC was in draft). I can't find any particular indication if other mailers have picked up explicit support for it (somewhat to my surprise); perhaps the authors of them are as unaware of RFC 7505 as I've been. Alternately, they were already rejecting email for things when there was only a 'MX .' MX entry, so they don't really have anything to do.

(And of course there are plenty of really old mailers out there on the Internet that will probably skip over a 'MX .' entry as clearly malformed and carry on to try to deliver the message to the IP in the A record, just the same as before.)

Since this is now an official RFC, I'm actively tempted to publish some 'MX .' entries for some hosts and see if anything happens as a result. It would be nice to think that spam senders will notice and I'll see a drop off of delivery attempts, but I'm not really that optimistic.

NullMXNowOfficialStandard written at 00:09:06; Add Comment

By day for May 2017: 20 21; before May; after May.

Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.