Re: local mail problem after FC4->FC5 upgrade
- From: Garen Erdoisa <gerdoisa@xxxxxxxxxxxx>
- Date: Wed, 31 May 2006 22:02:22 -0600
Art Werschulz wrote:
Hi.
AK <aktrader2@xxxxxxxxxx> writes:
Presumably the user information is stored in an LDAP directory? Are theAll the machines on the network are using NIS for user information.
HP's configured to consult the LDAP directory and do they store the message
or do they suppose to forward the email on?
There's one master NIS server, and no slave servers. IOW, all the machines have the same user info.
You need to look at the mail servers logs to see what is going on.When I sent mail to a local user on one of the affected machines, the
following appeared in /var/log/maillog:
May 31 09:30:24 dsm spamd[2532]: prefork: child states: II
May 31 09:30:25 dsm sendmail[3121]: k4VDUOuW003120: to=<root AT dsm.fordham.edu>, delay=00:00:01, xdelay=00:00:01, mailer=local, pri=34002, dsn=2.0.0, stat=Sent
This says that a spam daemon exited, then the email was delivered to root. ie: handed off to procmail for "root"
(I have replaced "@" with " AT ", to make things a bit harder for naive
simpleminded spambots.)
When I sent mail to joeuser AT dsm.fordham.edu (again, on one of the affected
machines), the following appeared in /var/log/maillog:
May 31 09:31:48 dsm sendmail[3153]: k4VDVmag003153: from=<>, size=3775, class=0, nrcpts=1, msgid=<200605311331.k4VDVmPX028099 AT sobolev.dsm.fordham.edu>,
proto=ESMTP, daemon=MTA, relay=sobolev.dsm.fordham.edu [150.108.64.57]
It appears that the above message was fed to spamd at this point which processed the message on a child process.
May 31 09:31:48 dsm spamd[2554]: spamd: connection from localhost [127.0.0.1]
at port 41721
May 31 09:31:48 dsm spamd[2554]: spamd: setuid to root succeeded
May 31 09:31:48 dsm spamd[2554]: spamd: still running as root: user not specified with -u, not found, or set to root, falling back to nobody at /usr/bin/spamd line 1152, <GEN202> line 4.
I see an issue here. your spamd (presumably SpamAssassin running in daemon mode as a sendmail milter) successfully set it's user id to root, then immediately dropped privileges again to the "nobody" account.
Subsequently because it lacked permissions the kernel denied access to spamd when it attempted to access it's files in the /root account.
IMO, based on the information that you've provided thus far, this issue is more likely a permissions issue on some of your servers than a hardware issue.
May 31 09:31:48 dsm spamd[2554]: spamd: processing message <200605311331.k4VDVmPX028099 AT sobolev.dsm.fordham.edu> for root:99
May 31 09:31:49 dsm spamd[2554]: mkdir /root/.spamassassin: Permission denied
at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin.pm line 1469
May 31 09:31:49 dsm spamd[2554]: locker: safe_lock: cannot create tmp lockfile /root/.spamassassin/auto-whitelist.lock.dsm.dsm.fordham.edu.2554 for
/root/.spamassassin/auto-whitelist.lock: Permission denied
May 31 09:31:49 dsm spamd[2554]: auto-whitelist: open of auto-whitelist file failed: locker: safe_lock: cannot create tmp lockfile /root/.spamassassin/auto-whitelist.lock.dsm.dsm.fordham.edu.2554 for /root/.spamassassin/auto-whitelist.lock: Permission denied
May 31 09:31:49 dsm spamd[2554]: bayes: locker: safe_lock: cannot create tmp lockfile /root/.spamassassin/bayes.lock.dsm.dsm.fordham.edu.2554 for /root/.spamassassin/bayes.lock: Permission denied
May 31 09:31:49 dsm spamd[2554]: spamd: clean message (-1.4/5.0) for root:99 in 0.1 seconds, 4060 bytes.
May 31 09:31:49 dsm spamd[2554]: spamd: result: . -1 - ALL_TRUSTED scantime=0.1,size=4060,user=root,uid=99,required_score=5.0,rhost=localhost,
raddr=127.0.0.1,rport=41721,
mid=<200605311331.k4VDVmPX028099 AT sobolev.dsm.fordham.edu>,autolearn=failed
May 31 09:31:49 dsm spamd[2532]: prefork: child states: II
The spamd process finishes returning it's results
May 31 09:31:49 dsm sendmail[3154]: k4VDVmag003153: to=<root AT dsm.fordham.edu>, delay=00:00:01, xdelay=00:00:01, mailer=local,
pri=33993, dsn=2.0.0, stat=Sent
And the DSN (Delivery Status Notification) says that the message was successfully delivered to root. (ie: handed off to procmail for root)
May 31 09:32:07 dsm sendmail[3169]: k4VDW74M003169: from=<agw AT dsm.fordham.edu>, size=590, class=0, nrcpts=1, msgid=<200605311332.k4VDW7S9028110 AT sobolev.dsm.fordham.edu>, proto=ESMTP, daemon=MTA, relay=sobolev.dsm.fordham.edu [150.108.64.57]
New message
May 31 09:32:07 dsm sendmail[3170]: k4VDW74M003169: to=<joeuser AT dsm.fordham.edu>, ctladdr=<agw AT dsm.fordham.edu> (201/150), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30838, dsn=2.0.0, stat=Sent
Which was successfully delivered to joeuser. (ie: handed off to procmail for joeuser)
If procmail is not configured to do anything special for those accounts, it would just deliver the message to the inbox for the account.
You might have to define in the mail service configuration that it needs toExactly how should this be done?
forward any and all emails to the MX. Or make sure that the mail server
knows the *.dsm.fordham.edu is a local domain or if there is an email
address map that it needs to be consulted.
I would double check your config files in /etc/mail
Specifically make sure all your local host names are defined in
/etc/mail/local-host-names
for each of your machines that processes mail.
Look for typos, syntax errors, etc.
Also double check the entries in
/etc/mail/access
Again, look for typos
Please recall that mail worked on all the machines before the FC4->FC5
upgrade, and it is still working on all the non-HP machines. It's only on
the HP machines that mail to local users has stopped working. We haven't
changed any of the sendmail configuration files.
If you ran an upgrade instead of an install, look for *.rpmsave files which may have been replaced by distribution default files.
find / -type f -name '*.rpmsave'
Sometimes this happens when you modify distribution config files, then run an upgrade. If an old config file was overwritten, it could potentially cause all kinds of havoc on a custom installation.
Which mail server are you using?
Our mail server is dsm.dsm.fordham.edu.
Many thanks for your response. I look forward to your next suggestions.
I'm not seeing any problem with the logs you supplied that addresses your original issue of mail to local host user names not being delivered. Do those accounts actually exist as such on those hosts? (ie: are they present in /etc/passwd and do each of them have home directories on those machines?) If not, then you could just add email aliases to /etc/aliases for those problem user names which will intercept and forward to the correct fully qualified email address.
spamd immediately dropping privileges when it's acquired root level access isn't surprising, and is probably normal. I don't run SpamAssassin here so am not certain of this.
--
Garen
.
- Next by Date: Re: dot-qmail forwarding to php skript
- Next by thread: Re: dot-qmail forwarding to php skript
- Index(es):
Relevant Pages
|
