No, it's not bad practice. It may be inapplicable to your systems, but don't treat your CPU overhead problems as if they are the same problems everyone else has.
Some sites have serious constraints on latency due to "mission critical email", to the point that the extra CPU overhead and network bandwidth usage is worth it greylist post-SA.
You have CPU overhead problems, to the point the extra latency is worth it to greylist first.
Both are perfectly valid uses of greylisting.
Neither of these systems defeats the purpose of greylisting or SA, although both sacrifice one benefit for another.
Agreed.
I could argue that by greylisting before SA you're loosing SA's benefit of spam filtering without the extra retries of greylisting. But that doesn't mean you've COMPLETELY defeated the purpose of using SA. You've lost one benefit to gain another. It's all a matter of optimizing your configuration to fit YOUR network, which is very different from the networks of other users.
As stated before, it will not scale well at all.
Agreed. However, to state that this COMPLETELY defeats the purpose if greylisting is entirely untrue.
Definately the wrong word on my part.
It *IS* a perfectly valid configuration for systems that have sufficient bandwidth and CPU to bear the load and can't afford the latency of greylisting all their mail.
Yes, it has limitations, but so does your configuration. Neither is an optimal solution for every network in the world.
My main goal is to provide users with a stable main environment.
The greylisting daemon i am using was coded by myself, from the ground up. The newer releases of the code provide functionality that make `false positives` very rare.
The functionality i've built in is per user whitelists which i have not seen any other implementation of greylisting have..
Regards, Cami
