# Postfix not playing nicely with dspam [SOLVED]

## wayt

I've been trying for two days to get dspam working along with postfix and procmail on my gentoo mail server. First I tried using the masked ebuild to set up dspam as an SMTP relay, following the HOWTO on the Gentoo Wiki. That didn't work, and after struggling with it for several hours I gave up, unmerged dspam and reset my postfix config files to their backed up working versions.

Then I found this nicely written guide to using dspam as a delivery agent in concert with procmail, and tried that. It presents a much simpler approach than the HOWTO does. Nevertheless, following the steps still results in a postfix that complains about refused connections and an apache that forbids access to the dspam CGI interface.

I'd be oh so grateful for assistance. At the moment, dspam 3.6.8 is compiled and installed in /usr/local/bin, postfix is using its as-emerged master.cf and a main.cf that includes

```
mailbox_command = /usr/local/bin/dspam --deliver=innocent --user $USER

luser_relay = [my user name]

setgid_group = postdrop

pwcheck_method: = saslauthd

smtpd_sasl_auth_enable = yes

smptd_sasl2_auth_enable = yes

smtpd_sasl_security_options = noanonymous

smtpd_sasl_local_domain =

broken_sasl_auth_clients = yes

smtpd_use_tls=yes

smtpd_tls_auth_only = yes

smtpd_tls_key_file = /etc/ssl/postfix/server.key

smtpd_tls_cert_file = /etc/ssl/postfix/server.crt

smtpd_tls_CAfile = /etc/ssl/postfix/server.pem

smtpd_tls_loglevel = 1

smtpd_tls_received_header = yes

smtpd_tls_session_cache_timeout = 3600s

tls_random_source = dev:/dev/urandom

best_mx_transport = local

ignore_mx_lookup_error = yes

smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_rbl_client relays.ordb.org, permit

smtpd_recipient_restrictions = permit_mynetworks, reject_non_fqdn_sender, reject_unknown_recipient_domain, reject_unauth_pipelining

```

in addition to the usual defaults and sensible mynetworks, mydomain, etc. settings.

Prior to installing dspam, postfix worked swimmingly handing off emails to procmail for filtering and delivery. The only change to main.cf was to the mailbox_command setting.

So why does postfix now spew this into the logs?

```
Jun 15 19:01:15 icarus postfix/smtpd[31467]: connect from mail1.sea5.speakeasy.net[69.17.117.3]

Jun 15 19:01:15 icarus postfix/smtpd[31467]: setting up TLS connection from mail1.sea5.speakeasy.net[69.17.117.3]

Jun 15 19:01:16 icarus postfix/smtpd[31467]: TLS connection established from mail1.sea5.speakeasy.net[69.17.117.3]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)

Jun 15 19:01:16 icarus postfix/smtpd[31467]: 7550B157403E: client=mail1.sea5.speakeasy.net[69.17.117.3]

Jun 15 19:01:16 icarus postfix/cleanup[31470]: 7550B157403E: message-id=<00fc01c690cf$7b513f30$800101df@ThinkPadT42>

Jun 15 19:01:16 icarus postfix/qmgr[14822]: 7550B157403E: from=<wayt@speakeasy.net>, size=1851, nrcpt=1 (queue active)

Jun 15 19:01:16 icarus postfix/local[31471]: 7550B157403E: to=<[myusername]@waytgibbs.net>, orig_to=<wayt@waytgibbs.net>, relay=local, delay=0, status=sent (delivered to command: /usr/local/bin/dspam --deliver=innocent --user $USER)

Jun 15 19:01:16 icarus postfix/qmgr[14822]: 7550B157403E: removed

Jun 15 19:01:16 icarus postfix/smtpd[31467]: disconnect from mail1.sea5.speakeasy.net[69.17.117.3]

Jun 15 19:01:55 icarus postfix/qmgr[14822]: warning: connect to transport dspam: Connection refused

Jun 15 19:02:55 icarus postfix/qmgr[14822]: warning: connect to transport dspam: Connection refused
```

...and so on with a new "Connection refused" message every minute.

Could it be a permissions problem? I followed the guide in setting dspam to

```
-r-x--s--x  1 root mail 345K Jun 15 14:42 dspam
```

Yet the mail does end up in $HOME/.maildir where it belongs. But the messages include a bizarre addition from dspam in the body:

```
test 5(actual message ends here)

!DSPAM:4491e6bc314721804284693!
```

Dspam's system.log is no help:

```
1150412476      I       "W. Wayt Gibbs" <wayt@speakeasy.net>    4491e6bc314721804284693 test 5 of dspam 0.019997        [myusername]    Delivered   <00fc01c690cf$7b513f30$800101df@ThinkPadT42>
```

The dspam docs are written for gurus--they're of little help to someone like me who has only been using gentoo for four years.

Fix this problem for me and I'll throw you another: getting the CGI to work in a virtual host on Apache2.Last edited by wayt on Fri Jun 16, 2006 2:30 am; edited 1 time in total

----------

## wayt

