Question regarding greylisting

I have a question regarding greylisting... WHY IS IT CONSIDERED GOOD? I suppose it's fine for those that have dial-up connections and don't want to download the junk and let their client-side junk filtering do the job. But, for those of us that havea decent connection and know how to use a client-side filter, it kind of sucks. And I can't really see how to helps you guys on the server end much either.

Consider the scenario with no greylisting... You get 5000 (number out of my a$$) e-mails come in, 4000 of which are junk. So, you're storing those until people grab them via POP3 and their client-side junk filters go to town.

Now the scenario WITH greylisting. You get those same 5000 e-mails, but now 4000 "retransmit requests" go back to the originator. So now you're storing these still for awhile until you determine if the retransmit happens. Only now you get another 1000 e-mails from the legitimate senders as well as maybe 1000 more from greylisting-savvy spammers.

Seems like you've just increased your traffic, so why is it good for "system stability" to increase traffic and delay all of the legit e-mails? The only people this could possibly be helping are dial-up users and people who have really crappy e-mail programs with no filtering. Is that really alot of people?

It's easy enough to turn on per account or domain, but it seems like it would be better to let that be default and let people turn it on if they want it - especially when there are some relatively large legit e-mail hosters out there (Yahoo comes to mind) who seem to have trouble with handling greylisting in a timely fashion. I had e-mail from there delayed by more than 24 hours before I turned greylisting off! That's a little much...

 

A couple things; greylisting does not accept the first message, so it is not stored on the target server. The "try later" dialog is sent to the sending server during the initial transaction, so an additional message is not being sent. It's all part of the same connection. Once the sending server retries, if the message is coming from the same IP address (which it will, for the vast majority of mail sent from legitimate servers), the message is accepted.

The reason you would see delays from big mail providers is because that re-sent message may not come from the same server, so the IP doesn't match and the target server tells the sender, "nope, try later." Until the IPs match, the message is deferred. But as Bruce pointed out, we bypass greylisting for all the big email providers, so it is a moot point.

That's a somewhat simplified version of what's going on behind greylisting, but it gives you the gist of the process.

As for "greylisting savvy spammers," I am sure that most spammers are painfully aware of greylisting, but there are very, very few who can work around it.

Most spam these days is sent from botnets. A botnet, simply put, is a group of compromised home and business computers. The largest botnets are made up of millions of these "zombie" computers. And these botnets send almost all the spam that is bouncing around out there today.

The program on the compromised computer does not resend messages that receive a "try later" response. It opens itself, quickly sends out a small batch of a few hundred messages, then closes. It operates that way in an attempt to avoid detection. If it stayed open on your computer like a real mail server, it could be easily detected and terminated.

So -- botnets send most of the spam, and greylisting is effective against mail from botnets. That's why greylisting is considered a valuable anti-spam tool.


mjp
---
DiscountASP.NET