Using spamassassin to block mails during SMTP transaction

Hi everybody,

(my english may be poor, please have mercy)

I am using Virtualmin GPL on Debian 7 and I try to optimize my spam filtering methods.

At the moment, I am filtering incoming mails with some RBL (especially spamhaus) to block spams. I did this by editing the “smtpd_recipient_restrictions” parameter in /etc/postfix/main.cf.

I am also using spamassassin to tag the remaining spams (the usual *** Probably Spam *** in the title). I did this with Webmin’s SpamAssassin module (SpamAssassin Mail Filter > Message Modification)

Untill now, this was OK to block enough spams. Unfortunately, it is no longer the case :’(

Thus, I would like to use spamassassin to block spams, preferably BEFORE they are accepted by the server, at SMTP transaction level. I tried to use the “header check” function of Postfix to block mails that reached a high spam level. Like this :

# cat /etc/postfix/header_checks
/X-Spam-Level: *{8,}/ REJECT Email rejected. Looks like spam.

But it is not working : the messages ares tagged by spamassassin (a lot of information added in the headers) but they nevertheless are accepted by the server.

I noticed that it is possible to delete mails if they are tagged as spam (Virtualmin > domain.com > Server Configuration > Spam and Virus Delivery) but I do not really like that idea of “deleting without warning”, whenever a mail is accepted by the server, i feel like I have to deliver it somewhere. That is why I would like to block mails during the SMTP transaction. Is it possible ?

Since this topic has been queued for moderation for 5 days, it never had a chance to be on top of page 1.

Let’s try a little bump before it reaches page 2 :slight_smile:

I don’t think what you’re trying to do is possible like that. SpamAssassin is called only after the mail is received and the SMTP session ends, during the invocation of Procmail, so the “X-Spam-Level” gets added only after Postfix had a chance to check the headers.

What issues are you seeing exactly? How is Spamhaus+SpamAssassin no longer sufficient to block spam?

If you wish to mark spam and move it to a different folder (instead of deleting it), there’s an option to do that in Virtualmin’s email setup.

How exactly would rejecting the mail after being processed by SpamAssassin improve its spam detection rate? What you’re describing would merely be a different way of dealing with detected spam as far as I see it.

Hello Locutus, thank you for your reply.

I don’t think what you’re trying to do is possible like that. SpamAssassin is called only after the mail is received and the SMTP session ends, during the invocation of Procmail, so the “X-Spam-Level” gets added only after Postfix had a chance to check the headers.

Yep, the way the email server is installed implies that spamassassin is processing the mails after they went trough Postfix, that’s the whole point.

After googleing for a while, I still believe it should be possible to use spamassassin the way I would like (see here for example : http://wiki.apache.org/spamassassin/IntegratePostfixViaSpampd). Though, I’d like to make sure this will not interfere at any point with Virtualmin.

What issues are you seeing exactly? How is Spamhaus+SpamAssassin no longer sufficient to block spam?

Spamhaus does a great job. It helps me in blocking thousands of spams every day. Unfortunately, it appears that it is not enough anymore: over the weeks/months/years, the amount of spam reaching the mailboxes grows inexorably. I tried to add even more RBLs, but it doesn’t help much.

If you wish to mark spam and move it to a different folder (instead of deleting it), there’s an option to do that in Virtualmin’s email setup.

Yes, i saw that. That’s OK if users check their mailboxes with IMAP. Unfortunatly, I have several users using POP, that’s why can’t deliver emails in another folder than the inbox.

How exactly would rejecting the mail after being processed by SpamAssassin improve its spam detection rate? What you’re describing would merely be a different way of dealing with detected spam as far as I see it.

Considering that (1) I have to deliver accepted mails (I don’t like the idea of deleting mails without notifying the sender) and (2) I have to deliver the mails in the inboxes (I can’t use the “move to other folder” feature), the only option I have is to deliver mails normaly once accepted by the MTA. As a result, the only way I can currently use spamassassin is to tag the mails titles. It’s a little sad to use spamassassin just to do that … I would like to use it (and it’s fantastic scoring system) to block even more spams … the earliest possible and with notification to the sender.

Howdy,

Yeah, as Locutus mentioned, what you’re looking to do is indeed possible if you set it up manually.

You’d lose the ability to configure SpamAssassin related settings from within Virtualmin, but if you just wanted to enable SpamAssassin for all domains, and don’t mind configuring that manually, that would certainly work.

You can tell Virtualmin to stop using SpamAssassin by going into System Settings -> Features and Plugins, and there you can disable the “Spam Filtering” feature.

Once that is done, Virtualmin will no longer attempt to configure procmail to perform spam filtering, and you can instead manually set that up elsewhere.

-Eric

Be aware that SpamAssassin can produce false positives, even if rarely. So to prevent your users from losing legitimate mail, you’d rather want to just have SpamAssassin tag the mails it detected, and have your users sort them out in their email clients. That’s easily done, since probably all email clients offer functions to post-process mails based on subject etc.

That way your can still auto-delete detected spam if they want to, and then it’s their own responsibility if they lose legitimate mail.

To introduce SpamAssassin into the SMTP dialog, you’d definitely need to do manual steps, since Virtualmin is not prepared to do that. I can’t say how that would interfere with its operation, but I’d suggest to test such modifications on an experimental system first.

In any case, doing that would as I said not improve your spam detection rate, but only deal with detected already spam in a different way.

Thank both of you for all those informations. I expected that I wouldn’t be able to use spamassassin along with Virtualmin anymore. That’s OK to me, I’m glad that the only thing I have to do is deactivate the Spam Filtering feature … let’s go for some do-it-yourself :slight_smile:

Be aware that SpamAssassin can produce false positives, even if rarely. So to prevent your users from losing legitimate mail, you’d rather want to just have SpamAssassin tag the mails it detected, and have your users sort them out in their email clients. That’s easily done, since probably all email clients offer functions to post-process mails based on subject etc. That way your can still auto-delete detected spam if they want to, and then it’s their own responsibility if they lose legitimate mail.

Yep, that’s exactly the way I’m currently doing it … but the point is that very few poeple want to auto-delete mails, precisly because there might be some legitimate mails tagued as spam. As a result, those poeple do check their spams and this is very time-consuming. Many of my users with heavily spamed mailboxes told me that they would prefer not recieve all those spams, provided that rare false positives would trigger a notification to the sender.

Okay, that good. Just be aware that there can be situations where the “sender” is not able to react to non-delivery reports, e.g. when it’s a web software. Confirmation mails when subscribing to forums etc. sometimes get flagged as spam, and in your case they’d be rejected. I doubt the forum reacts to that and informs the admin. :wink:

(1) I have to deliver accepted mails
Yes, you are even required by EU law if you or your customers are from an EU country. Deleting accepted mails would be a criminal offense against privacy of correspondence unless the customer asked you to do so or you asked for customer’s permission.
Whereas automatically processing, tagging or redirecting in a different folder is legal.

Though it sounds like a good idea to reject spam before it is accepted, I have got a concern in addition to the one Locutus mentioned:
Spammers may use such rejected spam to improve their tactics as they directly and quickly learn what spam has been detected as such. Thus, filtering/detecting spam might become even more difficult than it already is in your case.

Have you implemented own/custom filtering rules in SpamAssassin? I found such to be very effective.

On the other hand, I would like to point out that recent jurisdiction in Germany (LG Bonn, 10 Jan 2014, Az. 15 O 189/13) has ruled that Spam folders of business connections have to be searched for false positives daily. Therefore, some lawyers think that rejecting spam before it has been accepted is the safest way (www.openpr.de/news/806160) even though it is the first verdict in such matter and is controversial (hoesmann.eu/lg-bonn-spam-ordner-ist-taeglich-zu-kontrollieren/).

This works well for me :slight_smile:

/^X-Spam-Level: *{10,}.*/ DISCARD