Cannot send mail to root?

I have a freshly installed FBSD 8.0 on an AMD64 machine. Everything installed fine, but I noticed that I stopped receiving the daily security check logs (as I used to receive under FBSD 7.2). So I tried to send a mail to the root user using mutt, and mutt refuses, claiming "user unknown". I have no problems sending mail to the other users on the machine. I also noticed there is no file /usr/mail/root (as all other user have).
Can anyone tell me whether this is normal behavior and, if not, how can it be solved?
I have no problems logging in as root (I installed more than 150 ports as root).
 
Would you mind providing some log evidence ? Is sendmail running or have you changed it to something else ?
 
Using sendmail, and AFAIK works fine for all non-root users. I have no problems sending mail to any of the other users.
Here is the reply gmail gets from trying to send mail to root:
Code:
Delivery to the following recipient failed permanently:

    root@(text deleted by me)

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for 
further information about the cause of this error. The error that the other server returned was: 553 553 5.1.3 <root@(text deleted by 
me)>... User address required (state 17).

If I try to use mutt (on the FBSD machine) to send mail to root (while logged as another user) first mutt
replies
Code:
Error sending message, child exited 67 (User unknown.)
and I get back a mail containing pretty much the same info as the one from gmail:
Code:
The original message was received at Mon, 17 May 2010 00:39:34 -0500 (CDT)                          
from gabi@localhost                                                                                 
                                                                                                    
   ----- The following addresses had permanent fatal errors -----                                   
root@(text deleted by me)                                                                            
    (reason: 553 5.1.3 <root@(text deleted by me)>... User address required)                          
    (expanded from: root@(text deleted by me))                                                        
                                                                                                    
   ----- Transcript of session follows -----                                                        
... while talking to [127.0.0.1]:                                                                   
>>> DATA                                                                                            
<<< 553 5.1.3 <root@(text deleted by me)>... User address required                                    
550 5.1.1 root@(text deleted by me)... User unknown                                                   
<<< 503 5.0.0 Need RCPT (recipient)
 
root shouldn't receive mail. The root user should be aliased to a regular user. E.g in /etc/mail/aliases you should edit it to look something like this:

Code:
root:   frank

Once you've edited it, run newaliases(1) and all of roots mail will be delivered to you.
 
Actually it is aliased, but obviously sendmail rejects anything sent to root, before reaching the stage at which it checks aliases. Or so it seems to me.
 
frank_s said:
root shouldn't receive mail. The root user should be aliased to a regular user.
Why? Root does receive mail by default. I don't see any problem with that, other than the inconvenience of having to log in as root every time you want to read the reports. I don't see a security risk either if sendmail is bound to the localhost loopback interface only, as it is by default (sendmail_enable="NO").

&quot said:
# Pretty much everything else in this file points to "root", so
# you would do well in either reading root's mailbox or forwarding
# root's email from here.
 
Beastie said:
Why? Root does receive mail by default. I don't see any problem with that, other than the inconvenience of having to log in as root every time you want to read the reports. I don't see a security risk either if sendmail is bound to the localhost loopback interface only, as it is by default (sendmail_enable="NO").

I use Postfix and Maildirs which means that if I didn't have root aliased I'd be getting all the crap in root's Maildir filling up my already small root partition. I think the same applies to Sendmail and mbox. Potential DOS.

There's also a permissions problem in reading your mail if you use an X-based MUA. ie: startx as regular user & then try and launch your MUA as root.

There is a potential security problem if Sendmail can receive mail from the 'net.

They're 3 problems I can think of offhand. Plus the inconvenience you mention.

Most importantly, it's what I've always done ;)
 
tempel33 said:
Actually it is aliased, but obviously sendmail rejects anything sent to root, before reaching the stage at which it checks aliases. Or so it seems to me.

Try cranking up logging on Sendmail & have a look at maillog.
 
What is the output of [cmd=]sendmail -bv root[/cmd]
?

Note that local mail to the root address should not get expanded to anything by default. A system email to local user root simply shows up in maillog as:

Code:
May 17 00:00:37 somebox sendmail[5922]: o4GM0CIN005922: [B]to=root[/B], [B]ctladdr=root[/B] (0/0), delay=00:00:25, xdelay=00:00:00, mailer=relay, 
pri=32891, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (o4GM0bxF005928 Message accepted for delivery)

