spam weapon "greylisting"

It can be added completely through the exim.conf file (and a database). The current exim.conf file used by DA is written by me. I don't have time to add it now, but I could at some point in the future. I probably won't use it for my own domains because I don't like email to me to be delayed, even for first-time senders.

If someone else would like to do it in the meantime, that would be fine with me :) .

Jeff
 
Hi - Do I understand this correctly - Greylisting PURPOSEFULLY bounces email addresses if they have never mailed the server before even if there is the slightest possibility they are legitimate??

Rob
 
Well....

It doesn't "bounce" them.

If it's never received an email from you before, it will refuse emails with a temporary error. The sending server will try again later. The second time, it will let the message(s) through.

The question is how much later. This makes a difference to me, because, for example, if you have a server down, and decide to write me for help, I don't want email from you to be delayed an hour.

I like to get email immediately.

So I won't use greylisting. But that's just me.

Jeff
 
I agree - theres absolutely no way I'll be temporarily refusing emails for every user for an indefinate amount of time.

Thats a recipe for disaster - the phones wouldn't stop ringing with clients wanting explanations, and when they emailed to see what was wrong their messages would bounce!

In this crude form we wouldn't use greylisting. It would have to be configurable at userlevel with any recipients that did not want to use it in a recipient whitelist at server level - which of course they would be added to by default when a user is setup.

Maybe a user level interface could simply add or remove them from the whitelist to define if their emails went through the 'greylist filter' - it sounds simple enough but would it work ?

Rob
 
I just want to clarify for Matrixx and others that it won't delay emails for every user, just for every user who's never sent an email to the server before.

For me that's not acceptable; it may very well be for others.

And also, undetermined doesn't mean indefinite.

Most servers will retry more than once an hour.

The beauty is that Spam servers generally won't retry at all.

Jeff
 
jlasman said:
It can be added completely through the exim.conf file (and a database). The current exim.conf file used by DA is written by me. I don't have time to add it now, but I could at some point in the future. I probably won't use it for my own domains because I don't like email to me to be delayed, even for first-time senders.

If someone else would like to do it in the meantime, that would be fine with me :) .

Jeff

Hi Jeff, I was wondering if when you do this whether it could be configured for each user (not pop a/c but user as in DA user level).

I appreciate each user would have to be added manually until it was officially 'adopted' and integrated into the GUI by DA.

I'm unsure of the size of the job - is it something that you feel should be financially contributed towards?

Rob
 
this would be a cool feature if configurable in the user control panel, and off by default, but no way I will add this globally across the system, would be a support nightmare.
 
matrixx said:
I'm unsure of the size of the job - is it something that you feel should be financially contributed towards?
It's unlikely I'd could be made to feel comfortable scheduling it by a donation; I'm just too far behind on other work right now.

Jeff
 
Does the fact that I haven't been able to take a minute to even get onto the forums for about a month answer your question? Incredibly busy.

However, we've expanded, and we now have staff; it's not just me (and Onno) anymore :) .

A completely new SpamBlocker is on the horizon.

Jeff
 
Well, good exim.conf and sa and clamav should be enough, but need some work.

But new spamblocker will certainly make our life easyer, and with auto update i suggest (and hope).
 
SpamBlocker itself will never have autoupdating, because SpamBlocker is simply an exim.conf file.

The eventual commercial MailBlocker Pro will, but it will have to be completely rewritten.

Updating SpamBlocker automatically isn't easy, because after all it's got to update just the SpamBlocker portions of the exim.conf file, and not change the portions of the file which you may have changed yourself.

Jeff
 
spam blocker is ok

I think currrent spam blocker is blocking more than 90% of spam. I know grey listing is a very good weapon. but if anybosy start the work of grey listing i am interested to work together on that project
 
Back
Top