Mark Rogers wrote:
Steve wrote:
Mark Rogers wrote:
Basically, to check everything around dspam.
- To make sure spam gets quarantined correctly, and that the right
user can see it in their own quarantine box and process it.
- To check that any user can change their own settings and see the
effect on incoming spam (eg quarantine/tag/etc)
- To compliment the logs when trying to understand the path an email
is taking through dpsam (eg "tail -f" a given dspam/postfix/whatever
log, inject a "known spam", see what happens).
- To test that a domain is correctly configured to trap spam prior
to that domain's MX records being pointed to the server (weak
example, since this is pretty easy to check via mail headers too).
And you plan to capture all of the above test with one simple GTUBE
test string?
I don't see why not!
If GTUBE were supported I could send GTUBE to any (or all!) users I
support, and check that it arrives in the correct quarantine for that
user.
I could change a user's settings (eg to TAG instead of QUARANTINE) and
confirm that GTUBE now came through to their mail client correctly
tagged (and even set up mail client rules based on that and test them
too).
I routinely now "tail -f mail.log" (for example) and in a separate
session telnet to postfix on port 25 and send a test email to see how
postfix is processing it. It is very difficult to send a spam this
way, but I could copy+paste a GTUBE string in easily if I knew dspam
would recognise it as spam.
I can send mail directly via my mail client to my server for a domain
whose MX records have not yet been transferred and perform any/all of
the above tests prior to making DNS updates.
I am talking about multiple tests, of-course, but at each step the
ability to send a mail through (and trivially at that) which I know
dspam will treat as spam is helpful.
And so on. Pretty much the equivalent of EICAR: if your AV program
catches EICAR it doesn't prove that the AV program is functioning
100% correctly (eg properly downloading updates etc[*]), but it does
at least make it easy to test that the system is able to handle a
simple case.
But DSPAM does NOT download anything. DSPAM learns from the data it
receives or from the user making decisions.
Me and my analogies causing confusion again! My point was that EICAR
allows a basic functional test of AV; it does not and cannot test
everything (such as updates) but that doesn't stop it being useful.
GTUBE could not test everything in dspam either, but it would still be
useful for the things it did allow me to test.
Something so universal and easy as the EICAR or GTUBE is not
possible with DSPAM (actually this is not possible with any pure
statistical filter).
Agreed: it would have to be a special case in the code, and one which
could be disabled (indeed would probably be disabled by default). It
would do nothing to test whether or not the statistical processing and
learning of dspam is working whatsoever, but it would simplify the
testing of the integration of dspam with other components and basic
tests of its configuration such as quarantine settings, as described
above.
It may be difficult to add (or at least difficult to add without
compromising other code), or it may be I'm the only one who wants it,
but those are separate issues!
[8]Long ago I thought that it would be useful if EICAR did release a
new test "virus" every month or so, so that testing with a current
EICAR binary would test that updates were being properly downloaded
and installed. But that's another story.
test my AV by ensuring that the download/update process is working
correctly. Testing my AV with EICAR (even if it would be new each
month) is not the right approach for a functional test. At least I
don't see it as a perfect test.
Absolutely agree, but your last point is the important one; its not a
perfect test but it is still a test. Checking I can ping my web server
is not a perfect test but I still want to be alerted if that test
fails. Sending this month's EICAR through my AV would not be a perfect
test but it would still be simple to automate and helpful to know if
the test virus ever got through, because it never should.
And on my last point (that this is "another story"): this is
completely irrelevant to dspam as it doesn't download updates so there
is no equivalent; a monthly GTUBE would be of no benefit even though
(I still believe) a single GTUBE would be.
Mark,
I personally feel that being able to use GTube as a spam test would be
usefull, maybe not for testing accuracy, but definitely for testing the
flow of spam/ham through a system (though it is arguable that this could
be done without a dedicated GTube string, and could have adverse effects
on accuracy).
If you would like to use the GTube string, then create a Global user,
send that Global user an email containing the GTube string. Train it
several times (training could be done via Corpus Feeding also). Once the
Global user is accurately identifying the GTube string as spam, create a
merged group with the Global user as the trainer, and presto. You have
your GTube test system. For most testing purposes all you need to do is
look for the dspam signature to know if dspam is processing a message.
But in cases where you need a sure fire Spam message for testing the
GTube string would be nice.
-Jeff Harris
