Can a DMARC "reject" policy prevent NDR backscatter?

DMARC is not a solution against backscatter, and p=reject can actually cause more backscatter as a side effect on the servers sending Non-Delivery Receipts (NDR) instead of using connection-stage rejection during the SMTP connection. The whole backscatter problem is caused by a poor configuration on the receiving MTA, or on an intermediate MTA. Even if DMARC had a solution for this, that kind of administrators wouldn't be the first ones to adopt it.

On the other hand, DMARC offers a possibility to receive Failure Reports (ruf=), possibly causing massive amounts of forensics data. It's recommended to have a fully separated address for this, and the data is best to be forwarded somewhere where the analyzing can be automated.

Possible ways to fight backscatter include:

• Using DNS-based block list for known servers sending backscatter (backscatterer.org).
• Checking that the Message-Id of a bounced message matches your message ID pattern.
• Bounce Address Tag Validation (BATV) (Internet-Draft from 2008, explanation).

And first of all: configure your own SMTP servers in a way that they won't send NDRs to possibly forged return addresses: Use connection-stage rejection right after failed recipient validation or anti-forgery checks etc. The NDR will be generated for a local user on the sending MTA.

I appreciate that this is a late answer.

DMARC as specified cannot prevent backscatter ... but that's not the end of the story.

SPF, DKIM and DMARC have all reduced back-scatter where they are implemented on receiving servers so the problem is less than it was. However we can't assume people will implementing any of these techniques.

@Esa - your comment about not generating NDR to non-local users would mean that if anybody setup a relay that's not responsible for final delivery then no senders would ever get an NDR. This happens a lot for good reasons - separating the mail boundary (or spamwall) from the mailbox store is generally a good thing (IMHO) and also allows much more flexible processing. I don't think this is a viable solution to back-scatter.

Of course you are right that DMARC doesn't stop back scatter, as the NDR is a separate message to the original spoofed message then the NDR message may well comply with any DMARC policy for the domain originating the NDR. However as an NDR contains the original message headers then the information in those headers about the original email can be used to identify back-scatter.

There used to be a milter available called milter-null which inserted a computed header to outgoing messages and checked for the same header in the message headers on an NDR. If it wasn't there then it blocked the NDR message. This technique is only useful when the receiving mail server knows about the headers insserted by all of the outgoing servers and I think miilter-null only worked when the same server processed all outoging and incoming mail. It's no longer available (I think it was from snertsoft) although you might find the source somewhere with some persistent searching.

We are considering implementing a solution that uses the original message headers in the NDR to implement DMARC as it should have been implemented at the receiving server. Of course this isn't part of the DMARC scope and although we can see some weaknesses to this approach*, it's the best plan we've found to block back-scatter. We haven't done it yet but somebody else may have already implemented a solution.

• The key weakness is that as a message can be queued for days there's no guarantee that the records we will be assessing the message against are the same ones that existed at the time the message was sent. We can get around that if we host the DNS but it's not standards compliant. (We have a log of record changes so we can determine what the record was at a given point in time).