Spammers do forge various noreply@<you> sender addresses

May 31, 2024

It is probably not news to anyone reading this that some of the time, spammers sending you email will forge the email as being from various addresses at your domain, for either or both of the SMTP 'MAIL FROM' envelope sender address and the From: header address. Spammers have been doing this to us for years. What I hadn't realized until now, when I looked at the actual addresses being forged, was that spammers were forging various variations on 'noreply@<us>', in various variations of words and cases. Over the past ten days we've seen all of 'noreply@', 'Noreply@', 'Nonreply@', 'no_reply@', 'NOREPLY@', 'no-reply@', and 'NO-REPLY@'.

Of course, spammers also forge various plausible administrative addresses as well, such as 'Administrator@', 'Admin@', 'cpanel@', 'support@' (and 'Support@'), and one case of 'hr@', as well as the expected 'postmaster@'. These are almost all addresses that don't exist here and never have, so I'm pretty confident that spammers are just making them up instead of drawing them from a list of (past) legitimate email addresses of people here. I suspect that some or perhaps many of these forged addresses are being used on phish spams, and this is probably the case for the various 'noreply@' addresses.

(Spammers clearly use old email address lists to generate their envelope sender addresses, because we reject a lot lot of SMTP 'MAIL FROM' addresses that used to be real email addresses here but which have since been removed (we do eventually close some accounts). Interestingly, there is also a relatively frequently forged sender address that is a single-letter typo for a real person's email address.)

One of the lessons I draw from this little exercise in curiosity is that if we've created administrative-like email addresses in our system simply to reserve them, and we aren't using them, we should actively block their use as external sender addresses. If we want to create a dummy 'cpanel@' address, for example, we should definitely make it so that it's not accepted as a SMTP envelope sender.

(Because of some features of our mail environment, people here can created valid email addresses without our involvement (this has various entirely legitimate uses, including expendable personal email addresses). Historically this has meant that we grabbed a number of addresses simply as precautions to reserve them, without ever intending them to be 'legitimate'.)

PS: We do have a local noreply-like address, for internal use. However, spammers don't seem to forge it on their messages, perhaps because it basically never appears on email we send to actual people and thus has never made it onto various spammer lists of email addresses here.

(All of the email that we send to people has real sender and reply addresses that are read by us, even if the mail is sent by automated systems.)


Comments on this page:

When I was being a postmaster, one of the things I remember doing was pruning out pretty much all the system addresses that were aliased to postmaster@. Our system was pretty keen to ensure that email addresses were valid, so after the addresses were pruned, spammers could no longer forge mail “from” them. We didn’t have self-service addresses in the way you do (apart from +suffixes). If that had been an issue I probably would have ensured the system aliases were reserved but invalid.

We avoid a lot of this sort of thing with DMARC. We check all incoming mail for DMARC compliance and follow the published DMARC policies. And then we have a published DMARC policy that says to reject noncompliant mail.

This really feels more roundabout than necessary. We have rules that restrict who can send mail through our mail servers, which is necessary for DMARC to be at all useful. So it seems like we ought to just be able to apply similar rules for rejecting forged email with our own domain. It turned out, though, that DMARC checking was the simplest way—in terms of least configuration and maintenance on our part—to keep people from forging our domain in From: headers.

Written on 31 May 2024.
« Phish tests aren't like fire drills
Phish tests and (not) getting people to report successful phish attacks »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Fri May 31 22:47:50 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.