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 Rogers // More Solutions Ltd (Peterborough Office) // 0845 45 89 555
Registered in England (0456 0902) at 13 Clarke Rd, Milton Keynes, MK1 1LG
