F8 (and FX?]: Sendmail, Spamassassin, and Spamass-Milter issues.

Tue Dec 2 22:06:30 UTC 2008

Folks,

I have updated my F8 system and my spamassassin/spamass-milter
have crapped out.  Here is what I found, with no resolution:

1) Entries in: /etc/mail/sendmail.mc
=============================================================
INPUT_MAIL_FILTER(`clamav-milter', 
`S=local:/var/run/clamav-milter/clamav.sock, F=,T=S:4m;R:4m')dnl
INPUT_MAIL_FILTER(`spamassassin', 
`S=local:/var/run/spamass-milter/spamass-milter.sock, 
F=,T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confINPUT_MAIL_FILTERS', `spamassassin,clamav-milter')dnl
=============================================================

2) Entries in: /etc/sysconfig/spamass-milter
=============================================================
No changes needed because the default spamass-milter socket is:
    /var/run/spamass-milter/spamass-milter.sock
and no options needed either.
=============================================================

3) With sendmail stopped, maillog cleared, and when spamass-milter starts:
[root at linux mail]# service spamass-milter start
Starting SpamAssassin milter (spamass-milter):             [  OK  ]
[root at linux mail]#  tail -f /var/log/maillog:
=============================================================
Dec  2 12:10:24 linux sendmail[10575]: mB2KAOt9010575: from=sa-milt, 
size=195, class=0, nrcpts=1, 
msgid=<200812022010.mB2KAOt9010575 at linux.cdkkt.com>, relay=sa-milt at localhost
Dec  2 12:10:24 linux sendmail[10575]: mB2KAOt9010575: to=root, 
ctladdr=sa-milt (487/478), delay=00:00:00, xdelay=00:00:00, 
mailer=relay, pri=30195, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, 
stat=Deferred: Connection refused by [127.0.0.1]
Dec  2 12:10:34 linux sendmail[10583]: mB2KAYI8010583: from=sa-milt, 
size=195, class=0, nrcpts=1, 
msgid=<200812022010.mB2KAYI8010583 at linux.cdkkt.com>, relay=sa-milt at localhost
=============================================================
So, everything appears to be normal, right?  Oh wait!
=========
Notice this:
=========
# ls -l /var/run/spamass-milter/spamass-milter.sock
ls: cannot access /var/run/spamass-milter/spamass-milter.sock: No such 
file or directory

YOU CANNOT START SPAMASS_MILTER IF THERE IS NO PREVIOUS
SOCKET INSTALLED NOR WILL IT INSTALL ONE!  DANG!! THE SERVICE
DOES NOT CHECK TO MAKE SURE A SOCKET EXISTS AND SPEW NO
ERROR IF THERE IS NO SOCKET?

If you attempt to start sendmail, IT WILL FAIL. IT WILL REFUSE TO START.

Seems I might have a way out, let's see.  Lets see if we can MANUALLY
start it:
# /usr/sbin/spamass-milter -p 
'/var/run/spamass-milter/spamass-milter.sock' -f
<no error is reported on the command line> and of course the log information
in maillog simply says 'connection refused' since sendmail is not running.
But wait: is spamass-milter running?  really??
# pgrep spamass-milter
14339
14814
Oh gawd - two of 'em running!?!?  Nope, won't do.  Kill them with:
# service spamass-milter stop
[Displays stop results]
# pgrep spamass-milter
[nothing displayed, great]
# /usr/sbin/spamass-milter -p 
'/var/run/spamass-milter/spamass-milter.sock' -f
[nothing displayed, great]
# pgrep spamass-milter
14973
Geez.  Finally - I have ONE spamass-milter running.

4) Starting sendmail:
=============================================================
[root at linux spamass-milter]# service sendmail start
Starting sendmail: 451 4.0.0 /etc/mail/sendmail.cf: line 1714: 
Xspamassassin: local socket name 
/var/run/spamass-milter/spamass-milter.sock unsafe: Permission denied

[FAILED]
Starting sm-client:                                        [  OK  ]
[root at linux spamass-milter]#
=======================

Say what?  Permissions problem!?  Let's see:

