3

We run a small email (receiving not bulk sending) service (~ 300 domains or so) for our customers and are just starting to introduce DMARC. One of the reasons for doing so is to help stop backscatter (NDRs for emails that weren't sent) by helping us to identify when NDRs are for backscatter.

We can't stop people from spoofing email addresses we host, and we can't force other systems to properly implement SPF, DKIM and DMARC, but we want to be able to identify a backscatter reply.

The theory is that if we receive NDRs then the NDR should attach the original message headers, so we can check those to see if was spoof sent. So the idea is to requalify the original message headers, honouring SPF, DKIM and DMARC and if the NDR originating system should have binned the message then we can bin it.

I have been looking at one such message that has been received on a domain we're testing which suffers a lot of spoofing. The DMARC policy for the domain in question is:

"v=DMARC1; p=reject; aspf=s; adkim=s"

The relevant email headers (anonymised) on the NDR are:

Received: from h2773125.stratoserver.net (h2773125.stratoserver.net [81.169.157.174])
    by mailboundary.domainundertest.tld (8.14.7/8.14.7) with ESMTP id x65BOdv8028405
    for <user@domainundertest.tld>; Fri, 5 Jul 2019 11:24:44 GMT
DMARC-Filter: OpenDMARC Filter v1.3.2 mailboundary.domainundertest.tld x65BOdv8028405
Authentication-Results: mailboundary.domainundertest.tld; dmarc=none (p=none dis=none) header.from=h2773125.stratoserver.net

Which is correct so far - the NDR is from a target system that has received a spoof message so the NDR (this message) passes.

In the NDR message there are a number of email accounts in different domains that are being rejected. This may indicate that the system generating the NDR is an open relay and, if it is, probably not thoughtfully setup or possibly specifically setup by spammers. Of course if it was setup specifically by spammers then they won't care about not generating back-scatter!

In the original message headers it lists only the following:

Return-Path: <user@domainundertest.tld>
Received: from 92.119.160.85 (unknown [113.163.187.18])
    by h2773125.stratoserver.net (Postfix) with ESMTPSA id DEC718656E;
    Sat, 29 Jun 2019 22:54:56 +0000 (UTC)
Message-ID: <a77f25767d56838fa91caaf90dc8323e07995fd8@domainundertest.tld>
Reply-To: "CestusKaput96368" <some_apparently_throwaway_address@yahoo.com>
From: "CestusKaput96368" <user@domainundertest.tld>
Subject: Ich bin ein boses Madchen und muss bestraft werden.
Date: Sun, 30 Jun 2019 01:54:59 +0300
MIME-Version: 1.0
Content-Type: text/plain

That's all the headers ... but enough to have this blocked.

We can see that the envelope-from (Return-Path) is from the domain we're trying to protect and we have the IP Address it was sent from (113.163.187.18) so we can check the SPF - it would fail. As we have a policy of aspf=s the server originating the NDR should have binned the message so we can bin the NDR.

So what we want to do is implement our own DMARC checks for the NDR messages based on the original headers.

Does anyone know of an open source tool to do this? We could write our own milter in either C or Perl if needed but I thought that there may be something already existing out there.

Any thoughts and opinions are welcome!

Rob Lambden
  • 260
  • 2
  • 6
  • For sure this is an interesting approach to reducing backscatter and please do report success rates when you put this in production! A few things to consider: 1. Some MTAs strip `received` headers. 2. The Header.From domain might be entirely different from the bounce address, which may not spoof your domain, but would cause backscatter. 3. You could bin the message based on SPF failure, assuming the message was not DKIM signed. aspf=s is not directly related as it disallows return-path domains that only share the same organizational domain instead of exactly match the header.from domain. – Reinto Jul 05 '19 at 20:21

0 Answers0