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 cash to enable spammers, and SMTP doesn't change, spam will only continue to get worse. There needs to be a fundamental change in SMTP protocols. It oughta take the spammers about 2 days to fix their MTA bug to get around greylisting.
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 records suggest that 1 minute would have caught 99% of the same spam messages - "The data collected during testing showed that more than 99% of the mail that was blocked with the tested setting of 1 hour would still have been blocked with a delay setting of only 1 minute. At that point, having a larger initial delay will definitely help, as it gives time for other blocking methods to act. For this reason, it is suggested that at least a one hour delay value be kept as a default, since spammers will start adapting as soon as this method becomes known and starts being used. (again, emphasis added)
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.
There is no magical waiting period or re-try period that cannot be trivially coded around. And, with good money on the line, will be trivially coded around.
You don't get it. Really smart people are getting paid a whole lot of money to make programs to exploit every possible crack in the way we send email. There is no general rule to spammers, except that it is a lot of money and they are very clever. Little bandaids are not going to stop this one - there needs to be a much more fundamental change. And I am not talking about laws against spam - I am talking about changes in the protocols we use to send email.
It seems to me that we should start suing the people that pay the spammers. They should be relatively easy to find, since they are apparently making money off of the advertising that they purchased, after all. If you stop the flow of money to spammers and make the cost / risk of funding spam great, then you would inevitably reduce the spam that gets put out.
I agree that there is no "magical waiting period or re-try time period". However, by forcing the spammer to re-run through their spam list, their life has been made a little harder, they have been forced to be a little more visible, we have pushed them to use more resources (hopefully hitting them in the wallet), and we have forced them to do something that, BY ITSELF, can be used as a spam indicator. As I mentioned in another post, I rarely get duplicate emails fro
There is no magical waiting period or re-try period that cannot be trivially coded around. And, with good money on the line, will be trivially coded around.
They can code around the retry-period for grey-listing mail agents. By then the honeypot mail agents will already have the email, and during the retry period the FTC can try to find the server for the contact URL or the phone number, and put a wire-tap on it.
There is no magical waiting period or re-try period that cannot be trivially coded around. And, with good money on the line, will be trivially coded around. You don't get it. Really smart people are getting paid a whole lot of money to make programs to exploit every possible crack in the way we send email.
Yeah, spammers are so clever. Well, the fact is if for every one of these "smart" (yeah, right) spammers who has the help of a network consultant that will work around greylisting there are 5 dumbasses who don't (and I think I'm being generous there), then if I greylist I'd think over 80% of my spam problem would be eliminated. What's wrong with that? What's to "get"? Looking through headers I see the same bulk mailers used over the years, probably passed around as warez in spammer circles.
Well, the fact is if for every one of these "smart" (yeah, right) spammers who has the help of a network consultant that will work around greylisting there are 5 dumbasses who don't
This does fuck all when your one spamking is responsible for 80% of the SPAM (by volume.
Don't pro spamhauses get paid based on the number of addresses they attack (or at least claim to)? Do they care at all whether there's any chance an address will increase the miniscule response rate?
But the people paying those supposedly "smart people" are pretty dumb. Lately I've been getting 12-15 spam messages every day from "Some Bozo". And with a subject line containing the literal string "random text".
Lots of the fools paying for the smart spam tools are too dumb to configure it. Eliminate those turkeys, and it will reduce the amount of spam significantly.
No, simply sending the message twice does not defeat it. Retries are rejected for 1 hour (default setting). The paper specifically talks about how 1 minute will block virtually all spam today, but such a short timeout will allow spammers to defeat greylisting exactly as you have described.
Quoting from the paper:
The initial delay of 1 hour was picked for several reasons:
An hour is short enough that in most cases, users will not notice the delay.
It is long enough to give time for administrators on a
As stated, the only reason the hour works right now is because the spammers don't see this in the wild. Re-running your database script an hour later isn't a big deal.
If you can send legitimate mail through a system from a random source on the Internet, you can run illegitimate mail through it. Period.
As stated, the only reason the hour works right now is because the spammers don't see this in the wild.
What was stated in the article was that the 1 minute time would work only because the spammers don't see this in the wild - which is the reason why 1 hour is the default and the (currently) suggested setting.
You are correct that if legitimate email can be sent, then illegitimate mail can be sent. BUT, if a spammer sends 1,000,000 emails through a hijacked source, then has to send the 1,000,000 emails ag
This relies on the fact that spam software, unlike a real MTA, doesn't do things like care about 4xx series temp fail messages. So, you recode your software so that it does, or so that it simply runs through the script again. This implements a 1 hour delay. Not a 1 hour wait between different messages, or anything. People get their spam an hour after you initiate sending. BFD.
RIGHT NOW, this will stop spam cold. In six months, it will be useless.
Except that, as I said somewhere above (this time delay is annoying:) ), if the spammer has to start acting like a legitimate emailer, then (s)he has to start taking notice of the temp fail messages or just re-run the spam list. Either way, their productivity has dropped - and their income is based on a relatively miniscule response rate to huge numbers of messages. Cut down on the number of messages sent in a time period and you have just hit them in their income.
Nah,
In six months, you start black listing the obvious patterns from spammers during that first hour.
Example: Why is random e-mail addresses at 123.234.158.42 sending 36000 e-mails to everybody from 1@mydomain.com to BBCACE@mydomain.com? I think he's trying to spam me, lets add him to my black list before he annoys the 3000 users I have in that range.
But you can already do that. And lots of people do. So spammers just hop IP addresses. So people block dynamic blocks. But that hurts legitimate users. And so on.
The only solution to the spammer problem is the granting of plenipotentary powers of execution to, well, me. I'll be like Judge Dredd, only not quite as big and menacing.
People get their spam an hour after you initiate sending. BFD..... RIGHT NOW, this will stop spam cold. In six months, it will be useless.
No. If it's widely deployed and if spammers adapt, in six months spammers will be forced to maintain the same IP number for 1 hour to get messages delivered (very difficult for the ones who compromise hosts) AND not have that IP number end up in blacklists during that 1 hour AND not have newer spam-pattern detection filters identify that IP number as spewing spam AND
Then the target(s) have one hour to recognize you tried a spam run, and just block that IP for your second run (switching to a new IP means one new hour of waiting). That was part of the benefit of an hour delay, to give IP blockers time to react.
No, the real means of bypassing this is a little trickier.
I really like the part where the record of the attempted email ages out in 4 hours so that more email from that address/sender has to restart the 1 hour temp failure wait.
Most people do not send me multiple duplicate emails, so if a spammer had to send his entire spam list twice withing 4 hours to beat the greylist, then that would be a fairly obvious spam signature in itself!
Anything that makes spammers do extra work seems to make it more likley that they will have patterns that can be observed and then blocked before mail really goes anywhere...
So you mix up your spams; rather than sending all viagra, you send a few viagra, and a few mortgage, a few horny teen sluts, and so on.
I'm not saying this is a bad idea; I'm saying that it's only going to work for a while. I'm saying that basing your defences on the fact that spam software isn't RFC compliant means your fine until the spammers get RFC compliant, and that isn't very difficult at all.
> I'm saying that basing your defences on the fact that spam software isn't RFC > compliant means your fine until the spammers get RFC compliant, and that isn't > very difficult at all.
Whats even worse is not all mail servers are RFC compliant either:/
Exactly. That, and suddenly, if this system takes off, and all mail gets delayed by an hour, well, sure, the spammers need more resources, but so do legitimate mail senders. Suddenly you need to queue up your mail for an hour; disk space, send it twice; bandwidth, and so on.
So you mix up your spams; rather than sending all viagra, you send a few viagra, and a few mortgage, a few horny teen sluts, and so on.
I'm not saying this is a bad idea; I'm saying that it's only going to work for a while. I'm saying that basing your defences on the fact that spam software isn't RFC compliant means your fine until the spammers get RFC compliant, and that isn't very difficult at all.
:-/ No. I think you aren't getting this. The whole point is that a new sender is untrusted for one hour. Y
I'm confuzzled. Oh, and I'm probably screwing up my recp to/mail from (or is it rcpt from/mail to?) but you'll get my point.
smtp service OK.
>EHLO i-am-a-spammer.com
Hello, i-am-a-spammer.com.
>MAIL FROM: somebody@yourdomain.com
250 OK
>RCPT TO: somebodywhodoesn'twantspam@yourdomain.com
451: A temporary failure cuz your triplet is untrusted.
>curses, I'll be back later.
So who's going to vet it as 'spam?' Want to do it after the DATA message is sent? Then you're doubling your bandwidth.
So who's going to vet it as 'spam?' Want to do it after the DATA message is sent? Then you're doubling your bandwidth.
Want to try to identify based on the fact that there's a ton of mails coming through in a short period of time? What if the spammer simply re-orders his spam database, so it's not sorted by domain? If he has 1,000,000 emails, with, oh, 10,000 separate domains, then only every 100th email he sends will be to your domain, if he spaces them properly.
Yes, but saying 'they're in some other spam resource already' is rather disingenious.
At that point, it becomes 'reject ALL MAIL for one hour, on the theory that if it's brand new spam, it'll be in RAZOR in an hour.'
Well, shit. Here's an idea. Have a function in mail servers so that they each have a public/private key. When you connect to a mail server, you give it your public key. It can then check that public key against a public database of 'known good' servers.
As stated, the only reason the hour works right now is because the spammers don't see this in the wild. Re-running your database script an hour later isn't a big deal.
I disagree. When you are sending 250,000,000 emails a day -- restarting that script IS a big deal. It would, in effect, make them have to do the entire thing twice. That's a pretty big hit on their resources.
Spammers rely on a tiny hit rate to a huge number of emails. If they sent more emails, they would make more money. I assumed (dangerous, I know) that they would therefore be sending the maximum number of emails they could based on their bandwidth limitations as well as their resourse limitations - or as many as they thought they could get away with without being noticed/blacklisted/shutdown. I.e., they are either running flat out, or trying to stay under somebodys' radar.
Part of the plan is to cost spammers more money, driving more of the smaller ones out of the market. Once the spammer market consolidates enough that only a few mechanisms are effective, those individuals will be easier to attack, pickaxe, and make an example of.
Having your car up on blocks when all the other neighbors are doing it is one thing. When you're tho only one, your neighbors suddenly start focusing a bit.
Most common single-server mail transports can sustain ~10k-100k deliveries per hour under ideal conditions, with this delivery rate frequently saturating available bandwidth. Issues such as MX and DNS resolution become significant at these volumes. Thus, 100m mails is 1,000 server-hours of time.
Sending more mail requires multiple servers and mulitple pipes. Both of these are resources which are only available to the spamhaus at additional cost or reduced control.
That's fine. The idea is that by the time the hour has elapsed, vipul's razor or some other such method will have been updated to catch the spam. The author states several times that this won't really work that well on its own.
So the trade off is that you're (at least) doubling your bandwidth requirements to save on bandwidth?
I still don't see the benefit; currently, somebody gets a spam, off it goes to Razor,or pyzor, or DCC, or whatever, then you still get it, but you reject it.
Now, you reject it for an hour, get it again anyway, then check it against razor or whatever, doesn't seem to be a net gain.
Still, if it catches more than about five percent of total, I guess it's worth it.
Why not go one step further and take it past the turing machine answers of, "please enter in the number/word in this image and hit reply"?
Simple set of rules for email and web forms that works like this:
Email comes in and is not from a whitelisted envelope address -- reject it (permanent failure) with a URL in the rejection notice that is returned to the sender
Sender, if they give a rip, goes to the URL and applies for access. Nothing automated, they have to post a reason for contact like: user-list, s
It's a pain in the ass for users. I wouldn't want to have to reply to some stupid question every time I sent an email to someone new, and I don't have the time to go through my address book and send an email to everyone in it (assuming they all have this challenge response system set up) and reply to the challenge. Also, the people that I communicate with aren't always the most technically able, and I don't want to loose mail because someone gets confused and thinks it's bouncing (regardless of the nicely
"As long as knowledgable internet security experts are getting paid good cash to enable spammers, and SMTP doesn't change, spam will only continue to get worse.
Oh, foo. What these experts know that's most valuable to them is that essentially nobody pays attention to the huge level of spammer abuse that the spammers commit to send their spam. Beyond the impotent "secure your open relay" campaign that they were told from the start wouldn't work 99.99% of the operators pay no attention whatsoever to the sp
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 cash to enable spammers, and SMTP doesn't change, spam will only continue to get worse. There needs to be a fundamental change in SMTP protocols. It oughta take the spammers about 2 days to fix their MTA bug to get around greylisting.
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 records suggest that 1 minute would have caught 99% of the same spam messages - "The data collected during testing showed that more than 99% of the mail that was blocked with the tested setting of 1 hour would still have been blocked with a delay setting of only 1 minute. At that point, having a larger initial delay will definitely help, as it gives time for other blocking methods to act. For this reason, it is suggested that at least a one hour delay value be kept as a default, since spammers will start adapting as soon as this method becomes known and starts being used. (again, emphasis added)
RTFA!
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:2)
No, it will not. It will simply delay it by ten minutes, or whatever the dupe window is.
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.
Re:security through obscurity, again? (Score:5, Insightful)
There is no magical waiting period or re-try period that cannot be trivially coded around. And, with good money on the line, will be trivially coded around.
You don't get it. Really smart people are getting paid a whole lot of money to make programs to exploit every possible crack in the way we send email. There is no general rule to spammers, except that it is a lot of money and they are very clever. Little bandaids are not going to stop this one - there needs to be a much more fundamental change. And I am not talking about laws against spam - I am talking about changes in the protocols we use to send email.
Re:security through obscurity, again? (Score:2)
Re:security through obscurity, again? (Score:2, Informative)
I agree that there is no "magical waiting period or re-try time period". However, by forcing the spammer to re-run through their spam list, their life has been made a little harder, they have been forced to be a little more visible, we have pushed them to use more resources (hopefully hitting them in the wallet), and we have forced them to do something that, BY ITSELF, can be used as a spam indicator. As I mentioned in another post, I rarely get duplicate emails fro
Re:security through obscurity, again? (Score:2)
They can code around the retry-period for grey-listing mail agents. By then the honeypot mail agents will already have the email, and during the retry period the FTC can try to find the server for the contact URL or the phone number, and put a wire-tap on it.
Re:security through obscurity, again? (Score:4, Interesting)
Yeah, spammers are so clever. Well, the fact is if for every one of these "smart" (yeah, right) spammers who has the help of a network consultant that will work around greylisting there are 5 dumbasses who don't (and I think I'm being generous there), then if I greylist I'd think over 80% of my spam problem would be eliminated. What's wrong with that? What's to "get"? Looking through headers I see the same bulk mailers used over the years, probably passed around as warez in spammer circles.
Re:security through obscurity, again? (Score:3, Informative)
Well, the fact is if for every one of these "smart" (yeah, right) spammers who has the help of a network consultant that will work around greylisting there are 5 dumbasses who don't
This does fuck all when your one spamking is responsible for 80% of the SPAM (by volume.
Re:security through obscurity, again? (Score:2)
Re:security through obscurity, again? (Score:1)
Lots of the fools paying for the smart spam tools are too dumb to configure it. Eliminate those turkeys, and it will reduce the amount of spam significantly.
Re:security through obscurity, again? (Score:3, Insightful)
Quoting from the paper:
Re:security through obscurity, again? (Score:2)
As stated, the only reason the hour works right now is because the spammers don't see this in the wild. Re-running your database script an hour later isn't a big deal.
If you can send legitimate mail through a system from a random source on the Internet, you can run illegitimate mail through it. Period.
Re:security through obscurity, again? (Score:1)
What was stated in the article was that the 1 minute time would work only because the spammers don't see this in the wild - which is the reason why 1 hour is the default and the (currently) suggested setting.
You are correct that if legitimate email can be sent, then illegitimate mail can be sent. BUT, if a spammer sends 1,000,000 emails through a hijacked source, then has to send the 1,000,000 emails ag
Re:security through obscurity, again? (Score:2)
Nothing to do with open relays, my friend.
This relies on the fact that spam software, unlike a real MTA, doesn't do things like care about 4xx series temp fail messages. So, you recode your software so that it does, or so that it simply runs through the script again. This implements a 1 hour delay. Not a 1 hour wait between different messages, or anything. People get their spam an hour after you initiate sending. BFD.
RIGHT NOW, this will stop spam cold. In six months, it will be useless.
Re:security through obscurity, again? (Score:1)
Part of what I like about it is that they
Re:security through obscurity, again? (Score:1)
In six months, you start black listing the obvious patterns from spammers during that first hour.
Example: Why is random e-mail addresses at 123.234.158.42 sending 36000 e-mails to everybody from 1@mydomain.com to BBCACE@mydomain.com?
I think he's trying to spam me, lets add him to my black list before he annoys the 3000 users I have in that range.
IMarvin
Re:security through obscurity, again? (Score:2)
But you can already do that. And lots of people do. So spammers just hop IP addresses. So people block dynamic blocks. But that hurts legitimate users. And so on.
The only solution to the spammer problem is the granting of plenipotentary powers of execution to, well, me. I'll be like Judge Dredd, only not quite as big and menacing.
Re:security through obscurity, again? (Score:1)
Re:security through obscurity, again? (Score:2)
No. If it's widely deployed and if spammers adapt, in six months spammers will be forced to maintain the same IP number for 1 hour to get messages delivered (very difficult for the ones who compromise hosts) AND not have that IP number end up in blacklists during that 1 hour AND not have newer spam-pattern detection filters identify that IP number as spewing spam AND
But... (Score:2)
No, the real means of bypassing this is a little trickier.
Re:But... (Score:1)
Most people do not send me multiple duplicate emails, so if a spammer had to send his entire spam list twice withing 4 hours to beat the greylist, then that would be a fairly obvious spam signature in itself!
That's a good point (Score:3, Interesting)
Re:That's a good point (Score:2)
So you mix up your spams; rather than sending all viagra, you send a few viagra, and a few mortgage, a few horny teen sluts, and so on.
I'm not saying this is a bad idea; I'm saying that it's only going to work for a while. I'm saying that basing your defences on the fact that spam software isn't RFC compliant means your fine until the spammers get RFC compliant, and that isn't very difficult at all.
Re:That's a good point (Score:2)
> compliant means your fine until the spammers get RFC compliant, and that isn't
> very difficult at all.
Whats even worse is not all mail servers are RFC compliant either
Re:That's a good point (Score:2)
Exactly. That, and suddenly, if this system takes off, and all mail gets delayed by an hour, well, sure, the spammers need more resources, but so do legitimate mail senders. Suddenly you need to queue up your mail for an hour; disk space, send it twice; bandwidth, and so on.
Re:That's a good point (Score:2)
I'm not saying this is a bad idea; I'm saying that it's only going to work for a while. I'm saying that basing your defences on the fact that spam software isn't RFC compliant means your fine until the spammers get RFC compliant, and that isn't very difficult at all.
Re:That's a good point (Score:2)
I'm confuzzled. Oh, and I'm probably screwing up my recp to/mail from (or is it rcpt from/mail to?) but you'll get my point.
smtp service OK.
>EHLO i-am-a-spammer.com
Hello, i-am-a-spammer.com.
>MAIL FROM: somebody@yourdomain.com
250 OK >RCPT TO: somebodywhodoesn'twantspam@yourdomain.com
451: A temporary failure cuz your triplet is untrusted.
>curses, I'll be back later.
So who's going to vet it as 'spam?' Want to do it after the DATA message is sent? Then you're doubling your bandwidth.
W
Re:That's a good point (Score:2)
Want to try to identify based on the fact that there's a ton of mails coming through in a short period of time? What if the spammer simply re-orders his spam database, so it's not sorted by domain? If he has 1,000,000 emails, with, oh, 10,000 separate domains, then only every 100th email he sends will be to your domain, if he spaces them properly.
*nod* It is true your suggestion doesn't w
Re:That's a good point (Score:2)
Yes, but saying 'they're in some other spam resource already' is rather disingenious.
At that point, it becomes 'reject ALL MAIL for one hour, on the theory that if it's brand new spam, it'll be in RAZOR in an hour.'
Well, shit. Here's an idea. Have a function in mail servers so that they each have a public/private key. When you connect to a mail server, you give it your public key. It can then check that public key against a public database of 'known good' servers.
If the recieving server thinks t
Re:security through obscurity, again? (Score:4, Insightful)
I disagree. When you are sending 250,000,000 emails a day -- restarting that script IS a big deal. It would, in effect, make them have to do the entire thing twice. That's a pretty big hit on their resources.
Re:security through obscurity, again? (Score:2)
How, exactly, is it a big hit on their resources? It doesn't take very long to send out 250,000,000 emails.
Re:security through obscurity, again? (Score:2, Interesting)
If they are sending 250,000,000 ema
Part of the plan (Score:2)
Having your car up on blocks when all the other neighbors are doing it is one thing. When you're tho only one, your neighbors suddenly start focusing a bit.
I'm kidding. A little.
Re:security through obscurity, again? (Score:1)
Bollux: Mailserver peformance ~100k msgs/hr, peak (Score:2)
Most common single-server mail transports can sustain ~10k-100k deliveries per hour under ideal conditions, with this delivery rate frequently saturating available bandwidth. Issues such as MX and DNS resolution become significant at these volumes. Thus, 100m mails is 1,000 server-hours of time.
Sending more mail requires multiple servers and mulitple pipes. Both of these are resources which are only available to the spamhaus at additional cost or reduced control.
The mitigating issue is that multiple
Re:security through obscurity, again? (Score:1)
Re:security through obscurity, again? (Score:2)
So the trade off is that you're (at least) doubling your bandwidth requirements to save on bandwidth?
I still don't see the benefit; currently, somebody gets a spam, off it goes to Razor,or pyzor, or DCC, or whatever, then you still get it, but you reject it.
Now, you reject it for an hour, get it again anyway, then check it against razor or whatever, doesn't seem to be a net gain.
Still, if it catches more than about five percent of total, I guess it's worth it.
Re:security through obscurity, again? (Score:2)
Why not go one step further and take it past the turing machine answers of, "please enter in the number/word in this image and hit reply"?
Simple set of rules for email and web forms that works like this:
Re:security through obscurity, again? (Score:1)
Re:security through obscurity, again? (Score:1)
Re:security through obscurity, again? (Score:2)
Re:security through obscurity, again? (Score:2)
Oh, foo. What these experts know that's most valuable to them is that essentially nobody pays attention to the huge level of spammer abuse that the spammers commit to send their spam. Beyond the impotent "secure your open relay" campaign that they were told from the start wouldn't work 99.99% of the operators pay no attention whatsoever to the sp
Re:security through obscurity, again? (Score:2)
The problem is that good spam protection is a) a learning system that detects, defines and then filters out noise, keeping signal.
This is a very hard problem, but spam is FAR from the first place that it has been necessary to solve it.
I'll have more comments in a top-level comment, since there are some massive innacuracies in this paper. It's essentially mark