Never mind the qestion about the SFDC, it is working.

Looking at the filter order it does not appear there is a way to manually add an IP that might be having a problem, short of shutting down SFE and manually updating the greylistallowed.txt file and then restarting SFE to read the list it. Haven't had that need occur but today is the first full day of testing and its the busiest

Desperado,

Currently the greylist file is only imported once when SpamFilter starts up. We were going to change thing so it would be re-imported when it changed, however...:
1 - the filter is working so well, with such almost undetectable delays after a couple hours of implementing it, that we may not see the need for this
2 - this greylist file can easily contain millions of IPs, and allowing SpamFilter to read changes by an external program while SpamFilter itself writes to it may introduce too many problems..

We're leaving things "as-is" right now and we'll see how this filter evolves.

For the order, both the blacklist cache and the greylist will immediately terminate a connection if it doesn't pass the tests. The blacklist cache is smaller, and is thus slightly more efficient to check it first so we can block any spammer that will pound SpamFilter with multiple connection attempts before checking them against the greylist.

:-)  the "problem" with the blacklist cache is that, since it blocks connections at the TCP level right away, all the spam that would have been received is never seen, and thus, unless looking at the logs, you never see how much spam was really blocked (a lot!!)

My 2 Cents:

Nothing very scientific:

kspare,

Atif,

I don't know what to say here... this was supposed to be an alpha version as we were just about to start testing it here at LogSat internally. I got tricked into leaking it here on the forums, and that same build then suddenly became a beta. As of now we still did not receive a single bug report on it, so it may as well be promoted to official release...
With this kind of luck, I may just disappear for a few days as I'll be spending them in Las Vegas!!

As usual, our ears are always open to advice. We'll keep an eye on this, but please do note that with our "flavor" of greylisting, we are greatly reducing the risk of delaying delivery of emails due to the greylisting. yes, the side effect is that more IPs will slip thru, but (1) the other filters should get them, and (2) we can always tweak the greylisting parameters to reduce the number of days (90 by default, which is maybe excessive) permitted IPs remain in the "permitted" state.

I hear ya Dan, I just reset greylisting to the same settings as you and wow, the difference on my database is just night and day, there is no way you could write a sql script to remove all this automatically and be 100% accurate.

I'd normally have 1000+ spams alone in the queue for me personally and now I have zero, so i'm pretty impressed!

although we are very impressed with the greylisting, i see a lot (ten of thousands) of ip's which are clearly spammers ip's.

I'm thinking the following:
As an ISP we host email for over 2000 domains.
lets say spambots start sending emails at 15:00 and domain 1 is first on the list.
connection is rejected, and delayed for 300 seconds (or whatever the setting is)
even is this ip then tries to reconnect, it will only be allowed to reconnect at 15:05 right?
at 15:01 there are a couple of emails for domain 2 - 10
at 15:02 there are a couple of emails for domains 20-50
and so on.
at 15:05 we start receiving emails from this ip, bypassing the greylist.

The problem here, is that with this method of greylisting if you're places under spam attack for lets same 15 minutes, from the same ip range, then after 5 minutes they've broken through the first barrier. chances are they'll get caught straight away, but this situation is theoretical only.

We've observed that an ip range was sending emails (spam) for various domains, for over 1 hour. not spam flood, just a trickle. however since the greylist (on an installation with a lot of domains) "stops" working after 5 minutes,  it kinda defeats the point.

My suggestion is as follows:
on first connection start counting the time (by default 300 secs)
If further connection attempt are tried BEFORE the full 300 secs have expired, reset the count.
example:
first connect from 196.197.101.101 at 15:00
time to allow ip 15:05
second connect from 196.197.101.101 at 15:01
time to allow ip 15:06
third connect from 196.197.101.101 at 15:05
time to allow ip 15:10
and so on.

a correctly configured smtp server SHOULD not retry in a less then 5 minute period.
this change will greatly reduce the number of spam bots which are bypassing the greylist, as the timeout will continuously increment.  of course this 'may' lead to issues if the connection delay is set to too long.

any thoughts?

Amir

The greylisting has helped a lot, but your right, the spammers find a way a usual to circumvent this.

The greylisting occurs at the TCP level right after a connection attempt is detected. The server is disconnected before they even have a chance to output the commands that specify the sender and the recipient. For this reason, neither the "from" nor the "to" domains are known, and thus the filter can't be customized per domains in SFE, nor can we log that in the SpamFilter logs, sorry!

FYI - an updated beta is available in the registered user area.