I can't explain why, but rebooting fixed the problem. Postfix no longer complains every minute about its connections being refused. Needless to say, I had stopped and restarted the Postfix daemon many times, and that wasn't sufficient to resolve the issue. I don't know why rebooting did the trick, but I'm happily surprised.   :Laughing: 

----------

## magic919

You might want to stick up a fresh post regarding your Apache problems.  I'm assuming that's with the DSPAM web interface.  Glad you got the other bit sorted.  It's a bit of a learning curve with DSPAM.

----------

## thepustule

The complaints about a missing transport: DSPAM might indicate that you didn't do a postmap on your transports file, so you hadn't really cleared up the old setting of using DSPAM as a relay.  Not sure if postfix does a postmap and a newaliases during a reboot, but that might explain it.

As for the cgi - if my dspam nightmares are any indication, it's likely a permissions issue.  It took me two weeks of all-nighters to get this beast working.  Probably the most insanely complicated permissions requirement I've ever seen.  like yours, I do postfix -> dspam -> procmail

problem is - the gentoo layout of the files differs substantially from upstream (although I have to admit the gentoo choices made more sense to me), so a lot of the troubleshooting steps have to be translated to gentoo.  

dspam is by far the best spam filter I've ever seen - it filters 400 spams per day for me, out of the 700 or so emails I get daily.  I'm getting over 99.9% accuracy.  (I believe it's 99.93% to be exact) And I haven't gotten anything like that with any other program.  Only bogofilter came close, but it was more like 95%.

To get mine working, though, I had to totally give up on the web-managed quarantine - just simply couldn't get it to work.  Instead, I just drag spams to an imap folder and then have an hourly cron-job that processes that folder through a dspam retrain using formail and then moves the contents to my spam folder.  much easier to look after that way anyhow.  All of the dspam admin web pages work, with the status graphs and history, but I just gave up on the quarantine.

----------

## wayt

Well, thanks, I don't feel like quite as much of a numbnut now for staying up nearly all night futzing with the damn DSpam CGI.

Could you please post the script for your cron-job? I'd love to borrow that trick.

I made a major breakthrough when I thought to check /var/log/apache2/suexec_log and noticed "cannot run as forbidden uid", which, after doing a

```
suexec2 -V
```

 clued me in to the problem that the dspam user I had created had a user id below 1000, which makes suexec2 barf. It also wants dspam to be in a group with a gid greater than 100. So I used 

```
usermod -u 1234 dspam

groupmod -g 123 dspam
```

 did chown dspam:dspam on everything in /var/run/dspam and /var/www/[virtualhostname]/{htdocs|cgi-bin}, /etc/mail/dspam, /var/spool/dspam, [sigh] and everything else that wanted to be owned by dspam, and all was well. At last the promised webui appeared.

Appeared--it didn't exactly work, though.

The History and Analysis pages return only:

 *Quote:*   

> An Error Has Occured
> 
> The following error occured while trying to process your request: 
> 
> No historical data is available.
> ...

 

And while I can log in and browse to the preferences page, when I make a change and hit submit I get:

 *Quote:*   

> An Error Has Occured
> 
> The following error occured while trying to process your request: 
> 
> Unable to write preferences: No such file or directory

 

which seems to suggest that dspam.cgi, running as dspam:dspam, can't write to /var/run/dspam/data/[user], even though it owns that directory and everything in it. But when I add [user] to /var/www/[virtualhostname]/htdocs/admins, then use the Administration tab of the CGI to edit prefs for the very same user, it saves them just fine! Adding [user] to the dspam group and as a Trusted user in /etc/mail/dspam/dspam.conf doesn't seem to fix this. Bizarre.

One of these days some genius will put together an ebuild that actually sets the proper permissions and works (dspam-web still doesn't)--or at least a comprehensive HOWTO that lists what permissions are needed on every single file that dspam uses. Until that day, guys like us will just keep banging our heads against the wall and cursing the vague and unhelpful logs these utils produce.

----------

## thepustule

I think your "no historical data is available" sounds familiar.  I believe it has to do with permissions on the dspam log directory.  In mine it is symlinked to /var/log/dspam, but all log files in that area were 0 size, so I guessed that dspam couldn't write to them.  Changing the permissions and ownership allowed dspam to write to the logs, and then my graphs began to populate on the CGIs.

The script for processing missed spam and false positives:

```
#!/bin/sh

#

cd ~/imap/SpamCorpus

cat processme | formail -s /usr/bin/dspam --user <myusername> --source=error\

   --class=spam 2> /dev/null

cat oops | formail -s /usr/bin/dspam --user <myusername> --source=error\

   --class=innocent 2> /dev/null

cat processme | formail -s >> spam

cat oops | formail -s >> recovered

rm -f processme

touch processme

rm -f oops

touch oops

```

In my imap folders I have one called "processme" and one called "oops".  I put missed spam in "processme" and the one single false positive I've ever had I put in "oops" and then dspam reprocessed them with this script.  Obviously I use mbox for my mail.  Don't know how you'd have to modify this if you use maildir instead.

----------

