Significantly more mails quarantined with 8.200 SMTP proxy

mlenk, I disagree - this catches no new spam.  It only blocks opt-in emails.

It is short-sighted to hard-set the Proxy to block bulk emails - admins will not be happy that there's no opportunity to switch this behavior off.

Please recommend that the developer in charge of this add an appropriate select box on the Anti-Spam tab prior to ending the soft-release of 8.200.

Cheers - Bob

Bob's right - all the extra items I'm seeing blocked are opt-in bulk emails, as opposed to true spam.  I agree that an additional option to block bulk email en masse would be ideal.  For now, I've just added exceptions for all the bulk email domains I want to receive.  This is easy to do for a small number of users but I can imagine could become a headache for a large user base.  Signing up for bulk emails is commonplace for industry newsletters, articles, etc., so I could imagine admins getting a lot of phone calls from users who have intentionally signed up for some mailing list or other, but are not receiving the emails.

Btw, even Microsoft Security Bulletins are getting blocked at the moment...

If you don't want to block bulk mail, then configure your SMTP proxy to quarantine 'Confirmed Spam' only. The 'Spam' setting maps to the 'Bulk' classification from Commtouch, which apparently detects, well, Bulk mail.

Does this solve your problem?

Regards,
mlenk

Sorry, Micha, that's not acceptable for my customers.  I always set to reject "Confirmed Spam" at SMTP time, and choose to quarantine "spam" in the 'Spam filter' section.  Or, are you telling me that "Confirmed Spam" has a different meaning in those two different sections in V8.2?

Cheers - Bob

Hello Bob

In my eyes the categorization of these mails is absolutely correct. The issue may lay in the way how Astaro implemented Commtouch. If I remember right, Commtouch itself has around 4 or 5 different categorization levels, where "bulk" is only one of them, and Astaro has them grouped into the 2 levels "spam" and "confirmed" spam, which may cause such unwanted behaviour in a few scenarios due granularity of the chooseable handling of these levels.

Usually if other Antispamoptions as SPF, RDNS/HELO, RBLs etc are active, there are not much "real" spams left for Commtouch engine, and usually only bulk mails as Newsletters catched into quarantine by CT. From this view you also may set the "Reject at SMTP Time" to "Confirmed Spam" and Spam Filter "Spam Action" to "OFF" or "Warn" and "Confirmed Spam Action" to "Quarantine" or "Blackhole" - whatever fit better your needs...With this setting most Newsletters and Bulk Mails should pass ASG without issues [;)]

I already had Confirmed Spam being rejected at SMTP time, and as an experiment have just turned the "Spam action" option under Spam Filter to "Off" instead of "Spam", leaving the "Confirmed Spam action" set to Quarantine as before.  I'll see what effect this has.

Even so, as Bob points out this implies a different meaning for these options that in the prior version.  Does the "Spam" option *only* include bulk mail?  If so, maybe having a "Bulk Mail action" setting would be more accurate.  If it encompasses bulk mail as well as probably (but unconfirmed) spam, then it would seem we have one config option in 8.200 where we should really have two; one of unconfirmed spam and another for bulk mail.

Yep, sounds like we need another option or 2 for configuring the new anti-spam engine...

Sascha, that's exactly my point: one developer decided to use the more-granular settings, but another didn't change WebAdmin to account for that fact.  That this likely is miscommunication is further indicated by the lack of documentation about this new behavior.

No, this isn't a "bug" - it is something worse - a conceptual error.

None of my clients with Mail Security will be upgraded to V8 until this issue is resolved.  I figure if I wait, I won't have to give my time away for free to compensate for this "oops!" by Astaro.

Cheers - Bob
PS I'm just being frank.  I think the Astaro development team is one of the best around.  I just don't believe that this is a minor issue to our customers.

Hi BAlfson,

one developer decided to use the more-granular settings, but another didn't change WebAdmin to account for that fact.

No, I am sorry, but that assertion is only your wild guess.

The classification categories provided by Commtouch essentially didn't change by this update. There are no additional more-granular settings for Commtouch introduced that could be missing in WebAdmin. To be sure I've just checked back with Commtouch whether the meaning of 'Bulk' classifications might have changed by our Commtouch software update. It didn't. Here is their answer:

 The meaning of 'Bulk' classification has not changed in CTASD version 3.x or 4.x. 'Bulk' classification means that the message is considered unsolicited message that is received in large quantities within a given period of time. The message is also identified to have spam patterns, but it did not originate from a known spam source.

For your case with the experienced increase in false positives after the upgrade, Commtouch asks us to provide samples to investigate the reasons. For this purpose they need the RefIDs of the messages that were falsely cassified as 'Bulk' in the last 14 days (older RefIDs can't be investigated anymore). You can find the RefID as a separate header in each processed email, or even in the smtp.log.

In case anybody suffers from false positives, please provide the respective smtp.log and the RefID, and we will forward the needed information to Commtouch.

Regards,
mlenk