If you see things like

Code:
root@(text deleted by me)

there's obviously some aliasing or rewriting by e.g. virtusertable going on. The sendmail -bv root command may turn something up.
 
Code:
# sendmail -bv root
"|exec /usr/local/bin/procmail || exit 75"... deliverable: mailer prog, user "|exec /usr/local/bin/procmail || exit 75"

How does one "crank up the logging on Sendmail"?
 
Do you have a /root/.procmailrc or a /root/.forward file?

There's no real reason why this exec line should turn up in a sendmail -bv command. I'm using procmail as a LDA myself, but it simply works transparently from sendmail.cf's Mlocal setting.

Anything in [cmd=]cd /etc/mail && grep ^root aliases virtusertable[/cmd]
?
 
DutchDaemon said:
Do you have a /root/.procmailrc or a /root/.forward file?
?
No and no. I did not have those files under FBSD 7.2 either


DutchDaemon said:
Anything in [cmd=]cd /etc/mail && grep ^root aliases virtusertable[/cmd]
?

Code:
aliases:root:gabi

gabi is the user that used to receive root's mail under FBSD 7.2.
 
So what is calling "|exec /usr/local/bin/procmail || exit 75" ? That is highly unusal and looks manually configured. Maybe grep your /etc/ and /usr/local/etc/ directories recursively for files containing the string 'procmail'.

# grep -rl procmail /etc/ /usr/local/etc/ /root/.*
 
No files containing "procmail" there.
I think the only user that uses procmail (with the associated .forward file) is the one that used to receive root's mail (gabi).
 
If you want mail for gabi forwarded, just create an alias for gabi in /etc/mail/aliases, or alias the root address directly to the email address you want to have root mail delivered to. And check gabi's .procmailrc for anything out of the ordinary (assuming that procmail functions correctly otherwise).
 
Well, that is the only way I know to use spamassassin. .forward invokes procmail, procmail invokes spamassassin. I bet there could be better ways, but it worked for me since FBSD 6.4 and it still works with 8.0, except this weird un-mail-able root problem. To be frank, I wasn't paying a great deal of attention to those security mails root used to receive, but I cannot wonder whether there is something worse with my FBSD 8.0 ...
 
Ok, try this. Create a file .procmailrc in ~gabi, and add these lines:

Code:
:0:
* ^TOroot
/var/mail/gabi

(or /usr/mail/gabi, wherever that default mailbox may be)

Hopefully this file will get picked up by Procmail before the SA stuff gets called.
 
I added
:0:
* ^TO.*root
mbox
on top of the filters on gabi's .procmail file. Still same "unknown user" problem. I do not think this is a SA problem, the "unknown user" answer comes instantly after hitting the "send" key in mutt. Usually SA takes at least a couple of seconds until it does all its work and anyways the above filter comes before the SA filter in the .procmail file. And even if it comes to filter the message for root, it would just move it to a spam directory (in the worst case scenario).
 
Can you remove the root alias from /etc/mail/aliases and run make in /etc/mail? The root mail should simply drop in /var/mail/root without further ado.
 
Amazing how patient you can be on this subject. Many thanks!
I removed the root:gabi line from the aliases file, ran make to rebuild the aliases database, but sendmail still claims root to be an unknown user.
 
And what does [cmd=]sendmail -bv root[/cmd] come up with now? Also check the output of [cmd=]finger root[/cmd]
 
Code:
s# sendmail -bv root
root... deliverable: mailer local, user root

Code:
# finger root
Login: root                             Name: Charlie Root
Directory: /root                        Shell: /bin/csh
Never logged in.
No Mail.
No Plan.
Hmm, seems I only "logged in" as root via "su -". Maybe one normal log in would solve it?
 
Code:
# finger root
Login: root                             Name: Charlie Root
Directory: /root                        Shell: /bin/csh
Last login Mon May 17 12:02 (CDT) on ttyv0
No Mail.
No Plan.
dragans# sendmail -bv root
root... deliverable: mailer local, user root
But no other changes. Root is still unknown by Sendmail.
 
Back
Top