Dictionary Attack Crippling Us

[superbock]

Oh yeah.. I can say that greylisting is just an awesome concept. Massive results here. We used qmail though, with mysql backend. Works like a charm, since around 9 months ago.

However, it should only be used on frontend MX's.

 

[stupidnic]

Originally posted by voodoochile
My only problem with the above is that bounce behaviour on large servers is bad. You're not really solving any problems, just offloading it onto another server, which adds overhead to your operation and in turn extra costs, not to mention added layers of "things that can go wrong when rejecting the message altogether solves the problem at the frontline, rather than thowing servers, time and support at a spam problem, just stop it before it gets "expensive".

Another issue is that you assume that since a spammer gets bouncebacks from a server saying [email protected] isn't a valid user, that in turn, that account will never get spammed again. This is wrong as there's a ton of spammers out there, and they dont' really care too much about maintaining lists (hence why the use dictionary attacks in the first place). They just hammer out as much email as possible and dont' really worry about the bounces and whatnot. Hell, most of them forge the headers anyway so they never get the bouncebacks.

This in turn can also open you up to a different (and just as abused) method of spamming using bounces. When they send the email to a domain they KNOW bounces, they forge the from: portion of the header to be the real recpient of the spam, so your server does a dandy job of relaying the spam where it was supposed to go anyway and helped them cover their tracks.

I guess I didn't explain myself properly. Greylisting occurs at the SMTP conversation level, not at the MTA level. As such your concerns with bounces are moot.

There are no bounce messages injected into the queue, as greylisting simply returns a 4XX SMTP message in the STMP conversation between the two servers. The remote server is responsible for recognizing the 4XX STMP message and dealing with the message in its local delivery queue. Per the RFC any 400 level SMTP message is to be treated as a deferral with a retry, were as 500 level SMTP messages are treated as a failure, and will not be retried.

Also your point about false MAIL FROM and From: addresses (as almost all spammers use) and are commonly referred to as "Joe Job's" in the industry, is also moot as our greylisting server has no message to deliver via a bounce message since we never got to the payload or DATA portion of the spam message. Qmail has this exact behavior right now out of the box, where as our greylisting setup does not.

Finally, with regard to spammers pruning their databases of bad addresses... I have seen enough comprimised servers that have been used to send spam to know that there are three lists: one which is all the addresses to send the spam to, another which is all the messages that succeeded in being delivered (at least according to the SMTP conversation) and lastly another file that contains the messages which did not get delivered (once again via the SMTP converstation -- thereby rendering your argument about bounced messages moot). If you don't think spammers maintain their lists for maximum distribution with minimal overhead, you are mistaken.

I hope I have clarified your misconceptions about greylisting, and my apologies for hijacking genxer's thread.

Tom
aka: stupidnic

 

[voodoochile]

I had a fairly big piece written up on pros/cons of greylisting and instead of that, I think i'll just say this.

