Web Hosting Talk : Web Hosting Main Forums : Web Hosting : Greylisting/SMTP banner delay

[Pillhead]

Recently started greylisting/SMTP banner delay in addition to spamassasin and I must say my spam has dropped 10 fold, from many 1000's of spam a day to less than a 1000.

I was wondering if anyone else has been using greylisting/banner delay and if there are any adverse effects of using it, i.e. losing mail from some none RFC compliant SMTP hosts or hosts who have set there retry queues to very low numbmers possibly too low for standard greylisting?

I'm just wondering with such good results if I am throwing away genuine emails as there is always normally a catch! ;p

[extras]

My previous host was using it, and fellow users were complaining about loosing mail notification from some services/registration-forms/etc.

I turned it off, after a while (although I didn't see any problem).

[David]

Pillhead,

I've found that with almost every method of filtering some legitimate mail is going to be lost. It's inevitable when your friends are forwarding their weekly viagra deals to you but it's something we learn to live with!

Overall I've found the best solution is end-client filtering: Saves on cpu and gives clients exactly what they want -- control.

(Someone will almost always whine about receiving too much spam but you can't please everyone )

[Pillhead]

Originally Posted by extras

My previous host was using it, and fellow users were complaining about loosing mail notification from some services/registration-forms/etc.

I turned it off, after a while (although I didn't see any problem).

Ahh yeah, I heard that yahoo newsgroups dont try again as per standard SMTP rules, though most forum software uses the local smtp mailer which would be something like sendmail/postfix/qmail so technically should adhere to the rules of those mailers and not lose any mail.

I think for my situation the benefits outweigh losing notifications/etc, cheers for the info though

[Pillhead]

Originally Posted by David

Pillhead,
Overall I've found the best solution is end-client filtering: Saves on cpu and gives clients exactly what they want -- control.

Greylisting saves you a tonne of cpu time due the fact the spam doesnt reach the spam filter

[linktome]

Originally Posted by David

Overall I've found the best solution is end-client filtering: Saves on cpu and gives clients exactly what they want -- control.

(Someone will almost always whine about receiving too much spam but you can't please everyone )

even though, spam will take a lot of system resources, and I have seen many customers dont know how to manage spam at their end :| I prefer a filter system from server side, even it might make some emails lost, but as you said, you can't please everyone

[Pillhead]

I'm just going on the principle that as long as no important HAM is getting lost I'm happy, I couldnt really care if someone loses stuff like subscription list notifications from yahoo.

I guess that most important mails will be coming from normal end users who will use an average joe bloggs ISP that is probalby an RFC complient SMTP mailer, its only mass mailers that dont want to confirm to this standard, oh and some old version of lotus notes apparently (well you need beating with a stick if your using lotus notes so probalby good thing the mail didnt get delivered ;p).

As long as noone knows of any big ISP that runs there SMTP mailers in this way, I'm failry happpy I think

[Mike V]

Good experiences here with greylisting. Using a product called XWall to handle the greylisting, and so far it seems to have cut back on the "fire and forget" spammers. It ranks up there with Bayesian filtering on my list. Provided that users help "teach" the Bayesian filter, of course

[vantage255]

We Greylist. It has been VERY effective. Probably the biggest single thing we have done to reduce spam.
I haven't noticed any issues with Yahoo groups.. I have has some trouble with a few cellular providers who have built there own mail systems that will not resend..

[RossH]

I think you can effectively filter without greylisting *shrug*. I've never been a real big fan of it considering if you run a large mail complex and all the servers your complex has to send mail to greylist thats a ton more sockets open at once which means you have to buy more hardware, etc.

[Ankheg]

Not a fan of greylisting at all. It's only effective against a moderate percentage of spam, generally the easiest-to-identify kind, it doesn't help much at all if you've got more than one MX, it does block a fair bit of legitimate mail, and it delays the delivery of legitimate mail, sometimes by as much as half an hour or longer (and is more dependant on the settings of the sending server than those of the receiving).

[vantage255]

If you have your greylisting set up to whitelist a netblock after it is successfully sent one mail through the greylist filter then you only delay that 1 email. Usualy done with /24 netblocks, this generaly resolves most of the mail delay and blocking of legitimate mail issues.

[Ankheg]

True, but whitelisting /24s seems (to me) to be defeating the somewhat useless point of greylisting, namely forcing sending hosts to "prove" they're somewhat functional mailservers, and not just scripts or bots. If I accept email from the mailserver for (a ficticious, I think) Nishnabotna Technical College, it doesn't mean I want to accept mail from three classrooms full of infrequently-updated Win2K workstations...

If you're going to whitelist, which I'm not convinced is of any real use, it should, IMO, be done on a per-server (read: IP) basis. Otherwise, it's a bit like giving your friend a key to your house so he can feed your cats when you're on vacation - and giving a key to everyone who lives on his block, as well.

[vantage255]

I think, Like everything when dealing with spam, there is a grey area. We whitelist /24s. We due it to prevent some of the issues listed above. We expire the whitelist after 24 hours. It seams to have the effect we were looking for. We have been doing it for a long while now. It took some tweeking to get it just where we were comfortable. But I havent gotten any customer complaints about it in many months and it has cut the volume of mail by 60%. and spamassassin is no longer the highest cpu user on our mail servers.

t might not be right for everyone. and like all other solutions, it needs to be thought out. But we love it and it has worked to our expectations.

[Pillhead]

Originally Posted by Ankheg

Not a fan of greylisting at all. It's only effective against a moderate percentage of spam, generally the easiest-to-identify kind, it doesn't help much at all if you've got more than one MX, it does block a fair bit of legitimate mail, and it delays the delivery of legitimate mail, sometimes by as much as half an hour or longer (and is more dependant on the settings of the sending server than those of the receiving).

Well may badmail archive which is a gunzip of the last 24 hours spam mail run overnight dropped a digit in size, think its safe to say its slightly better than moderatly effective ;p

I use spamassassin with DCC/PYZOR and all the other mod/cons and actual spam hitting my mailbox has also dropped 10 fold, so spam caught by spamassassin has dropped 10 fold + an actual decrease in spam not caught by spamassassin adds up to alot of CPU time reclaimed plus less spam for me.



In terms of effectiveness it is the single most effective method I have implemented yet, though obviously jubious of losing genuine mail, delayed mail is a small price to pay.