All I can say is, if you can crack jokes about this guy killing himself and/or others, then you've never had to deal with the aftermath of a suicide. It's horrible, it's gross, it hurts you, it chews you up, and you never forget it. It's not something I would ever wish on anyone, worst enemy or not.
Matt kindly decides against outing the waste of space responsible. Which is a shame, as they deserve to be outed.
Oddly enough, this reminds me of my days back at the Artists' Quarter in St. Paul, MN. Occasionally we'd have a patron who would go off the rails. Decide they don't like the music, or the guy next to them, or the phase of the moon. They'd start inappropriately shouting, yelling, poking at people around them, the bartnder, waitresses, door man. On the few occasions that I observed this, my solution was to physically eject that patron from the club, at whatever level of effort it took. In my estimation, this was the right solution. If you're an idiot, you forfeit your right to hang with us, and it's not inappropriate for me to push you out of the circle.
Sadly, it's probably not possible for ReturnPath to force this guy off of the internet. But if I were Matt, I'd probably be sure this guy never received a piece of ReturnPath-related email ever again, no matter how he signs up or verifies consent.
Here's a great example of that. Terry Zink of Microsoft's Exchange Hosted Services has done a very detailed write up on backscatter. What it is, why it happens, what you can do to prevent it, and more.
Let's start at the end. Terry writes:
- Don't make the problem worse by contributing to it:
- Don't accept mail, and then bounce.
- Don't use Challenge/Response, and don't allow your users to, either.
- Configure your virus scanner to silently strip or discard viruses/worms instead of sending a notification back to the sender.
- Don't run autoresponders, out-of-office notifications, etc. (Or maybe you only send auto-responses to senders who pass a DKIM or SPF check.)
After you've read and digested that, I recommend reading the rest of the series:
- The Problem of Backscatter, Part 1
- Part 2: The Legitimate Case
- Part 3: Legitimate Bounces
- Part 4: What the RFC Says
- Part 5: A Bit More on RFC 3464
- Part 6: Who sends the NDRs
- Part 7: Backscatter: What is it?
- Part 8: Why is it So Hard to Stop?
- Part 9: Block it With Content Analysis
- Part 10: Using SPF to Stop Backscatter
- Part 11: Check to See if You Sent it in the First Place
- Part 12: Don't Contribute to the Problem
Terry's my hero for taking the time and spending the effort to document the backscatter problem in this much detail. Thanks, Terry!
Was it really necessary to send me, "Oh noes! Your subscription expires today!!" four times, today?
Come to think of it -- was it really necessary to send it at all? Since it's a fake construct, attempting to push people to click through and provide profile information, and it actually has nothing to do with the ability to send me email messages?
I trust that since my subscription is "expiring," this'll be the last message I receive? Please?