Greylisting is worthless against *ANY* spam sent from normal MTAs (Think Open Relays, Vulnerable Formmail-ish scripts and ONLY effective if the MTA that hands the e-mail to your server is a "custom" mail solution built by spammers that only sends one copy. Yep, that's right, if $spammailler updates figures this out, they're going to send two emails instead of one and walk right over your greylist. If they fire two e-mails off, the tuplet is going to be identified by your greylist making it effectivley worthless.

Greylisting is a good idea, but by no means anything to brag about. It's the code equivelant of duct tape on a much larger problem. *IF* you use GreyListing at all, it needs to be in conjunction with other methods as there is *No Way* in a real world environment that it can really deal with that much spam, plus do you want to tell your customers that they're e-mail is getting delayed for an hour (Or whatever) because it's fighting spam? One of the benefits to email is that it's fast and pretty much instant. Greylisting solves the "instant" problem.

Also, to be blunt, bouncing every email bound for a non-existent address is dumb. The *ONLY* benefit this could provide you is that in the future, the spammer that Just dictionary attacked your server will not spam that non-existent account again! Congrats, You've kept an account that didn't go anywhere, from getting spam and effectivley doubled the overhead for your server on a per-domain, per-email account basis while helping the spammer clean out his list a bit.

In short, Greylisting is a very mediocre method of blocking spam. Just because it runs "AT THE MTA LEVEL OMG" doesn't mean that it's effective. Although if that's your bag, here's this other Spamfiltering software that can run at the MTA level that might be a bit more effective for you. It's called SpamAssassin and you can probabally find some more info on it in google.

Sorry if this is somewhat terse, but I've been around the block several times with spam filtering solutions and it's a sorry sight honestly. When one method comes up, it's generally figured out and compromised in a *very* short amount of time, this especially goes for greylisting which, by nature is flawed. The only way to make it "more" effective is to delay mail for longer and longer periods of time, which only irks your customers and makes your mail service look shoddy and unreliable. Just about any of my clients would choose getting some extra spam over having random e-mails delayed for an uknown (to them) amount of time.

 

[superbock]

Dear voodoochile,

Since you seem so knowledgeable about anti-spam techniques, you should be the first to know that no technique is perfect.

Although you rant theoretically about greylisting, you should, instead, look at numbers and take the right conclusions.

Wether you want it or not, MOST spam is avoided by greylisting. Just because, in fact, the vast majority of it is NOT sent by regular SMTP's. That's a fact, period. And fortunately, i've had and have experience at ISP and hosting levels, in different locations, to support this affirmation. In average, a 73% reduction in spam queueing. HUGE!

Greylisting + rbl checks + anti-virus + spamassassin is one of the nicest mail filtering combinations, and i don't think anyone here is using JUST greylisting for filtering purposes. I know i'm not. None of the mentioned techniques excludes any other, although greylisting saves a lot of work for av and sa.

 

[voodoochile]

Sorry if you took offense to my post, but your evangelical view on greylisting listed none of the cons associated with it. This is bad as a lot of uninformed people read these forums and use them for guidance. My personal view is when telling people about new tech, you need to give them the whole story, something your post failed to do.

Also, you really shouldn't state percentages when dealing with this stuff, most numbers associated with spam reduction are complete BS. Because you received 100 pieces of spam yesterday, and today you implement $x spam prevention and you only got 90, this does not mean that $x is 10% effective at reducing spam. It's an ebb and flow deal, some days your servers get rocked, some days they don't. That's just a nitpick of mine though, there's no real way to quantify spam reduction as spam doesn't hit any server with any sort of consistency. Things change, spammers use new methods, your servers add email accounts, domains, remove domains and accounts, etc etc. The baseline for your calculatinos (graphs, stated percentiles, etc) changes by the minute and well, that doesn't make it a very good baseline.

Anyway, have fun. I'm sorry you took my post as a personal attack when I was pointing out issues with your "spam solution" and the way you deal with mail. This is one of those deals where everyone has their own way of dealing with stuff,

 

[superbock]

Rest assured, no offense was taken. I guess i'm just more pragmatic than you on this matter.

The numbers i provided, which relate to a large period of time, have a direct correlation with customer satisfaction and server load, and those are, for me, the metrics that matter, as a service provider that has to manage operation costs and customers satisfaction.

If GL, at this point, translates in great benefit for those aspects, if find it a great solution for the time beeing. Obviously, it's known spammers adapt, and our techniques will have to adapt too.

But for now, bottom line is: despite the "cons", there's no way i'll turn GL off... It blocks a lot, and if correctly tuned will be transparent for clients, and the risk of blocking valid e-mail is practically none existent. I don't really care if it's based on a subversion of the SMTP protocol, as long as things work.

I don't call this evangelizing. I'm here, as practically everyone else on this forums, just giving input and feedback on my experiences. It works for me, but everyone has to take the time to analyze the best solution for their specifics.

 

[stupidnic]

I stand by my comments about greylisting as they pertain to the original posters needs and as a resolution to his particular problem.

Tom
aka: stupidnic

You should never make assumptions... they are dangerous, and often... wrong.

 

[atomicturtle]

Side note, some MTA's cant handly temporary failures correctly, most notably Lotus Notes will treat a 400 as a 500 (permanent failure, drops the message).

That'd be one of the reasons I haven't update my qgreylist rpm in a few years

 

[superbock]

Yep, that's correct. But so far no complaints. The minute a client complains and we verify that the remote SMTP does not follow protocol, we add that SMTP's IP to the whitelist. Another case of residual risk over great benefit..