Grzegorz Czapliński --> errata


<--

Postfix with SASL

Setting up Amavisd-new

 
ERRATA
 
Postfix with SASL Authentication over TLS

After the publication several questions were asked and also I came to useful conclusions. Here it goes...

I was asked why not use PAM while authenticating via SASL.
When I was working on the article it was not possible. Also the manpage was misleading stating that PAM option works on Linux and Solaris. According to manpage getpwent option works on all platforms. That is why I chose the latter. I made some tests and PAM authenticaion works fine with saslauthd daemon now.

Moreover it is possible to chroot(1) postfix while working with SASL.
In my article I suggested to edit master.cf file and change it to read like this:

 smtp      inet  n       n       n       -       -       smtpd

Don't do that! Leave it as it was. The whole secret lies in SASL installation.

After last cvsup of ports I have noticed some changes. There are now three SASL ports - cyrus-sasl, cyrus-sasl2 and cyrus-sasl2-saslauthd.

(I decided no to go with the details regarding old layout of ports, sorry.)

Before you make(1) anything go to cyrus-sasl2 and cyrus-sasl2-saslauthd; and apply these patches as follows:

(Get the patches from here.) Go to /usr/ports/security/cyrus-sasl2 and apply:
# patch -p < cyrus-sasl2.patch

Go to /usr/ports/security/cyrus-sasl2-saslauthd
# patch -p < cyrus-sasl2-saslauthd.patch

then chdir to /usr/ports/security/cyrus-sasl2-saslauthd/files
# patch -p < saslauthd.sh.patch

Go back to /usr/ports/security/cyrus-sasl2-saslauthd and now type:
# make all install

I assume you have not changed the queue_directory variable in main.cf file. It is essential. queue_directory is the place where Postfix chroots. My patches force SASL to use /var/spool/postfix/saslauthd as a place to keep pid file and its socket. This way, even when postfix is chrooted, it can see what's below queue_directory. The config has been tested!

 

Setting up Amavisd-new + Sophos for Postfix

In that article a few errors were spotted...

In the section Bayesian Learning, I presented a script for Bayesian learning method. For mbox format the correct parameters are:
/usr/bin/sa-learn --spam -p /var/amavis/.spamassassin/user_prefs --mbox
/usr/bin/sa-learn --ham -p /var/amavis/.spamassassin/user_prefs --mbox

In the section Additional Notes, there is a paragraph regarding MkS_Vir instalation and configuration.
For a test run, mksd should be called with a group vscan. This is essential as all your mails will hang in the queue forever.
In other words, a line that reads:
# mksd -u mks -g mks scan 4
should be changed to:
# mksd -u mks -g mks,vscan 4

The script presented later on is OK.
Credits for spotting that go to: Krzysztof Stryjek.

I have also received an emial regarding SpamAssassin configuration. I will quote it here as it goes.
I was reading quickly through your september article [0] and noticed that you mention that in order to whitelist local messages you need a rule in your SA config that looks like:

header LOCAL_RCVD Received =~ /\S+\.domain\.com\s+\(.*\[.*\]\)/
score LOCAL_RCVD -50

where domain.com is your local domain. This is a bad idea, since all a spammer has to get those -50 is to give 'whatever.domain.com' when doing the EHLO/HELO. You need to check for the domain in the reverse lookup part of the received: header, like this:

header LOCAL_RCVD Received =~ /from.*\(\S+\.domain\.com\s+\[.*\]\)/
score LOCAL_RCVD -50

or, in case you don't have reverse dns set up for your local addresses, then you need to look at the third field:

header LOCAL_RCVD Received =~ /from.*\(.*\[192\.168\.\d+\.\d+\]\)/
score LOCAL_RCVD -50

I noticed a rule just like the one that appears in your article being "exploited" yesterday, so I guess that it is not that uncommon.
Credits for spotting that go to: Alberto Brealey G.

Thanks for everyone's feedback!  

Contact
E-mail: <G.Czaplinski at prioris.mini.pw.edu.pl>
PGP Key: <http://prioris.mini.pw.edu.pl/~gregory/pgp.txt>

"The Power to Serve, Right for the Power Users!" - http://www.FreeBSD.org/

 

Powered by FreeBSD Powered by vi Powered by Apache

28th of October 2003.
Grzegorz Czapliński