[root at linux spamass-milter]# ls -lZ 
/var/run/spamass-milter/spamass-milter.sock
srwxr-xr-x  root root unconfined_u:object_r:var_run_t:s0 
/var/run/spamass-milter/spamass-milter.sock

Oh man.  Seems that starting the spamass-milter improperly creates the 
sockets with
the wrong security context and assigns root ownership?  Perhaps things 
are different
were it started as a service? Dunno, but moving on...

Ok, well, let's see if we can fix the security context:

[root at linux spamass-milter]# restorecon -v 
'/var/run/spamass-milter/spamass-milter.sock'
restorecon reset /var/run/spamass-milter/spamass-milter.sock context 
unconfined_u:object_r:var_run_t:s0->system_u:object_r:spamd_var_run_t:s0

Interesting.  Why did running spamass-milter create and unconfined_u and
var_run_t security context for it's socket?

Let's check the directory holding this socket:
[root at linux dant]# ls -lZd /var/run/spamass-milter/
drwxr-xr-x  sa-milt sa-milt system_u:object_r:var_run_t:s0   
/var/run/spamass-milter/

Looks good to me. I did this so that I'd have a reference for later on
when the sendmail and it's milters start running...

Ok, let see if we can get sendmail started once again:
[root at linux spamass-milter]# service sendmail start
Starting sendmail:                                         [  OK  ]

Yeah. that seemed to work... so let see what the maillogs
and message logs says"

[root at linux mail]#  tail -f /var/log/maillog:
=============================================================
Dec  2 12:15:51 linux sendmail[10873]: alias database /etc/aliases 
rebuilt by dant
Dec  2 12:15:51 linux sendmail[10873]: /etc/aliases: 91 aliases, longest 
25 bytes, 1101 bytes total
Dec  2 12:15:51 linux sendmail[10878]: starting daemon (8.14.2): 
SMTP+queueing at 01:00:00
Dec  2 12:15:52 linux sm-msp-queue[10887]: starting daemon (8.14.2): 
queueing at 01:00:00
============================================================vvvvvvvvvvvvvvv
Dec  2 12:15:53 linux sendmail[10889]: mB2KFqPe010889: Milter 
(spamassassin): error connecting to filter: Connection refused by 
/var/run/spamass-milter/spamass-milter.sock
Dec  2 12:15:53 linux sendmail[10889]: mB2KFqPe010889: Milter 
(spamassassin): to error state
===============================================================^^^^^^^^

But notice this, from /var/log/messages:
=============================================================
Dec  2 13:38:44 linux setroubleshoot: SELinux is preventing sendmail 
(sendmail_t) "connectto" to /var/run/spamass-milter/spamass-milter.sock 
(unconfined_t). For complete SELinux messages. run sealert -l 
83175cb8-f9dd-4451-af8a-122502520e54
=============================================================

Huh?  I just fixed the security context earlier when I manually started 
spamass-milter,
so why does SELinux *think* that the socket still has the "unconfined_t" 
security
context?

Let's see:  Let's restart the setroubleshoot service, perhaps it is `out 
of sync'?

[root at linux dant]# service setroubleshoot restart
Stopping setroubleshootd:                                [  OK  ]
Starting setroubleshootd:                                  [  OK  ]

Looking at the logs again, the darn thing (setroubleshoot) SHUT UP!
No more alerts to spamass-milter socket!

But DANG!!  There is another problem.... in /var/log/maillog:
=============================================================
Dec  2 13:51:03 linux sendmail[15554]: mB2Lp2UC015554: Milter 
(spamassassin): error connecting to filter: Permission denied
=============================================================
What filter are they talking about?  Is it a sendmail or spamassasin (or 
spamass-milter)
issue?

I am not at this point even sure what is going on nor what the 
consequences of ignoring
this error message would mean.  Perhaps someone could care to comment?  
Seems
to me that there are no other error messages reported except for 
repeated and interspersed
"Permission denied" errors similar to the above log message and it 
appears every time
a new message comes in.

Alas - after coming this far, if the system reboots - all bets are off 
and I'd
have to go though this whole scenario again.  Perhaps someone could take
a look at it and get it fixed (assuming it is not some stupid 
configuration issue
on my part)?

Thanks,
Dan