Independent testing of various AntiSpam solutions (commercial and free products)
The purpose of this test was to evaluate the effectiveness of various anti-spam systems. The following products were selected for testing:
• Apache Spamassassin - SA (free)
• Yandex Spamooborona 2.3 - SO (commercial)
• Kaspersky Antispam 3.0 - KAS (commercial)
• FastBL 0.7.0 (free)
• dnsbl listings:
bl.spamcop.net
cbl.abuseat.org
dnsbl.sorbs.net
dul.nsbl.sorbs.net
dul.ru
sbl-xbl.spamhaus.org
zen.spamhaus.org
DNSBL listings were chosen for popularity of use.
A separate server (P4 3.0GHz HT / 1GB RAM / FreeBSD 7.2-PRERELEASE) was allocated for each product, on which mail correspondence was tested. As MTA, sendmail compiled with milter support was used to connect the SA, SO, KAS services. To test commercial products, temporary licenses obtained from the developers site were used.
Mail traffic was used incoming for two domains, registered in 2002 and 2003. The total daily traffic for these domains ranges from 5 to 12 thousand letters, which is an ample amount of mail for testing. These domains are mainly used for personal correspondence, subscription to mailing lists and have about 10 real mail recipients available. Personal traffic on these domains ranges from 10 to 40 emails per day, which allows us to evaluate the effectiveness of the products tested, as well as the False Negative coefficient for each of the systems. Unfortunately, because of the small personal traffic, it was not possible to estimate the False Positive coefficient, but this is not a problem, since the systems under test use standard methods for evaluating spam and the probability of normal email getting into spam is very small.
')
The server connectivity for analysis was as follows:
The main relay accepted all incoming connections and performed their initial analysis by querying DNSBL lists, verifying the compliance of the RFC session (FastBL), then redirecting the letters further to the servers with the tested products. At once I will say that the requests in the DNSBL zone were only for receiving information about the IP address, but the address was not blocked. Testing was carried out without additional “tuning” of products in the form of overstatement of estimated coefficients, i.e. "As is".
Due to the fact that the systems under test have different methods for testing letters, the products were updated according to the following scheme:
"Apache Spamassassin" - sa-update once a day
"Kaspersky Antispam" - every 3 minutes
Yandex Spamooborona - every 20 minutes
The specified time intervals are due to the possible frequency of new updates and recommendations of the developers.
Each of the products has its own characteristics of testing email content:
Kaspersky Anti-Spam uses offline testing, regularly updating its local databases, plus the ability to connect dnsbl sheets.
Yandex Spam Defense uses online-testing technology, constantly working with its central server, as well as updating its local databases as needed, while also having the ability to connect dnsbl sheets.
Apache Spamassassin uses offline data processing, as well as online services of DNSBL, Razor, Pyzor, DKIM, SPF lists.
SA and KAS use fork () to process each letter, and SO, in turn, uses Threads, which is much more economical in terms of memory consumption. At the same time, SA uses preforked processes, limiting the likelihood of memory overruns, and KAS forks as needed, without exceeding the level of filtering processes above the limit specified in the configuration file.
Approximate memory consumption for each process:
SA ~ 40 MB
KAS ~ 30 MB
SO ~ 90 MB
Below are the results table with comments.
Abbreviations used in the tables:
PS - Passed (number of missed letters)
BL - Blocked (the number of blocked letters defined as SPAM)
FN - FalseNegative (The number of emails identified as good but being spam)
FP - FalsePositive (The number of letters defined as SPAM, but not such).
The first day of testing began with a strange breakdown of the anti-spam protection of the Kaspersky Antispam product, and therefore KAS missed more letters than expected. The same day showed the weakness of the separate work of dnsbl lists and SpamAssassin against Russian spam. When testing, I specifically sent 4 letters with quoting of one of the spam emails with word mixing to the test server. Kaspersky in connection with contextual content analysis sent a valid letter signed by DKIM from gmail.com to SPAM. On the one hand, the content of the letter was indeed spam, but, in turn, the letter was rated [SPAM] instead of [Possible Spam]. Taking into account that this letter could be forwarded to the system administrator to analyze the contents of the headers, KAS received 1 FP.
On the second day of testing, Spamooborona and Kaspersky Antispam leveled their positions.
On the third and fourth day of testing (weekends), Spamooborona’s protection was worn out a little because of a sharp surge in single messages. Since the data on the constituent components of letters from Yandex Spamooborona are processed online, it is likely that there will be misses of messages that have not had frequent repetitions. Kaspersky Antispam, in turn, showed the advantages of its offline rating system.
On the fifth day, there were no special surprises, except for an increase in the number of breakouts in Kaspersky Antispam.
On the sixth day, Spamooborona grabbed FP, blocking a valid newsletter with subscribe.newsland.ru. On all days of testing, quite a large number of NDRs came with reports about non-delivery of spam messages, but all NDRs were filtered by products like SPAM and did not deal with this. Although this is not true.
At the end of all tests, 125 absolutely valid letters were allocated from the total volume of letters (44552 letters), on the basis of which the parameters FalseNegative and FalsePositive were calculated. If we exclude the first day of testing, then we see how commercial products go hand in hand when analyzing spam. Spamassassin is still designed for the analysis of foreign spam and often misses letters due to the lack of content normalization. Commercial products lead letters to a particular type. For example, the method used by spammers to insert extra characters in words like: “PAA, S.Y., L = KI,” and also replacing Russian letters with similar English letters is completely ineffective against normalization, in which the distorted the word will still turn into “mailings” and will fall under contextual analysis, adding for each such word a certain amount of points to the entire letter. In turn, SpamAssassin quite well distinguishes foreign spam of the type “Medical, Viagra, Cialis, Enlargement”, and also well filters “bayes poisoning” context analyzers.
Concerning dnsbl-lists the opinion has developed ambiguous. On the one hand, the popularity of public dnsbl is very high, and they can provide protection against spam to a certain extent. But, on the other hand, dnsbl lists cannot be used as a panacea, since there are still FPs when working with valid domains. As for checking incoming connections by RFC (FastBL), not a single FP happened during testing and the level of filtering is comparable to commercial products. But that's another story. :)
Well, and finally, I decided to tabulate the variants of events in the event that the context analyzers worked in conjunction with DNSBL lists. As expected, I got 100% effective spam filtering even when using a foreign Apache SpamAssassin product.
Now about the saddest thing in this informative story about anti-spam - about setting up and licensing commercial products.
Despite the almost flawless core of products, the outer wrapper is very unsuccessful and inconvenient. Personally, I expected more professionalism from the developers of such products.
So, a few "spoons of tar in a barrel of honey."
Both products are focused on installation on the FreeBSD 6.2 system, which has long been outdated in terms of security, as well as the product versions used in the release (I had to use shaman compat6x).
Kaspersky antispam contains perl 5.6.2 in its distribution, as well as some of the specific perl modules. The KAS administration console uses thttpd and system harness in the form of pearl barley CGI scripts. Of course, it looks beautiful, but, in my opinion, not very informative, although it has filter schedules. It is possible to create user groups with different filtering methods, there are white / black lists - both users and ip addresses. Unfortunately, I did not find the ability to use external databases of users and groups in the administrator’s web console (perhaps buried somewhere in console utilities). With licensing, it is also not entirely clear; formally, I have nowhere found a quantitative unit by which per-user licensing is assessed. In a temporary license, the specified processing threshold of 250 megabytes actually ranges from 250 to 499 megabytes. Product licensing is based on the license file obtained upon purchase. The system supports the addition and installation of multiple licenses. Well, my biggest “fi” towards KAS developers is the method of installing the milter filter in the sendmail.cf configuration file.
Guys!!! Why do you rule the WORKING COMPUTER CONFIG, which, with the FIRST update, will cancel all the changes made?
The script of adding a filter to the config upon closer inspection has the same-hidden flag, which allows you to specify sendmail.mc to inject the lines that call the filter, but this flag is not called from the MTA-config.pl configuration script
All KAS processes run under the user mailflt3, which has its own directory for / usr / local / ap-mailfilter3. Startup scripts use the old service startup mechanism, which is not controlled from /etc/rc.conf.
Yandex Spamooborona also surprised me. The configurator is written in DIALOG, I didn’t expect this at installation. The branches of the configurator are very "razlapistye" and very easy to get lost there. Most of the settings are already preset, but it is better to go through all the items in the menu and set the parameters you need. SO has the ability to work with plaintext files, LDAP and judging by the pieces of SQL code in the config, it also knows MySQL. After I set up the work of SO, one person asked me: “I just heard reviews from some anti-spam vendors that supposedly spam defense was terribly difficult to set up and no one who bought direct support from Yandex couldn’t get it. Or are you the only one rare, or someone lying somewhere. ”
In reality, setting up with plaintext files is not so complicated, and, in principle, completely transparent. But it seems to me that the main configuration problems are still related to LDAP and MySQL. Licensing policy is also unusual. To protect against spam, you must either manually or automatically register all email addresses that the system will protect. Because it is really uncomfortable in a dynamically growing network, it makes you wonder. Per-user licensing is based on this list of users. I can’t say what will happen if the list of users increases the maximum level specified in the license, but it seems to me that this is not entirely correct. In my organization there are about 30 domains, 600 users and about 50 groups. Given that each user can have addresses from two domains (for example, alias), I will have to buy an almost unlimited license for the normal operation of my company. A separate article is the licensing key. The key is generated from two files: spam.ini (the main config of the filter) and domains (the list of protected domains). These two files are sent to the SO web server “manually” and, after filling in the necessary information in the web form, the server generates a key. The key is saved to the so.key file and placed in the directory where the other SO settings are located. And God forbid you to fix at least one bit in the spam.ini and domains files - the whole registration procedure will have to be repeated, otherwise the filter will not work. A good plus for novice administrators is the Russification of the SO configuration interface.
Describing the configuration and operation of SpamAssassin makes no special sense, since it is installed on the vast majority of mail relays.
Well, in principle, everything seems to be. What I wanted to write and say - wrote and explained.
Doubts about the bias of testing, I, of course, accept from anyone. If you think that this testing was biased and you can get other results without seriously tightening the screws, you can send me a personal configuration file of the product you are interested in, and I can put a couple more servers with the existing and your configs, then we will again compare the results.
PS: If there are questions about testing, then Kaspersky Lab wrote a wonderful document: www.spamtest.ru/document.html?context=15948&pubid=16638 , in which you can find all the recommendations for tests. In my tests, they were observed as accurately as possible, except for the testing time, all the same 2004 document.
ZZY: Ready to catch the stones in your garden.
ABORCHE 2009
SpamAssassin config:
bayes_auto_learn 1
bayes_ignore_header X-Bogosity
bayes_ignore_header X-Spam-Flag
bayes_ignore_header X-Spam-Status
loadplugin Mail :: SpamAssassin :: Plugin :: AWL
loadplugin Mail :: SpamAssassin :: Plugin :: AutoLearnThreshold
loadplugin Mail :: SpamAssassin :: Plugin :: Bayes
loadplugin Mail :: SpamAssassin :: Plugin :: BodyEval
loadplugin Mail :: SpamAssassin :: Plugin :: Check
loadplugin Mail :: SpamAssassin :: Plugin :: DKIM
loadplugin Mail :: SpamAssassin :: Plugin :: DNSEval
loadplugin Mail :: SpamAssassin :: Plugin :: HTMLEval
loadplugin Mail :: SpamAssassin :: Plugin :: HTTPSMismatch
loadplugin Mail :: SpamAssassin :: Plugin :: Hashcash
loadplugin Mail :: SpamAssassin :: Plugin :: HeaderEval
loadplugin Mail :: SpamAssassin :: Plugin :: ImageInfo
loadplugin Mail :: SpamAssassin :: Plugin :: MIMEEval
loadplugin Mail :: SpamAssassin :: Plugin :: MIMEHeader
loadplugin Mail :: SpamAssassin :: Plugin :: Pyzor
loadplugin Mail :: SpamAssassin :: Plugin :: Razor2
loadplugin Mail :: SpamAssassin :: Plugin :: RelayEval
loadplugin Mail :: SpamAssassin :: Plugin :: ReplaceTags
loadplugin Mail :: SpamAssassin :: Plugin :: Rule2XSBody
loadplugin Mail :: SpamAssassin :: Plugin :: SPF
loadplugin Mail :: SpamAssassin :: Plugin :: SpamCop
loadplugin Mail :: SpamAssassin :: Plugin :: URIDNSBL
loadplugin Mail :: SpamAssassin :: Plugin :: URIDetail
loadplugin Mail :: SpamAssassin :: Plugin :: URIEval
loadplugin Mail :: SpamAssassin :: Plugin :: VBounce
loadplugin Mail :: SpamAssassin :: Plugin :: WLBLEval
loadplugin Mail :: SpamAssassin :: Plugin :: WhiteListSubject
report_safe 0
rewrite_header Subject ***** SPAM *****
use_bayes 1
• Apache Spamassassin - SA (free)
• Yandex Spamooborona 2.3 - SO (commercial)
• Kaspersky Antispam 3.0 - KAS (commercial)
• FastBL 0.7.0 (free)
• dnsbl listings:
bl.spamcop.net
cbl.abuseat.org
dnsbl.sorbs.net
dul.nsbl.sorbs.net
dul.ru
sbl-xbl.spamhaus.org
zen.spamhaus.org
DNSBL listings were chosen for popularity of use.
A separate server (P4 3.0GHz HT / 1GB RAM / FreeBSD 7.2-PRERELEASE) was allocated for each product, on which mail correspondence was tested. As MTA, sendmail compiled with milter support was used to connect the SA, SO, KAS services. To test commercial products, temporary licenses obtained from the developers site were used.
Mail traffic was used incoming for two domains, registered in 2002 and 2003. The total daily traffic for these domains ranges from 5 to 12 thousand letters, which is an ample amount of mail for testing. These domains are mainly used for personal correspondence, subscription to mailing lists and have about 10 real mail recipients available. Personal traffic on these domains ranges from 10 to 40 emails per day, which allows us to evaluate the effectiveness of the products tested, as well as the False Negative coefficient for each of the systems. Unfortunately, because of the small personal traffic, it was not possible to estimate the False Positive coefficient, but this is not a problem, since the systems under test use standard methods for evaluating spam and the probability of normal email getting into spam is very small.
')
The server connectivity for analysis was as follows:
The main relay accepted all incoming connections and performed their initial analysis by querying DNSBL lists, verifying the compliance of the RFC session (FastBL), then redirecting the letters further to the servers with the tested products. At once I will say that the requests in the DNSBL zone were only for receiving information about the IP address, but the address was not blocked. Testing was carried out without additional “tuning” of products in the form of overstatement of estimated coefficients, i.e. "As is".
Due to the fact that the systems under test have different methods for testing letters, the products were updated according to the following scheme:
"Apache Spamassassin" - sa-update once a day
"Kaspersky Antispam" - every 3 minutes
Yandex Spamooborona - every 20 minutes
The specified time intervals are due to the possible frequency of new updates and recommendations of the developers.
Each of the products has its own characteristics of testing email content:
Kaspersky Anti-Spam uses offline testing, regularly updating its local databases, plus the ability to connect dnsbl sheets.
Yandex Spam Defense uses online-testing technology, constantly working with its central server, as well as updating its local databases as needed, while also having the ability to connect dnsbl sheets.
Apache Spamassassin uses offline data processing, as well as online services of DNSBL, Razor, Pyzor, DKIM, SPF lists.
SA and KAS use fork () to process each letter, and SO, in turn, uses Threads, which is much more economical in terms of memory consumption. At the same time, SA uses preforked processes, limiting the likelihood of memory overruns, and KAS forks as needed, without exceeding the level of filtering processes above the limit specified in the configuration file.
Approximate memory consumption for each process:
SA ~ 40 MB
KAS ~ 30 MB
SO ~ 90 MB
Below are the results table with comments.
Abbreviations used in the tables:
PS - Passed (number of missed letters)
BL - Blocked (the number of blocked letters defined as SPAM)
FN - FalseNegative (The number of emails identified as good but being spam)
FP - FalsePositive (The number of letters defined as SPAM, but not such).
| Date: 04/02/2009. Count: 10291 | PS | BL | Fn | FP |
| Spamooborona | 56 | 10235 | 42 | 0 |
| SpamAssassin | 887 | 9406 | 873 | 0 |
| Kaspersky Antispam | 277 | 10014 | 264 | one |
| bl.spamcop.net | 5107 | 5184 | 5093 | 0 |
| cbl.abuseat.org | 2353 | 7938 | 2339 | 0 |
| dnsbl.sorbs.net | 5732 | 4559 | 5718 | 0 |
| dul.nsbl.sorbs.net | 7773 | 2518 | 7759 | 0 |
| dul.ru | 10255 | 36 | 10241 | 0 |
| Fastbl | 89 | 10202 | 75 | 0 |
| sbl-xbl.spamhaus.org | 2336 | 7955 | 2322 | 0 |
| zen.spamhaus.org | 395 | 9896 | 381 | 0 |
The first day of testing began with a strange breakdown of the anti-spam protection of the Kaspersky Antispam product, and therefore KAS missed more letters than expected. The same day showed the weakness of the separate work of dnsbl lists and SpamAssassin against Russian spam. When testing, I specifically sent 4 letters with quoting of one of the spam emails with word mixing to the test server. Kaspersky in connection with contextual content analysis sent a valid letter signed by DKIM from gmail.com to SPAM. On the one hand, the content of the letter was indeed spam, but, in turn, the letter was rated [SPAM] instead of [Possible Spam]. Taking into account that this letter could be forwarded to the system administrator to analyze the contents of the headers, KAS received 1 FP.
| Date: 04/03/2009 Count: 6357 | PS | BL | Fn | FP |
| Spamooborona | 61 | 6296 | 31 | 0 |
| SpamAssassin | 780 | 5579 | 750 | 0 |
| Kaspersky Antispam | 65 | 6292 | 35 | 0 |
| bl.spamcop.net | 3455 | 2902 | 3425 | 0 |
| cbl.abuseat.org | 1571 | 4786 | 1541 | 0 |
| dnsbl.sorbs.net | 3759 | 2598 | 3729 | 0 |
| dul.nsbl.sorbs.net | 4801 | 1556 | 4771 | 0 |
| dul.ru | 6331 | 26 | 6301 | 0 |
| Fastbl | 77 | 6280 | 47 | 0 |
| sbl-xbl.spamhaus.org | 1557 | 4800 | 1527 | 0 |
| zen.spamhaus.org | 325 | 6032 | 295 | 0 |
On the second day of testing, Spamooborona and Kaspersky Antispam leveled their positions.
| Date: 04/05/2009. Count: 7025 | PS | BL | Fn | FP |
| Spamooborona | 59 | 6966 | 39 | 0 |
| SpamAssassin | 1291 | 5739 | 1271 | 0 |
| Kaspersky Antispam | 29 | 6996 | 9 | 0 |
| bl.spamcop.net | 4170 | 2855 | 4150 | 0 |
| cbl.abuseat.org | 2031 | 4994 | 2011 | 0 |
| dnsbl.sorbs.net | 4424 | 2601 | 4404 | 0 |
| dul.nsbl.sorbs.net | 5180 | 1845 | 5160 | 0 |
| dul.ru | 6986 | 39 | 6966 | 0 |
| Fastbl | 42 | 6983 | 22 | 0 |
| sbl-xbl.spamhaus.org | 2018 | 5007 | 1998 | 0 |
| zen.spamhaus.org | 368 | 6657 | 348 | 0 |
On the third and fourth day of testing (weekends), Spamooborona’s protection was worn out a little because of a sharp surge in single messages. Since the data on the constituent components of letters from Yandex Spamooborona are processed online, it is likely that there will be misses of messages that have not had frequent repetitions. Kaspersky Antispam, in turn, showed the advantages of its offline rating system.
| Date: 04/06/2009. Count: 9963 | PS | BL | Fn | FP |
| Spamooborona | 53 | 9906 | 33 | 0 |
| SpamAssassin | 1506 | 8459 | 1486 | 0 |
| Kaspersky Antispam | 125 | 9837 | 105 | 0 |
| bl.spamcop.net | 7042 | 2921 | 7022 | 0 |
| cbl.abuseat.org | 2562 | 7401 | 2542 | 0 |
| dnsbl.sorbs.net | 6420 | 3543 | 6400 | 0 |
| dul.nsbl.sorbs.net | 7561 | 2402 | 7541 | 0 |
| dul.ru | 9907 | 56 | 9887 | 0 |
| Fastbl | 68 | 9895 | 48 | 0 |
| sbl-xbl.spamhaus.org | 2549 | 7414 | 2529 | 0 |
| zen.spamhaus.org | 308 | 9655 | 288 | 0 |
On the fifth day, there were no special surprises, except for an increase in the number of breakouts in Kaspersky Antispam.
| Date: 04/07/2009. Count: 10923 | PS | BL | Fn | FP |
| Spamooborona | 88 | 10832 | 48 | one |
| SpamAssassin | 1418 | 9503 | 1377 | 0 |
| Kaspersky Antispam | 190 | 10727 | 149 | 0 |
| bl.spamcop.net | 6405 | 4518 | 6364 | 0 |
| cbl.abuseat.org | 2651 | 8272 | 2610 | 0 |
| dnsbl.sorbs.net | 6478 | 4445 | 6437 | 0 |
| dul.nsbl.sorbs.net | 8237 | 2686 | 8196 | 0 |
| dul.ru | 10877 | 46 | 10836 | 0 |
| Fastbl | 103 | 10820 | 62 | 0 |
| sbl-xbl.spamhaus.org | 2633 | 8290 | 2592 | 0 |
| zen.spamhaus.org | 293 | 10630 | 252 | 0 |
On the sixth day, Spamooborona grabbed FP, blocking a valid newsletter with subscribe.newsland.ru. On all days of testing, quite a large number of NDRs came with reports about non-delivery of spam messages, but all NDRs were filtered by products like SPAM and did not deal with this. Although this is not true.
| Total. Count: 44552 | PS | BL | Fn | FP |
| Spamooborona | 317 | 44235 | 193 | one |
| SpamAssassin | 5882 | 38686 | 5757 | 0 |
| Kaspersky Antispam | 686 | 43866 | 562 | one |
| bl.spamcop.net | 26178 | 18374 | 26053 | 0 |
| cbl.abuseat.org | 11168 | 33384 | 11043 | 0 |
| dnsbl.sorbs.net | 26812 | 17740 | 26687 | 0 |
| dul.nsbl.sorbs.net | 33551 | 11001 | 33426 | 0 |
| dul.ru | 44353 | 199 | 44228 | 0 |
| Fastbl | 379 | 44173 | 254 | 0 |
| sbl-xbl.spamhaus.org | 11093 | 33459 | 10968 | 0 |
| zen.spamhaus.org | 1689 | 42863 | 1564 | 0 |
At the end of all tests, 125 absolutely valid letters were allocated from the total volume of letters (44552 letters), on the basis of which the parameters FalseNegative and FalsePositive were calculated. If we exclude the first day of testing, then we see how commercial products go hand in hand when analyzing spam. Spamassassin is still designed for the analysis of foreign spam and often misses letters due to the lack of content normalization. Commercial products lead letters to a particular type. For example, the method used by spammers to insert extra characters in words like: “PAA, S.Y., L = KI,” and also replacing Russian letters with similar English letters is completely ineffective against normalization, in which the distorted the word will still turn into “mailings” and will fall under contextual analysis, adding for each such word a certain amount of points to the entire letter. In turn, SpamAssassin quite well distinguishes foreign spam of the type “Medical, Viagra, Cialis, Enlargement”, and also well filters “bayes poisoning” context analyzers.
Concerning dnsbl-lists the opinion has developed ambiguous. On the one hand, the popularity of public dnsbl is very high, and they can provide protection against spam to a certain extent. But, on the other hand, dnsbl lists cannot be used as a panacea, since there are still FPs when working with valid domains. As for checking incoming connections by RFC (FastBL), not a single FP happened during testing and the level of filtering is comparable to commercial products. But that's another story. :)
Well, and finally, I decided to tabulate the variants of events in the event that the context analyzers worked in conjunction with DNSBL lists. As expected, I got 100% effective spam filtering even when using a foreign Apache SpamAssassin product.
| Total Count: 44552 | PS | BL | Fn | FP |
| bl.spamcop.net + so | 124 | 44243 | 184 | one |
| bl.spamcop.net + sa | 125 | 38702 | 5725 | 0 |
| bl.spamcop.net + kas | 124 | 44050 | 377 | one |
| cbl.abuseat.org + so | 124 | 44266 | 161 | one |
| cbl.abuseat.org + sa | 125 | 40541 | 3886 | 0 |
| cbl.abuseat.org + kas | 124 | 44264 | 163 | one |
| dnsbl.sorbs.net + so | 124 | 44258 | 169 | one |
| dnsbl.sorbs.net + sa | 125 | 39832 | 4595 | 0 |
| dnsbl.sorbs.net + kas | 124 | 44068 | 359 | one |
| dul.nsbl.sorbs.net + so | 124 | 44247 | 180 | one |
| dul.nsbl.sorbs.net + sa | 125 | 39398 | 5029 | 0 |
| dul.nsbl.sorbs.net + kas | 124 | 44013 | 414 | one |
| dul.ru + so | 124 | 44236 | 191 | one |
| dul.ru + sa | 125 | 38714 | 5713 | 0 |
| dul.ru + kas | 124 | 43872 | 555 | one |
| FastBL + so | 124 | 44413 | 14 | one |
| FastBL + sa | 125 | 44374 | 53 | 0 |
| FastBL + kas | 124 | 44412 | 15 | one |
| sbl-xbl.spamhaus.org + so | 124 | 44268 | 159 | one |
| sbl-xbl.spamhaus.org + sa | 125 | 40519 | 3908 | 0 |
| sbl-xbl.spamhaus.org + kas | 124 | 44265 | 162 | one |
| zen.spamhaus.org + so | 124 | 44309 | 118 | one |
| zen.spamhaus.org + sa | 125 | 43747 | 680 | 0 |
| zen.spamhaus.org + kas | 124 | 44387 | 40 | one |
Now about the saddest thing in this informative story about anti-spam - about setting up and licensing commercial products.
Despite the almost flawless core of products, the outer wrapper is very unsuccessful and inconvenient. Personally, I expected more professionalism from the developers of such products.
So, a few "spoons of tar in a barrel of honey."
Both products are focused on installation on the FreeBSD 6.2 system, which has long been outdated in terms of security, as well as the product versions used in the release (I had to use shaman compat6x).
Kaspersky antispam contains perl 5.6.2 in its distribution, as well as some of the specific perl modules. The KAS administration console uses thttpd and system harness in the form of pearl barley CGI scripts. Of course, it looks beautiful, but, in my opinion, not very informative, although it has filter schedules. It is possible to create user groups with different filtering methods, there are white / black lists - both users and ip addresses. Unfortunately, I did not find the ability to use external databases of users and groups in the administrator’s web console (perhaps buried somewhere in console utilities). With licensing, it is also not entirely clear; formally, I have nowhere found a quantitative unit by which per-user licensing is assessed. In a temporary license, the specified processing threshold of 250 megabytes actually ranges from 250 to 499 megabytes. Product licensing is based on the license file obtained upon purchase. The system supports the addition and installation of multiple licenses. Well, my biggest “fi” towards KAS developers is the method of installing the milter filter in the sendmail.cf configuration file.
Guys!!! Why do you rule the WORKING COMPUTER CONFIG, which, with the FIRST update, will cancel all the changes made?
The script of adding a filter to the config upon closer inspection has the same-hidden flag, which allows you to specify sendmail.mc to inject the lines that call the filter, but this flag is not called from the MTA-config.pl configuration script
All KAS processes run under the user mailflt3, which has its own directory for / usr / local / ap-mailfilter3. Startup scripts use the old service startup mechanism, which is not controlled from /etc/rc.conf.
Yandex Spamooborona also surprised me. The configurator is written in DIALOG, I didn’t expect this at installation. The branches of the configurator are very "razlapistye" and very easy to get lost there. Most of the settings are already preset, but it is better to go through all the items in the menu and set the parameters you need. SO has the ability to work with plaintext files, LDAP and judging by the pieces of SQL code in the config, it also knows MySQL. After I set up the work of SO, one person asked me: “I just heard reviews from some anti-spam vendors that supposedly spam defense was terribly difficult to set up and no one who bought direct support from Yandex couldn’t get it. Or are you the only one rare, or someone lying somewhere. ”
In reality, setting up with plaintext files is not so complicated, and, in principle, completely transparent. But it seems to me that the main configuration problems are still related to LDAP and MySQL. Licensing policy is also unusual. To protect against spam, you must either manually or automatically register all email addresses that the system will protect. Because it is really uncomfortable in a dynamically growing network, it makes you wonder. Per-user licensing is based on this list of users. I can’t say what will happen if the list of users increases the maximum level specified in the license, but it seems to me that this is not entirely correct. In my organization there are about 30 domains, 600 users and about 50 groups. Given that each user can have addresses from two domains (for example, alias), I will have to buy an almost unlimited license for the normal operation of my company. A separate article is the licensing key. The key is generated from two files: spam.ini (the main config of the filter) and domains (the list of protected domains). These two files are sent to the SO web server “manually” and, after filling in the necessary information in the web form, the server generates a key. The key is saved to the so.key file and placed in the directory where the other SO settings are located. And God forbid you to fix at least one bit in the spam.ini and domains files - the whole registration procedure will have to be repeated, otherwise the filter will not work. A good plus for novice administrators is the Russification of the SO configuration interface.
Describing the configuration and operation of SpamAssassin makes no special sense, since it is installed on the vast majority of mail relays.
Well, in principle, everything seems to be. What I wanted to write and say - wrote and explained.
Doubts about the bias of testing, I, of course, accept from anyone. If you think that this testing was biased and you can get other results without seriously tightening the screws, you can send me a personal configuration file of the product you are interested in, and I can put a couple more servers with the existing and your configs, then we will again compare the results.
PS: If there are questions about testing, then Kaspersky Lab wrote a wonderful document: www.spamtest.ru/document.html?context=15948&pubid=16638 , in which you can find all the recommendations for tests. In my tests, they were observed as accurately as possible, except for the testing time, all the same 2004 document.
ZZY: Ready to catch the stones in your garden.
ABORCHE 2009
SpamAssassin config:
bayes_auto_learn 1
bayes_ignore_header X-Bogosity
bayes_ignore_header X-Spam-Flag
bayes_ignore_header X-Spam-Status
loadplugin Mail :: SpamAssassin :: Plugin :: AWL
loadplugin Mail :: SpamAssassin :: Plugin :: AutoLearnThreshold
loadplugin Mail :: SpamAssassin :: Plugin :: Bayes
loadplugin Mail :: SpamAssassin :: Plugin :: BodyEval
loadplugin Mail :: SpamAssassin :: Plugin :: Check
loadplugin Mail :: SpamAssassin :: Plugin :: DKIM
loadplugin Mail :: SpamAssassin :: Plugin :: DNSEval
loadplugin Mail :: SpamAssassin :: Plugin :: HTMLEval
loadplugin Mail :: SpamAssassin :: Plugin :: HTTPSMismatch
loadplugin Mail :: SpamAssassin :: Plugin :: Hashcash
loadplugin Mail :: SpamAssassin :: Plugin :: HeaderEval
loadplugin Mail :: SpamAssassin :: Plugin :: ImageInfo
loadplugin Mail :: SpamAssassin :: Plugin :: MIMEEval
loadplugin Mail :: SpamAssassin :: Plugin :: MIMEHeader
loadplugin Mail :: SpamAssassin :: Plugin :: Pyzor
loadplugin Mail :: SpamAssassin :: Plugin :: Razor2
loadplugin Mail :: SpamAssassin :: Plugin :: RelayEval
loadplugin Mail :: SpamAssassin :: Plugin :: ReplaceTags
loadplugin Mail :: SpamAssassin :: Plugin :: Rule2XSBody
loadplugin Mail :: SpamAssassin :: Plugin :: SPF
loadplugin Mail :: SpamAssassin :: Plugin :: SpamCop
loadplugin Mail :: SpamAssassin :: Plugin :: URIDNSBL
loadplugin Mail :: SpamAssassin :: Plugin :: URIDetail
loadplugin Mail :: SpamAssassin :: Plugin :: URIEval
loadplugin Mail :: SpamAssassin :: Plugin :: VBounce
loadplugin Mail :: SpamAssassin :: Plugin :: WLBLEval
loadplugin Mail :: SpamAssassin :: Plugin :: WhiteListSubject
report_safe 0
rewrite_header Subject ***** SPAM *****
use_bayes 1
Source: https://habr.com/ru/post/56779/
All Articles