Score:0

How to prevent 3rd party domains using our server/domains for email envelopes

cn flag

We recently received a whole bunch of notification emails stating an email that apparently originated from our servers was blocked for being spam, but we can't find the source emails on our server, so wanted to ask if we're missing anything obvious.

Below is the notification email. [email protected] is our domain email address:

Notification email:

A message that you sent was rejected by the local scanning code that checks incoming messages on this system. The following error was given:

This message was classified as SPAM and may not be delivered

------ This is a copy of your message, including all the headers. ------

Received: from amcham by vps62989.inmotionhosting.com with local (Exim
4.95) (envelope-from [email protected]) id 1nrvvQ-0002CA-NB for
[email protected]; Thu, 19 May 2022 23:15:48 -0700
To: [email protected] Subject: Contact
X-PHP-Script: amchamec.com/index.php/contactanos for 104.149.136.246
X-PHP-Originating-Script: 1003:class.phpmailer.php
Date: Fri, 20 May 2022 06:15:48 +0000
From: "? Donna just viewed your profile! Click here: https://spamPornURLRemoved.com ?"
[email protected] Message-ID:
[email protected] MIME-Version: 1.0
Content-Type: text/html; charset=utf-8

Customize this e-mail also. You will receive it as administrator.

Nombre y Apellido:? Donna just viewed your profile! Click here: https://wondergirl22.page.link/29hQ?bvh9r ?
E-mail:[email protected]
{CompanySize:caption}:{CompanySize:value}
{Position:caption}:{Position:value}
{ContactBy:caption}:{ContactBy:value}
{ContactWhen:caption}:{ContactWhen:value}

Some bullet points:

  • The envelope was from [email protected] This is a genuine email address on our servers. This is NOT a mailbox but a forwarder that comes to my business email mailbox.
  • Checking Exim there is no record of the 1nrvvQ-0002CA-NB mail ID or [email protected] mail id except the above message.
  • class.phpmailer.php does not exist on this server, but we do use PHP and clients do send mailings using PHPMailer (but not from this domain).
  • Our servers always use PTR, DKIM, SPF, DMARC , etc.

Our problem

So, there have been enough of these notification emails I'm not sure they're fake, but checking Exim Logs can't find these id's or email addresses in the logs so am not sure what's going on. I can only conclude that the email is entirely 3rd party but somehow they're "piggybacking" on our domain as the "envelope".

Question

What can we do to prevent 3rd party domains using our domains as "envelopes" for emails they send?

If the illustarted email above is a spam or fake, a) Is this likely and b) Why?

Nikita Kipriyanov avatar
za flag
I don't understand. Are they sent using your IP address, or some completely unrelated addresses and only your domain names appear there?
Martin avatar
cn flag
@NikitaKipriyanov as I say, I can't find any Exim records for the referenced mail, the exim logs for the above email show where it's from but that's inmotionhosting.com (I'd imagine, I've not confirmed).
Score:7
bd flag

You can do nothing to prevent others from using your domain name in mails they send, including the envelope address. This is called sender address forgery and is generally considered abusive, but you as the legitimate owner of the domain have no direct means to prevent it.

You can also do nothing to prevent others receiving such mail from blindly believing that envelope address and sending non-delivery messages to it. This is called backscatter and is generally considered bad practice, but again, you as the recipient have no direct means to prevent it.

What you can do is set an SPF record in your domain to signal which servers are legitimated to send mails with envelope sender addresses from that domain. Well-configured mail servers will then reject mails falsely claiming to be from your domain during delivery instead of emitting notifications after the fact, thereby avoiding backscatter.

What you can also do is complain to the owners of the mail server producing the backscatter (ie. the sender of the notification mails) for running a misconfigured server.

As a last resort, you can use the ips.backscatterer.org RBL to block mailservers producing backscatter from delivering mail to your server.

Nikita Kipriyanov avatar
za flag
Also it is worth setting up DKIM records and configuring DMARC policy. But all those measures are *recommendations to receivers* that mail with your domain name in "mail from" should be rejected or quarantied if it doesn't adhere to certain rules.
cn flag
Setting SPF records would help as major mail service providers will respect it and bounce off the emails from not allowed sources. You would need to read up a little more on how to configure SPF records properly.
Martin avatar
cn flag
Thanks for this answer. We have DKIM, DMARC and SPF all set up and working on the domains across our servers.
Martin avatar
cn flag
Currently our SPF records are set on SoftFail `~all` would it help combat this situation if they're changed to HardFail `-all` ?
Tilman Schmidt avatar
bd flag
It may mitigate it but will not entirely stop it. Misconfigured mailservers that produce backscatter tend to ignore SPF, too. At the end of the day, you can only complain and, if that is fruitless, block them.
djdomi avatar
za flag
you can consider a hard fail if the business owners accepting that a false positive will be rejected also.
Tilman Schmidt avatar
bd flag
SPF false positives are rare and easily handled, compared to other false positives which are part of the daily business of running an internet mailserver. I'd argue that such a decision falls within the general competence of an IT operations manager and needn't be escalated to the business owners (except if the two coincide).
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.