From: Matt Sergeant <msergeant(_at_)startechgroup(_dot_)co(_dot_)uk>
...
No, the goal of this is to have a standard way to trip a spam filter that
is supported across the industry in a non-changing fashion. I don't care
*how* the filter gets tripped (whether it bounces or quarantines or adds a
header or munges the subject...), just that it does get tripped.
The idea is that when I install a new spam filter I want to be able to
check its working, and I want to be able to do that without having to use
a different email for each content filter, or without having to have
intimate knowledge of how this particular filter works.
Often a sysadmin would install a new spam filter on a test machine, so
waiting for spam to come through wouldn't be an option.
Ok, I stand corrected about whether it might make sense to standardize
such a thing. However, this does not sound useful enough for me to
put it into the DCC this year. Spam and viruses differ. It's far
more difficult and/or dangerous to give a Windows box a test infection
of a virus than to send test spam to a mail system. To test a spam
filter that can be tested with a standardized test, you can instead
grab something from NANAS or whatever spam you hate and send it from
somewhere, such as a free provider or one of your own systems. A
bigger problem is that anti-spam systems define spam in differing
ways. For example, how would a standardized spam filter test check
that an SBL installation is working? (The testing auto-responders
permanently listed i the RBL, DUL, and RSS should be but are not be
emulated by all DNS blacklists.)
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg