Backscatter spam is annoying. It's tough to filter because the contents of it can fool content filters and can also fool end users.
Indeed, if your content filter could recognize an NDR and ignore the parts that typically occur in NDRs, you could then filter the rest of the message normally and make the spam/not-spam classification that way.
When it comes to NDRs and Delivery Status Notifications, probably the key thing to remember is to treat them as a subclass of actual email. It's not marketing, it's not business mail, it's not a personal communication, it's simply a notification that mail that you sent did not get delivered the way you expected.
We've seen a number of ways to filter the mail, some better than others. Ultimately, what it comes down to is treating bounce messages differently than regular inbound mail and making decisions based upon that special categorization of email. The rules of normal inbound filtering are modified because it's simply a better way to evaluate it.
Question: I just registered a set of new domain names for a client, but they will not be used for email at all, just as aliases for the web site's "real" domain name. Should I set up a Mail Exchange (MX record) in the DNS for those domains? Should I also set up SPF that says those domains are *never* used for sending email? Or just the SPF records only? Thanks, this has been an interesting series.
1. If you will never use these domains to receive email, then you don't need to set up an mx record. Any attempt to deliver mail to that domain should fail and you will receive an NDR (but not an accept... then bounce).
2. If these domains never send email, then you should create an SPF record that says "v=spf1 -all".
Great Series Terry! It'd be nice to see all of them combined together and published as a whitepaper someday.
@Michael Clark, tzink; #1: A domain that lacks a MX record in DNS can still receive mail; mail servers in that case will go to the A record (or, presumably, in the case of IPv6-connected sites, AAAA) instead. See RFC 2821 section 5 for details. ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt
Is BATV key has expiry time? BATV generate same key for specific sender for more than one message in short duration. I was thinking that BATV generate different Key for each email sent out.