Dear lazyweb, this morning I got bitten by fake Delivery Status Notifications. You’ve probably seen this a thousand times:
- Spammer sends mail to non-existant user in existant domain.
- Idiotic mail service accepts mail, even though:
- My domain’s SPF record is telling them not to.
- Destination address doesn’t even exist.
- Another component of idiotic mail service (hurray for qmail modularity!) realizes this address is invalid, and generates a DSN for the mail sender, even though they don’t really know who that is.
- I receive a gazillon of bounces informing me that some mail I didn’t send couldn’t be delivered.
Do you know of any blacklist containing all hosts and/or domains that do this?
Alternatively, I think a blacklist containing all qmail domains would probably cover most of it.
October 26, 2009 at 13:37 |
Why not write a script which will recognise DSN and reject it unless it finds corresponding outgoing mail?
October 26, 2009 at 13:56 |
I wouldn’t trust it. I can’t afford to miss legitimate DSNs :-(
October 26, 2009 at 14:35 |
I configured my mail server to reject mail if the source address would not accept a DSN (by the sender verify feature of exim). But if you do that, you’ll end up in yet other blacklists… (sorry, lost the reference to the black list provider)
October 26, 2009 at 14:52 |
Using the »zen.spamhaus.org« (http://www.spamhaus.org/zen/index.lasso) keeps most (like 90% for my MTAs) spam, including DSNs, out of my mailbox.
October 26, 2009 at 15:08 |
Spamassassin has an option (whitelist_bounce_relays option) that tries to detect bounces. If you alreay use spamassassin for mail filtering you could use that. I use it to filter DSNs to a separate folder.
October 26, 2009 at 15:11 |
See here:
http://lwn.net/Articles/277399/
referencing here:
http://www.infradead.org/rpr.html
and here:
http://david.woodhou.se/eximconf/include/routers-ses
Where a scheme for rewriting MAIL FROM such that your mailserver can authenticate real bounces is described, including exim configuration fragments.
Don’t be too confused by its mentions of SRS and SPF — that was just the inspiration and original impetus for building the system. The configuration is actually a stand-alone bounce-authentication system.
October 26, 2009 at 15:18 |
http://en.wikipedia.org/wiki/Bounce_Address_Tag_Validation
October 26, 2009 at 21:02 |
Awesome. I need to look into this when I have time…
October 26, 2009 at 16:36 |
You might be looking for http://www.backscatterer.org/ .
October 26, 2009 at 21:00 |
Very nice, even with Exim recipe! I just enabled it, let’s see how it performs…
Thank you!
October 26, 2009 at 21:54 |
Please don’t use this blacklist; it blacklists backscatterers (good) but also blacklists servers that use sender callouts (not good). I know several legitimate mail servers that use sender callouts.
October 26, 2009 at 21:58 |
Sure enough, I just checked, and one of the mail servers I deal with regularly has a listing there, presumably for using sender callouts (since I know it doesn’t do backscatter).
October 26, 2009 at 22:01 |
Oh, and for a more specific higher-profile example, Sourceforge does sender callouts.
October 26, 2009 at 22:14 |
Sender callouts are most emphatically *NOT* good, though. Consider the effect on my mailserver when all 100000 sites on the internet that someone has sent spam to (with my server faked as the sender) attempt to connect to me to verify the account exists. It’s just about as bad as if they were sending DSNs!
And sometimes it’s worse, because some mailservers seem to keep the connection open for a while…I guess just in case they need to send more callouts or something.
This isn’t a theoretical concern: Just last week I had this happen and had to reconfigure my server to allow 500 (vs 20) exim processes, and decrease the idle disconnect delay to 30s.
And, sorry to say, before last week I also though sender callouts were a good idea. (sorry to everyone’s mailservers I unthinkingly helped DOS) :(
October 27, 2009 at 03:57 |
The sites I know of that use sender callouts do so very carefully. For instance, they do greylisting *first*, and only do the sender callout later after the greylist passes; thus, illegitimate mail servers won’t trigger the callout in the first place. They also only do a callout *once* for a given address (much like greylisting, pass or fail gets remembered), and they delay a random amount for callouts. IIRC they take a few other measures I’ve forgotten about as well.
I can certainly understand that badly done server callouts can cause problems. That doesn’t make the technique inherently bad.
October 29, 2009 at 21:33 |
Too late, I already found that out on my own. Needless to say, I stopped using it as it was making me reject mail from mx10.gnu.org!!
But thanks for the warning.
October 28, 2009 at 02:44 |
Read this, even if you don’t use Postfix:
http://www.postfix.org/BACKSCATTER_README.html
In particular:
Blocking backscatter mail with forged mail server information