OK, I have been running qmail-scanner on my server for a few months now and it works ok. OK, more than ok!
But there is a problem and it is pretty big. Qmail-scanner also scans outgoing mails. I can definitly see the advantages in this setup (my customers or abusers couldn't misuse my servers), but it also causes all mail to be added points for being spam. OK, what is causing the spam points? Well, I use both domainkeys and SPF and domainkeys isn't added until after qmail-scanner is completed (at least I think it is added after...) and the SPF-check fails because the local IP I am sending from isn't listed in the SPF TXT, only the server IP:s.
Anyone has any ideas how to get around these issues?
qmail-scanner, outgoing mail, domainkeys and SPF
-
- Forum User
- Posts: 35
- Joined: Thu Jan 08, 2009 4:31 am
- Location: Fort Worth, TX
- Contact:
What you might be able to do is open up a separate port for outgoing mail and have it not hit the qmail-scanner.
I personally suspect that qmail-scanner processing outgoing mail is causing delays that are visible from the client side. The tagging of messages as spam isn't too much of a problem to me as I've refined my SpamAssassin rules and most web based apps that send mail are RFC compliant.
----
I would theorize that it might be possible to open up an additional port for outgoing mail and to route things differently -- perhaps install a second copy of qmail in a different location without the qmail-scanner addition and route things through that install --
I'm providing instructions on how to open up port 5190 (usually for AIM, thus never blocked) as an outgoing SMTP port ... as a starting point.
Read on for an explanation from Scott as to why scanning outgoing mail is good.
Edit /etc/services and add the 3rd and 4th line:
Save and copy your smtp_psa file in /etc/xinetd.d to smtp_psa_5190 then edit and change the first line to:
Then restart xinetd (service xinetd restart)
---
Good information from Scott:
So there is certainly a silver lining to having your outgoing messages scanned also.
It would be -nice- if a future release of qmail-scanner would have an option that differentiated incoming and outgoing and allowed a user to turn off tagging as you've mentioned.
From a purely ignorant standpoint, I have no idea how SPF and DomainKeys work -- I respect that PLESK has added them and figure that there must be a value there. However, I would rather sacrifice them for qmail-scanner as I believe qmail-scanner is more effective.
If only it worked for PLESK 9...
I personally suspect that qmail-scanner processing outgoing mail is causing delays that are visible from the client side. The tagging of messages as spam isn't too much of a problem to me as I've refined my SpamAssassin rules and most web based apps that send mail are RFC compliant.
----
I would theorize that it might be possible to open up an additional port for outgoing mail and to route things differently -- perhaps install a second copy of qmail in a different location without the qmail-scanner addition and route things through that install --
I'm providing instructions on how to open up port 5190 (usually for AIM, thus never blocked) as an outgoing SMTP port ... as a starting point.
Read on for an explanation from Scott as to why scanning outgoing mail is good.
Edit /etc/services and add the 3rd and 4th line:
Code: Select all
smtp 25/tcp mail
smtp 25/udp mail
smtp5190 5190/tcp mail
smtp5190 5190/udp mail
Code: Select all
service smtp5190
---
Good information from Scott:
--Qmail-scanner implements scanning in the queue, rather the mail box. At the time I thought that the .qmail design was better in every way since it let you do settings at the user level rather than system wide. BUT, here was the key... everybody sharing the same bayes and awl dbs created a collective defense. Bayes doesnt work at all until you get up to 200 entries for spam and ham (so 400 messages
*scored*). That lead to the server wide version of Plesk's spamassassin.
Great right? It should be the same right? No. It wasnt ever as good and it drove me nuts for days until I figured out just what was going on. Bayes gets *poisoned* by spammers, and its super easy to do if you're looking down at the inbox level. On top of that bayes expires all the old tokens after 90 days, so priming with a pre-trained bayes DB is only useful for so long. What qmail-scanner was doing that I didn't realize was that it captures bayes and AWL data in *both* directions.
That means every message your users send is getting added to the bayes DB. Now barring that your system is getting used for spam, there basically isnt a better way of training a bayes DB to the highest level of accuracy (this gets crazy accurate over 2000 messages on each side). Thats why it was so much more accurate, it just has the best possible data. Of course in a plesk environment the likelihood of it getting poisoned by outbound mail is pretty high too. So really the most ideal configuration is to use the per-user settings via mysql for anyone that sends a lot of their own mail.
So there is certainly a silver lining to having your outgoing messages scanned also.
It would be -nice- if a future release of qmail-scanner would have an option that differentiated incoming and outgoing and allowed a user to turn off tagging as you've mentioned.
From a purely ignorant standpoint, I have no idea how SPF and DomainKeys work -- I respect that PLESK has added them and figure that there must be a value there. However, I would rather sacrifice them for qmail-scanner as I believe qmail-scanner is more effective.
If only it worked for PLESK 9...