Roberto,

If SF will do that it will be easier to implement the option to disable this feature to some domains that want to be unfiltered from the Greylisting and limbo cache.... i have some problems using global filters because if only one customer does not want it i have to disable it to everybody.

I cannot understand why i cannot disable SFDC on a single domain.

I'm Using SFI ... SFE ca do that?

Roberto in another post (or email maybe) told me that Greylisting and ip limbo black list catch only the IP and nothing else, so it not possible to decide which domain should use Grey listing and which one not in the domain filter matrix ad u can actually do with SUBL, MAPS, etc.

You are asking SF to catch EmailFrom data for logging purpose so if SF will catch it, it will also ave the possibility to decide which domain has this filter and which one not because it catch also the DomainFrom data.

My problem is that some customer of mine wuold like to receive ALL spam ... i don't why but they prefer it instead of the risk ok some rare antispam error.

Is it more comprensible now?

When we first started to implement greylisting, we debated internally if to have SpamFilter output the 400 rejection error immediately upon connection, or wait for the MAIL FROM / RCPT TO commands so we could catch more information and be more flexible with the filtering options.

We opted for option #1 (immediate rejection) as we were seing some spammers retrying continuosly even after the 400 error, but using different MAIL FROM/RCPT TO addresses. Eventually, they retried so often that the 5 minutes interval for the greylisting elapsed, and they were then allowed to connect permanently. Not good.
We instead saw that, if they received the 400 right away, without giving them a chance to specify the from/to addresses, this caused them to "give up" much sooner, and they wold not retry again.

So we decided to loose the flexibility to improve the rejection reliability. Since as of now, after about a month, and over half a billion emails processed by all the SpamFilters out there, we still did not receive a complaint about it stopping good emails... we're very tempted not to make any changes
i

Roberto,

I'm sure that the greylisting works very well as it is, I can see that from our small setup.

However, when a customer reports a missing email, we have no way to track it. Did it get blocked by the greylisting??? who knows??

Currently our only option would be to disable the greylisting alltogether....not what I want to do.

So, can I please ask for a half way measure....that you implement a configurable option as to when the 400 response is issued and leave that descision to us.

You could leave it to operate immediately as default, but give us the option to issue the 400 response where we would prefer it, after the rcpt copmmand.

I do understand what you are saying about the limbo timeout, but you already give us the option to change this, so having the option as to where the 400 response is issued should be is a minor change, but will give us the logging info we need to be able to report back to our customers that the missing email did not arrive or get greylisted and we have the logs to prove it.

Thanke,

Roberto,