On 1 Mar 2019, at 9:21, Thomas Seilund wrote:
On 01/03/2019 08.39, Andrey Repin wrote:
Greetings, Thomas Seilund!
smtp inet n - n
- - smtpd -o
content_filter=spamfilter -o
receive_override_options=no_address_mappings
spamfilter unix - n n
- - pipe
flags=Rq user=vmail argv=/usr/bin/spamfilter.sh -oi -f ${sender}
${recipient}
Apparently, the reason you're filtering outbound mail is that you are
having local users submit mail on port 25, using the same configuration
of the smtpd daemon that is used for mail coming in from the Internet.
Best practice is to have port 587 "submission" (plaintext with STARTTLS
support) and/or port 465 "smtps" ("wrappermode" TLS) transports, using
smtpd with settings suited only for initial message submission. By
splitting initial message submission from inbound message transport, you
can make both services better and safer. This includes the options to
not scan mail from your own users OR to scan it differently so that you
don't create useless and unwanted directories for random remote
recipients.
Furthermore, I have this script in /usr/bin/spamfilter:
#!/bin/bash
SENDMAIL=/usr/sbin/sendmail
SPAMASSASSIN=/usr/bin/spamc
RECEIVER=`echo $4 | tr '[:upper:]' '[:lower:]'`
${SPAMASSASSIN} -u $RECEIVER | ${SENDMAIL} "$@"
exit $?
That's almost the simplest shim possible between Postfix and
SpamAssassin. To make it not try to use per-user configurations, just
remove the "-u $RECEIVER" on the 5th line. That would be an appropriate
script for use as the pipe target of an additional transport used as the
content_filter of a submission or smtps service.
Finally, this is the parameters I have for SA in file
/etc/sysconfig/spamassassin:
SPAMDOPTIONS="--daemonize --create-prefs --max-children=5
--helper-home-dir=/mnt/ebs01/vmail/%d/%l/SpamAssassin
--username=vmail
--nouser-config
--virtual-config-dir=/mnt/ebs01/vmail/%d/%l/SpamAssassin"
export PYTHONPATH=/usr/lib/python2.6/site-packages
Easiest way to stop creating the unwanted directories: remove
"--create-prefs" there. It won't solve the root cause, but it will fix
the symptom.
If your users are not using personal spamassasin lists, you can just
tell it
to use same user for all server works.
I assume I do use personal SA lists as I run like this:
-- Each user has a LearnAsSpam and LearnAsHam mailfolder.
-- I instruct users to move mails that SA falsely did not tag as spam
to the LearnAsSpam folder
-- I instruct users to have at least 10 not spam messages in
LearnAsHam
-- Once a day for each user I clear the bayes files and rebuild bayes
files with:
-- sudo -u vmail sa-learn --username vmail --spam --dbpath
$SUBDIR/SpamAssassin $SUBDIR/mail/LearnAsSpam/cur
-- sudo -u vmail sa-learn --username vmail --ham --dbpath
$SUBDIR/SpamAssassin $SUBDIR/mail/LearnAsHam/cur
-- $SUBDIR evaluates to each users vmail directory, ie.
/mnt/ebs01/vmail/netmaster.dk/tps
If there is a better way to keep bayes upto date I would be happy to
know.
Your users are unlikely to be actually using Bayes if you're clearing
the databases daily. SA Bayes will not score messages AT ALL if its
database doesn't have enough messages learned to have a statistically
valid sample size, set by default to 200 each of spam and ham. That's
high enough to avoid most cases of Bayes being actively bad, but Bayes
doesn't really work *well* until it has about a thousand messages
analyzed.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
