Wizard IT Products

Do you guys use/don't use Plesk's SPF, DomainKeys, RBLs, SpamAssassin, Submission port for antispam? Why?

For example we use bogusmx.rfc-ignorant.org, dsn.rfc-ignorant.org and sbl.spamhaus.org for RBL block. I found that a pair of our clients IPs are in Spamhaus's pbl list (and as you know Plesk doesn't honor smtp-auth for rbl checks), so zen.spamhaus.org isn't an option. For SPF we use "include:spf.trusted-forwarder.org", "a/24 mx/24 ptr". We have a problems with that, because from time to time clients use their ISP's SMTP server with some public e-mail service addresses. We're looking intro disabling SPF check in near future - more headache than real help. Just need of one last drop/client call. SpamAssassin alone is very resource hungry and easily tricked by spammers last months, so it's only good as secondary level check. And we don't use Submission port for known reasons.

You asked a lot in those couple of lines

1) Do you guys use/don't use Plesk's SPF, DomainKeys, RBLs, SpamAssassin, Submission port for antispam?

SPF, DomainKeys etc.. have been a lot more difficult in the real world. Many email operators do not have access or the skills to do this correctly, and our systems already have simpler ways from a 'Spam' perspective to catch most of the problem ones.. It is still low on our totem pole, unless we see that there is a distinct need. We don't involve ourselves with SpamAssassin. There is already a SpamAssassin module for Plesk. And the submission port? This should only accept SMTP authenticated sessions, so it shouldn't be a spam problem, and this goes beyond the scope of the MagicSpam module.

2) For example we use bogusmx.rfc-ignorant.org, dsn.rfc-ignorant.org and sbl.spamhaus.org

The problem is that you are using it at the filtering level. AFTER the connection is severed, as part of your SpamAssassin module right? At that point in the email processing you do not have the smtp-auth information available any more. That's one of the great advantages of MagicSpam. We do our checks DURING SMTP, meaning we do have access to that information, meaning that if your clients are on say.. RATS-DYNA, it won't affect their ability to send email out your email server. Not like the problem you were reporting with the SA module. I think that basically you are saying that all the things MagicSpam is doing works better than before. And yes, it is a great performance boost that we stop most of the attackers BEFORE they even get to your Spam Assassin module.

magicspam wrote:The problem is that you are using it at the filtering level. AFTER the connection is severed, as part of your SpamAssassin module right? At that point in the email processing you do not have the smtp-auth information available any more.

We use it as Plesk's RBL (DNSBL) for qmail (smtp_psa/rblsmtpd). Problem is that it's implemented that way it doesn't honor smtp_auth. Maybe this is fixed in latest releases, but for 8.2.1 it's not.