Martijn Grooten wrote:
Yes, that makes sense and, if you're running a test (and don't care too much
about computational performance) could be extended to content scanning too.
But that assumes you are able to identify messages, which I doubt is possible
to do in a reliable way unless you greylist during/post DATA. Which -- at least
in theory -- does not need to give the same results as greylisting at an
earlier stage.
I guess the only way to really test the effectiveness of (your version of)
greylisting (on your mail stream) is if you have a reasonably large stream and
you split that feed in two random groups and use greylisting one group only.
(I suppose most people don't care as much about measuring effectiveness as I
do, nor should they, but including something about effectiveness may be a good
idea as this is the main reason people use greylisting.)
I think that it's not serious to run any security tool without monitoring it. If you run a tool
which may reject messages (or any kind of communication), you should monitor and know how it
performs : how many connections it handles, how many connections it rejects, etc, etc, etc... If you
do, and observe this numbers each day, you can have some idea about effectiveness. "Fire and forget"
is never a good thing in security.
An unattended and interesting side effect of greylisting is that it blocks a
lot of virus/worms.
José-Marcio
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg