SpamAssassin Confusion

The NodeWorx SpamAssassin configuration setting is misleading, and should be changed.

Enable SpamAssassin. This option will scan all e-mail using the SpamAssassin content filter as the e-mail enters the server. The SMTP connection will be dropped only if the Spam Score is higher than the SMTP Spam Score option below. Otherwise, the e-mail will still be delivered to the recipient.

The setting in NodeWorx is mislabled as “enable spamassassin” this appears to turn on the ability for domains to use SA. When you read the description, you may notice that it does not enable SpamAssassin at all, but enables a spamassassin module of dubious benefit, the in-transaction SMTP scanner. The setting label and/or text should be more clear that it has no bearing on a domain-level spamassassin setting, and "you probably don’t want this, you should enable spamassassin through SiteWorx individually for domains, instead.

A significant problem with enabling this option (because there’s no indication that a user wouldn’t want to) is that the setting will write SA headers in email, even on domains which do not have SA enabled in SiteWorx. If domains are doing external SA checking (such as with Thunderbird, etc.) it can cause conflicts, and they will be unable to disable it (since it’s enabled for the whole server, with no option for a domain to turn it off). And in the case of a domain which DOES want to enable SpamAssassin to check its mail, this has the effect of running SpamAssassin twice for each mail (thus, double the “cost” of the processing).

Please rename the option to something other than “enable spamassassin” and indicate something like “you probably don’t need this” or “only enable this if you know what you’re doing” or similar. The default “Spam Score” set by the dev team is 9999, making it evident that they believe it shouldn’t be enabled.

Is anyone brave enough to reject email during the SMTP transaction? I know my users would be upset if they found out I was doing it. Since it has to get through the DATA phase for SA to work, there’s no savings of bandwidth to process it in-session anyway.

Chris, a lot of what you said is highly opinionated, and not everyone will agree with you.

The setting in NodeWorx is mislabeled as “enable spamassassin” this appears to turn on the ability for domains to use SA. When you read the description, you may notice that it does not enable SpamAssassin at all, but enables a spamassassin module of dubious benefit, the in-transaction SMTP scanner.
“Mislabeled” is a bit harsh. When you read “enable spamassassin” you interpreted it to mean one thing, while in fact it could mean a number of things. That’s why the description is there - to clarify the meaning in this context. I agree that the two words “enable spamassassin” don’t convey much detailed information. We’ll try to come up with a more descriptive few words. Did you have any suggestions?

"you probably don’t want this, you should enable spamassassin through SiteWorx individually for domains, instead.

I agree that the description should mention the option of enabling SpamAssassin in SiteWorx and explain the difference more clearly. Saying “you probably don’t want this” is a pretty sweeping statement, we can probably find a less biased way to describe the feature.

A significant problem with enabling this option (because there’s no indication that a user wouldn’t want to) is that the setting will write SA headers in email, even on domains which do not have SA enabled in SiteWorx. If domains are doing external SA checking (such as with Thunderbird, etc.) it can cause conflicts, and they will be unable to disable it (since it’s enabled for the whole server, with no option for a domain to turn it off).
Yes, this is one reason why you might not want to enable SpamAssassin scanning server wide at the SMTP level.

And in the case of a domain which DOES want to enable SpamAssassin to check its mail, this has the effect of running SpamAssassin twice for each mail (thus, double the “cost” of the processing).
That’s correct. The reason for this double scanning is to guarantee that the user’s spamassassin preferences are used at least once during the scanning. When scanning at the SMTP level, if a message has multiple recipients, there’s no way to know which user’s preferences to load (so it uses the global settings and other defaults). This is another reason you many not want to enable SpamAssassin scanning server wide at the SMTP (NodeWorx) level.

Please rename the option to something other than “enable spamassassin” and indicate something like “you probably don’t need this” or “only enable this if you know what you’re doing” or similar. The default “Spam Score” set by the dev team is 9999, making it evident that they believe it shouldn’t be enabled.
A better name for the option is a good idea, and ideas are welcome. The default setting is also “off” which means the server administrator has to specifically enable it, at which point I hope they would read the description printed right next to the option.

Is anyone brave enough to reject email during the SMTP transaction? I know my users would be upset if they found out I was doing it. Since it has to get through the DATA phase for SA to work, there’s no savings of bandwidth to process it in-session anyway.
A LOT of folks reject mail during the SMTP transaction, be it via virus scanning, RBL checking, or any number of other scanning methods. It could be argued that some RBL checking services are even more error prone than SpamAssassin.

I definitely agree that SpamAssassin scanning at the SMTP level isn’t for everyone. There are advantages and disadvantages, both of which should be considered when deciding to enable it or not. I also agree that the advantages and disadvantages are not immediately clear looking at the option in NodeWorx, and we’ll do a better job of pointing these out to the user.

Thanks for the feedback as always Chris.

Paul

This is what I found how the different settings work:
http://interworx.info/forums/showthread.php?t=420

I’m pretty sure when you enable it server wide you are already scanning two times, even if you don’t have enable spamassassins “on” in the SiteWorx account.

So if you only want to scan once you have to just turn it on in the SiteWorx accounts.

Justin, thanks for posting a link to your other thread, I guess it slipped by my radar before. I’ll reply to your post in a moment.

I’m pretty sure when you enable it server wide you are already scanning two times, even if you don’t have enable spamassassins “on” in the SiteWorx account.

Actually if it’s enabled server wide (in NodeWorx) and not enabled in SiteWorx, the message will only be scanned once. The only catch is, IF the e-mail has more than one recipient, it won’t grab the preferences from SiteWorx, it will only use the global preferences set in NodeWorx. However if there is only one recipient, then it can get the SiteWorx level preferences.

Paul

That was completely not my intention, and I apologize for my tone. You guys have a great product, and I’m one of your biggest fans. Heck, half the reason I file “bug” reports is because I want to help you guys improve.

How about “Enable Extra SpamAssassin Scanning” or “Enable In-Session scanning [advanced]” or “Enable advanced SpamAssassin scanning”

As for the description text

That would be a welcome addition, well put.

Maybe this could go into one of your famous help ?s in the interface. making the info available to the curious (like me!), but not cluttering the text.

Once again, I’m sorry about the tone and the bias. I can only guess that I posted that way because I had a customer get bit by double-SA checking (he runs SA on his own computer, and the server-wide setting added a SA header, which mangled his mail processing)

Edit:
I just read Justin’s thread, and I think that this quote from Paul should be in the description:

That’s the best information I’ve seen so far on why to use the setting. Here’s a question, though. If a good score is 95 (which seems reasonable, when you consider that SpamAssassin marks something as spam at 5), why is the setting prefilled at 9999? The description says it’s to prevent dropping mail, but if you don’t want to drop mail during the SMTP transaction, shouldn’t you just disable [more correctly: not enable] the “enable spamassassin” option (above) instead? What about a default score of 95, and a suggestion to only enable if you want to drop mail in-protocol?

You can enable it in NodeWorx to do regular scanning as well as the dropping the mail. So if you set that to 9999 you wont drop any mail, but all messages coming into the server will be scanned and be given a Spam score.

This does bring another question I’m not sure if I asked before, but kind of goes with the problem your client had. If you do NodeWorx and SiteWorx scan (seperate not SMTP/Nodeworx pulling the SiteWorx preferences, but actually SiteWorx doing a 2nd scan) will the SiteWorx scan mess up the score given in the NodeWorx or will it just override it?

Yes, but this isn’t very useful. If you’re going to scan during the SMTP transaction, you’re using a global configuration (e.g. blocklists). This should really be a binary option (either scan and drop or don’t). Otherwise you run into this problem:

SpamAssassin will write a header for the SMTP transaction, and then will add a second header when run for the SiteWorx account (using customer rules). This is exactly the problem that my customer complained to me about, that there were two SA headers. If we’ve scanned it at the SMTP level and not dropped it, we should not add a SA header. This will allow us to pass along mail that wasn’t “bad enough” to be dropped at the SMTP transaction to the client’s filters to do with as they please. The idea behind an in-transaction filter is to reduce the consumption of resources such as badwidth and processing power. Thus, if mail’s coming from open proxies in China, drop it. This keeps us from having to scan very obvious spam using the client’s more expensive filters.

I just noticed the warning in the config. Flawless victory (again), gentlemen. Thank you.