Hi,
On Jun 11, 2015, at 4:49 PM, Noel Jones wrote:
On 6/11/2015 3:13 PM, Al Zick wrote:
...
I don't know anything about dspam, but I have some comments on your
postfix configuration.
If I integrate it into my postfix's master.cf, dspam doesn't crash
anymore, but I have greater problems.
Here is my master.cf:
# SMTP no filter
127.0.0.1:25 inet n - n - - smtpd
10.20.238.4:25 inet n - n - -
smtpd
# SMTP with filter
smtp inet n - n - - smtpd
-o content_filter=lmtp:unix:/var/dspam/dspam.sock
# Post Dspam filter
127.0.0.1:2424 inet n - - - - smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_checks,no_header_body_c
hecks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8
The above looks reasonable, assuming you can configure dspam to pass
mail back to postfix via SMTP port 2424. You should add " -o
syslog_name=postfix/dspam-out" to the port 2424 listener to
differentiate it in the logs.
I added " -o syslog_name=postfix/dspam-out" to my config. This helped!
With this integration, very quickly the server becomes 0% idle with
a high load average. I am not sure if this is because it is bouncing
the emails and then the spammers send them right back, or if the
emails are being deferred.
The logs will tell you what postfix is doing, no need to guess.
Well, I have never seen the log look like this before. The log had a
very large group of deferred emails. Then a very large group of
emails that were being sent to dspam. I could not make any sense of it.
My guess is that you're looping dspam output back to the wrong
postfix listener and it gets filtered again and again, eventually
triggering "too many hops" and bounce the mail to the sender.
Yes, you were right. It was looping dspam output back to the wrong
postfix IP/port. The only way that I could find to fix this was to
change inet_interfacees = all
I changed this to only use the IP addresses that are necessary and
the problem went away. My guess is that dspam tries its default IP on
port 25 first. It must be somewhere in 127.0.0.0/8.
There are a lot of deferred emails in the
log.
The log shows why they are deferred, and the unreachable
destination. Both valuable clues. Read your logs carefully.
Well, my log is back to normal now. It must reject about 90% of the
emails for one reason or another. Still, almost all the emails I get
are spam.
Next, it seems to save all the spam and reject all the real
emails.
This supports my guess that spam was detected, and good mail looped
until it melted.
At this point, you convinced me that it looped until there were too
many hops.
Also, I am still not sure what happened to all the emails.
Were they were bounced, or just lost somewhere?
The logs will show where mail went.
It really looks like they eventually bounced.
And procmail doesn't
seem to know who to deliver the emails to if they are passed to it
from dspam. I am getting errors in my maillog from procmail saying
user unknown.
Is this good mail or spam mail? Is it really the wrong username?
Dspam takes what ever is before the @ in the email address and then
passes that off as the user to procmail.
Anyway, seems to me dspam should be sending all mail back to postfix
for delivery, not trying to pass mail to procmail.
It took me a while to get this working properly too.
Kind Regards,
Al
