Mark Rogers wrote:
Troy Ayers wrote:
Are you using dspam as daemon? Restart the dspam daemon only, not
the whole server.
Fair point, although the server restart is only a few seconds so that
isn't the problem, its stopping it happening in the first place!
Otherwise:
Enable debug logging.
Silly question, but where do I enable this?
I'm pretty sure that debugging isn't enabled in the Ubuntu/Debian
builds (how do I check?). I do have (and always have had) SystemLog
and UserLog enabled.
To check build parameters: dspam --version.
run dspam with the --debug switch ( my man page is a few years old,
please double check that --debug is the right switch to issue and also
check to see if it's compatible with daemon mode)
Check for the missing emails on the root account (or it's alias) if
applicable.
Check for the missing email on the account specified to receive
double-bounces (IE postmaster)
Where would I check where these are going?
Uh. the postmaster email account?
The domain I am particularly concerned about locating missing mail
from was set as a catch-all which redirected to a single address
elsewhere, ie postmaster@ would have gone to the same place as the
other emails. Other domains which drop to POP3 boxes on my server do
not, it turns out, have postmaster aliases set up (something I need to
fix).
Where would any root alias be set?
Whatever your postfix specifies it to be set as. My default location is
/etc/aliases. The postconf utility will tell you.
Would postfix have logged any failure to find a suitable
root/postmaster mailbox, and if so what should I look for in the logs?
Yes.
You would be better served looking up postfix questions yourself, to be
sure you're getting accurate information. Something like egrep
"error|fatal|panic|warning" /var/log/maillog.
I thought that dspam quarantine doesn't delete the message from the
mbox until after a successful exit code from whatever delivery agent
was specified. Could somebody confirm?
Looking at the Perl code I'm not convinced it is very careful, but I
really don't know much Perl at all. I've appended what I think is the
relevant subroutine below, but it looks to me like it extracts
messages, retrains on them (which I think leaves dspam to resend the
message?), then afterwards just deletes selected messages from the
quarantine (via Quarantine_DeleteSpam). There doesn't seem to be much
attempt to avoid deleting messages that couldn't be sent for some reason.
I leave this up to those more knowledgeable than me to determine if a
bug report should be reported.
Sounds like the message are not getting to postfix though. Postfix
logs a "connect from <hostname>[ipaddress]..." Please confirm that
postfix is listening in on the same ip/port as what you have
specified in your dspam.conf deliveryhost/deliveryport.
Based on my comments above, I think you're right; maybe postfix has
died for some reason (on the port 10026 configured for dspam to send
via), and the web interface simply ignores that fact and deletes the
messages.
Looking in the logs there are plenty of connections from
localhost.localdomain, but that's to be expected as the server is
usually working.
Does dspam log any failure to connect to the mailserver? I can't see
it having happened anywhere.
Next time it fails I will release something from the quarantine and
watch what goes into mail.log (and dspam's system.log).
[I assume that if I release a spam from the quarantine then retrain
that spam as spam then I get back to where I started? There's no point
releasing ham from the quarantine when I know its going to go missing!]
Correct.
-Troy
!DSPAM:1011,4874c4dc150923992416012!
