The Door Nobody Checks

This weekend I tried to warn a small company that their website had been taken over. It was sending phishing mail to strangers, and I was one of the strangers. I wrote a careful letter, in their language and in English, and sent it to the only address on their site.

The next morning my own mail provider wrote back instead. The letter had not arrived and was still being retried. It would keep trying for two days and then give up.

What went wrong

The address sat on a different domain from the website, and that domain has no mail server. There is no MX record, the entry in DNS that tells the world where to deliver mail.

When that record is missing, the mail standard does something reasonable that turns out to be a trap. RFC 5321 says the address “is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.” In plain words, the sender tries to deliver to the domain’s ordinary web address instead. A web server has no reason to answer on the mail port. So the sending server knocks, gets no answer, waits, and knocks again, for days.

Nobody at the company sees any of this. The only person who learns the door is broken is the stranger outside it, and only after most of a day.

Out works, in does not

The part that stays with me is the asymmetry. The compromised site had no trouble sending mail. Phishing left that server at a steady pace. The one thing that could not get through was the warning going the other way.

I found a second way in. The website’s own domain does have a mail server, so I wrote to the two role addresses every mail domain is supposed to carry, postmaster and abuse, both named in RFC 2142 back in 1997. The server accepted postmaster within seconds. It rejected abuse outright as an unknown user.

So the letter is now in somebody’s mailbox. Whether anyone reads the postmaster mailbox at a small company on a Sunday is a separate question, and one I cannot answer from here.

In Norwegian we have a word for this, flaskepost, a message in a bottle. That is what reaching out to a stranger online feels like. You write it carefully, seal it, throw it as far as you can, and watch it drift. Most of the time nothing comes back. When something does, it is usually a machine telling you it received your bottle.

Check your own door

This takes ten minutes and needs no special tools.

1. List every address you publish, on the site, in security.txt, in footers and PDFs. Look up the MX record for each domain, with dig MX example.com or any online DNS lookup. An empty answer means mail to that domain is going somewhere you did not choose.
2. If a domain should never receive mail, say so. RFC 7505 defines a “null MX”, a record that tells senders plainly that the domain accepts no mail. They fail at once instead of retrying for days, and the person writing to you learns straight away to try another route.
3. Make postmaster and abuse real on whichever domain actually receives your mail, and have them land in a mailbox a person reads.
4. Test by sending. Write to each published address from an account outside your organisation and wait for it to arrive. A published address is a claim until something has been delivered to it.

The people most likely to tell you something is wrong are strangers. They owe you nothing, they try once, and if the door does not open they move on.

References

• RFC 5321, Simple Mail Transfer Protocol: https://www.rfc-editor.org/rfc/rfc5321
• RFC 7505, A “Null MX” No Service Resource Record for Domains That Accept No Mail: https://www.rfc-editor.org/rfc/rfc7505
• RFC 2142, Mailbox Names for Common Services, Roles and Functions: https://www.rfc-editor.org/rfc/rfc2142
• RFC 9116, A File Format to Aid in Security Vulnerability Disclosure: https://www.rfc-editor.org/rfc/rfc9116