Why not 'bounce' spam instead of 'eating' it?

[nicknick]

As I understand the design of SpamGourmet, it 'eats' unwanted emails. ie they are simply deleted without being forwarded to me. This means the spam disappears into a black hole. But from the viewpoint of the spammer, doesn't the spam appear to have been delivered successfully? So the SpamGourmat address appears to still be valid & they will keep it on their mailing lists.

Would it not be better to send a rejection email back to the spammer? That way they would experience similar 'pain' as their victims? (I assume that a human at their end has to read the replies - but I admit I am no expert in email or spam)

[jbs]

AFAIK there are a few reasons for this.

1. No one on the spammers end (certainly no human) is likely to read the bounces, they just create additional bandwidth needs for Spamgourmet, and clog up the internet with additional unwanted traffic.

2. Spam usually does not come from a "legitimate" address. It's either a fake, or even worse a spoofed address from a legit user (i.e. you get a worm on your computer which starts pumping out spam that appears to be FROM you. In this latter case, you as the already screwed infected user would not be getting tens of thousands of bounced messages bombrading your computer.

3. And this one is just my guess . . . spam works because the costs of sending it are so small than even the one-in-a-million colossal bonehead who responds covers the cost of sending to him and 999,999 others. The only way spam will stop is to flip this economic argument and make it more expensive to send. To the extent that you help remove ineffective addresses from spammers lists (i.e. bouncing messages back instead of eating them) you reduce their costs of sending. Just eating the messages actually makes their costs go up, and the effectiveness of their campaigns goes down. If half of those million emails referenced above were bad, and the spammer took them off his list, his response rate would effectively double (one in 500,000 instead of one in a million). Eating the messages costs Spamgourmet less bandwidth than bouncing them and costs spammers more bandwidth cause they keep pumping spam into a black hole.


Anyhow, those would be my thoughts on the bounce/eat issue. Besides all that, you eat spam cause it's SOOOOO tasty

--Jason

[Guest]

Points 1 & 2 seem to refer to email-based viruses.

Point 3 refers to spam as cheap mass marketing. In this case there is no point in faking the sender address - they WANT a response. And presumably have a person read them?

[Frac]

In this case there is no point in faking the sender address - they WANT a response. And presumably have a person read them?

Actually spam rarely works on replies to the email anymore. It almost always has a web site you are supposed to visit (or just installs malicious code). The email address is, in fact, almost always faked as suggested above.

[Guest]

But the point is bandwidth. Bouncing email means rejecting it with a simple SMTP line.

[SysKoll]

Today, 60% of spam at least is sent by Trojan-infected Windows machines sitting on high-speed connections. It *IS* a senseless waste of bandwidth and "bouncing" the spam is pointless: the PC owners don't even know that they are infected and think that a healthy cable modem should has a permanently lit "transmit" LED.

[Guest]

I agree with you. Although it would save spamgourmet's bandwidth, it would put a higher chaotical traffic on the internet as a whole.

[spampuke]

Yes spammers want a reply, but generally they don't want an email response, they want you to click on a link to a website and go from there. I used to bounce spam in the past but I found it to be a waste of time. Black holing it is the best way to go.

[Paul]

Another reason to not bounce failures (including consumption) is that it can result in DoS attacks while attempting to deliver the bounce.

That is, (forward direction) SG client email is forwarded to a known-working eaddr. (Well, it was working when the client registered ...) Bounces are not, and could potentially sit on the outgoing mail queue for an extended interval with several delivery (re)attempts, probably over several days (depending on how the SG server is configured). If the queue becomes sufficiently clogged, performance would suffer.

Add to that the significant possiblity that the sender address is itself valid but forged, and now the bounce becomes spam directed at some innocent third-party. Experience of experts shows that innocent users tend to reply to bounces (odd and useless, but true), compounding the problem.

Finally, sites which originate bounces are often targeted for "negative harvesting" by dictionary attacks: that is, if a site is kind enough to tell you that an address is invalid, spammers assume that the few email addresses which are not bounced are valid and working addresses. They'll send emails to [dictionary]@site, and sell the harvested email addresses to their contacts. Such an attack could be terrible for services such as SG.

Bounces would give pleasure, not pain, to the evildoers.

[jgombos]

Sometimes it's not spam. Example-

I post a message to usenet under "usenet.me@spamgourmet.com". This address is quickly exhausted due to harvesting. Then someone reads my post a couple weeks later and puts considerable effort into a reply - which is blackholed. The email evaporates, and the author thinks I ignored them. If they get a bounce, they will at least know the message didn't reach me - which is important if they are willing to try other means to get in touch.

I prefer bouncing because there could be a legitimate human at the other end, and the EFF philosophy of not canning spam at the cost of legit mail is a good one.

Another approach would be to graylist mail destined for exhausted addresses - and if it gets resent, flag it as gray listed and deliver it so the end user can assess legitimacy.

[josh]

from the FAQ:

We vaporize the mail because a) it keeps our cost down and your service free, and, more importantly, b) if we saved it for you, you'd probably come look at it every once in awhile, and then you'd see spam, which is exactly what we're trying to avoid. If this still bugs you, try to think of spamgourmet as not really email, but something like email that is appropriate to use when dealing with entities who refuse to use real email appropriately.

Anticipating the sensible arguments about sound engineering principles (from the EFF or otherwise), we encouraged you to not think of spamgourmet as email. The truth is that, while the eating has some benefits (the majority of senders *are* hostile), reason a) above is both necessary and sufficient for the position we're taking. We simply couldn't afford to bounce -- not without charging some money for the service or finding some "business model" that would probably suck.

[jgombos]

Anticipating the sensible arguments about sound engineering principles (from the EFF or otherwise), we encouraged you to not think of spamgourmet as email.

Whether we call it email is just a matter of semantics. Regardless, it's a useful tool, and I applaud the SG staff for their efforts. Offering SG services at no cost, as useful as they are, means SG has gone above and beyond what's expected. It has certainly eased my email management.

My comment was focused purely on end user needs, without regard to business models. Sometimes I want disposable email to vaporize, and other times I don't. Vaporizing is best when the address was created for a known entity with minimal exposure. However, public forums are different.

The best possible mechanism for posting public messages is to have disposable email addresses that are graylisted. And if such email addresses would expire, time might be used rather than reply counters. When considering the business model, it probably makes little sense for SG to offer this, now that I've given it more thought, but it would be a useful service to have.