I'm going to try to say this as nicely as possible and without trolling: You have just rendered Greylisting pretty useless by making it open source. Spammers are much smarter than you think and what you have basically done is shown them what they need to do in order to get around Greylisting. That's just my take on the issue, maybe I'm wrong but I doubt it.
The thing that is wrong is the SMTP protocol, and most people's conception of a spammer. Once you see a few "confessions of ex-spammers", everything changes.
There are people out there who pay $10000 in startup costs, and then make $2000/week for spamming. The $10000 gets them software written by knowledgable internet security experts. This software finds any and every way to anonymify the email spam, and finds lists of people to spam.
As long as knowledgable internet security experts are getting paid good
The way to get around this, of course, being that you send each email twice. In other words, run through your database, then run through your database. Same IP addy, same sender, same recipient. As far as the MTA's concerned, it's retrying. Boom.
From the article: If we have never seen this triplet before, then refuse this delivery and any others that may come within a certain period of time with a temporary failure. (emphasis addded)
Later in the article it goes into much more detail about the delay, how long to delay if the triplet has not been seen before, life time of the whitelist, etc.
It also talks about configuring the times - they mention the default delay is 1 hour, but that their recor
I did. Big freakin whoop. It pays attention to multiple incomings? Randomize your list so you're breaking them up. It wants you to wait an hour? Then WAIT AN HOUR.
What he wants to do, instead of rejecting the mail immediately, is reject the mails on the greylist after holding the connection for, say, 10 minutes. That will help deter spamming software, since it will slow down the rate at which mail goes out.
is reject the mails on the greylist after holding the connection for, say, 10 minutes. That will help deter spamming software,
I doubt it. I would assume the spam software would have a timeout, and I doubt it's ten minutes. If they want to hit-and-run and aren't even willing to make a second delivery attempt when an error code is returned, I doubt they're going to wait 10 minutes. I'm sure that within 30 seconds or less they'll consider it a dead connection and hang up.
Problem is, I used to have my sendmail HANG UP in real-time on an incoming connection as soon as it realized a message was spam. I.e., the incoming message was filtered in the DATA phase and if it was spam I hung up immediately. It worked great and it felt good, but there were many spam programs that took the disconnection as some kind of TCP/IP failure and immediatelty tried again. So I had one day where a single message was attempted to be delivered about 30,000 times as the spammer connected, I hung up, spammer software said "Oops, let me try again!" About one delivery attempt every second or so.
I'd be willing to bet if you put a 10 minute timeout in sendmail you'll see lots of spammer software disconnecting sooner and just trying again. It takes more of their resources, but takes more of yours, too.
Let us assume that the timeout is 't'. The spammer can send 'x' emails in time 't'. With greylisting a spammer can now only send 'x' emails in time '2t'. It's that fucking simple.
I'd be willing to bet if you put a 10 minute timeout in sendmail you'll see lots of spammer software disconnecting sooner and just trying again. It takes more of their resources, but takes more of yours, too.
Yeah, but think of it like distributed.net... but for pissing off spammers. That's DEFINATELY worth it:-)
I can live with a few sockets open, but can they live with a few sockets * 1,000,000 open?:-)
It takes more of their resources, but takes more of yours, too.
Well, if each email took (say) one extra second to send and one extra second to recieve, we'll see how many spammers are still sending out 10,000,000 emails per day.
"Well hello there Charlie Brown, you blockhead."
-- Lucy Van Pelt
your first mistake (Score:4, Insightful)
You have just rendered Greylisting pretty useless by making it open source. Spammers are much smarter than you think and what you have basically done is shown them what they need to do in order to get around Greylisting. That's just my take on the issue, maybe I'm wrong but I doubt it.
security through obscurity, again? (Score:5, Insightful)
Re:security through obscurity, again? (Score:5, Interesting)
There are people out there who pay $10000 in startup costs, and then make $2000/week for spamming. The $10000 gets them software written by knowledgable internet security experts. This software finds any and every way to anonymify the email spam, and finds lists of people to spam.
As long as knowledgable internet security experts are getting paid good
Re:security through obscurity, again? (Score:4, Insightful)
The way to get around this, of course, being that you send each email twice. In other words, run through your database, then run through your database. Same IP addy, same sender, same recipient. As far as the MTA's concerned, it's retrying. Boom.
Re:security through obscurity, again? (Score:4, Insightful)
From the article: If we have never seen this triplet before, then refuse this delivery and any others that may come within a certain period of time with a temporary failure. (emphasis addded)
Later in the article it goes into much more detail about the delay, how long to delay if the triplet has not been seen before, life time of the whitelist, etc.
It also talks about configuring the times - they mention the default delay is 1 hour, but that their recor
Re:security through obscurity, again? (Score:2)
I did. Big freakin whoop. It pays attention to multiple incomings? Randomize your list so you're breaking them up. It wants you to wait an hour? Then WAIT AN HOUR.
Re:security through obscurity, again? (Score:2, Informative)
Re:security through obscurity, again? (Score:5, Interesting)
I doubt it. I would assume the spam software would have a timeout, and I doubt it's ten minutes. If they want to hit-and-run and aren't even willing to make a second delivery attempt when an error code is returned, I doubt they're going to wait 10 minutes. I'm sure that within 30 seconds or less they'll consider it a dead connection and hang up.
Problem is, I used to have my sendmail HANG UP in real-time on an incoming connection as soon as it realized a message was spam. I.e., the incoming message was filtered in the DATA phase and if it was spam I hung up immediately. It worked great and it felt good, but there were many spam programs that took the disconnection as some kind of TCP/IP failure and immediatelty tried again. So I had one day where a single message was attempted to be delivered about 30,000 times as the spammer connected, I hung up, spammer software said "Oops, let me try again!" About one delivery attempt every second or so.
I'd be willing to bet if you put a 10 minute timeout in sendmail you'll see lots of spammer software disconnecting sooner and just trying again. It takes more of their resources, but takes more of yours, too.
THIS IS WHY IT WORKS (Score:1)
Re:security through obscurity, again? (Score:1)
Yeah, but think of it like distributed.net... but for pissing off spammers. That's DEFINATELY worth it :-)
I can live with a few sockets open, but can they live with a few sockets * 1,000,000 open? :-)
Re:security through obscurity, again? (Score:1)
Well, if each email took (say) one extra second to send and one extra second to recieve, we'll see how many spammers are still sending out 10,000,000 emails per day.