FreeBSD Sendmail Problem

Thanks for the help with my script issue recently. I was wondering if anyone has seen this problem with Sendmail? I aliased root to "taosecurity at gmail dot com" as shown below. (I used the real email address on the computer.) This is a fresh install of FreeBSD 8.1.

$ uname -a
FreeBSD vm.taosecurity.com 8.1-RELEASE FreeBSD 8.1-RELEASE #0: \
Mon Jul 19 02:55:53 UTC 2010 \
root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386

vm# diff -u /etc/aliases /etc/aliases.orig
--- /etc/aliases 2010-11-18 10:30:37.000000000 -0500
+++ /etc/aliases.orig 2010-11-18 10:30:26.000000000 -0500
@@ -18,7 +18,6 @@
# root's email from here.

# root: me@my.domain
-root: taosecurity at gmail dot com

# Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
vm# newaliases
/etc/mail/aliases: 28 aliases, longest 21 bytes, 300 bytes total

My /etc/mail and /var/spool directories are pristine from the factory"

vm# ls -al /etc/mail
total 300
drwxr-xr-x 2 root wheel 512 Oct 31 11:28 .
drwxr-xr-x 20 root wheel 2048 Nov 18 10:30 ..
-rw-r--r-- 1 root wheel 6818 Jul 18 22:25 Makefile
-rw-r--r-- 1 root wheel 2905 Jul 18 22:25 README
-rw-r--r-- 1 root wheel 634 Jul 18 22:25 access.sample
-rw-r--r-- 1 root wheel 1695 Nov 18 10:30 aliases
-rw-r----- 1 root wheel 65536 Nov 18 10:30 aliases.db
-rw-r--r-- 1 root wheel 58276 Jul 18 22:25 freebsd.cf
-rw-r--r-- 1 root wheel 4118 Jul 18 22:25 freebsd.mc
-r--r--r-- 1 root wheel 40751 Jul 18 22:25 freebsd.submit.cf
-r--r--r-- 1 root wheel 901 Jul 18 22:25 freebsd.submit.mc
-r--r--r-- 1 root wheel 5657 Jul 18 22:25 helpfile
-rw-r--r-- 1 root wheel 409 Jul 18 22:25 mailer.conf
-rw-r--r-- 1 root wheel 253 Jul 18 22:25 mailertable.sample
-rw-r--r-- 1 root wheel 58276 Jul 18 22:25 sendmail.cf
-r--r--r-- 1 root wheel 40751 Jul 18 22:25 submit.cf
-rw-r--r-- 1 root wheel 582 Jul 18 22:25 virtusertable.sample

vm# ls -al /var/spool
total 16
drwxr-xr-x 8 root wheel 512 Jul 18 22:23 .
drwxr-xr-x 23 root wheel 512 Nov 12 11:45 ..
drwxrwx--- 2 smmsp smmsp 512 Nov 18 10:00 clientmqueue
drwxrwxr-x 2 uucp dialer 512 Nov 12 16:45 lock
drwxr-xr-x 2 root daemon 512 Jul 18 22:23 lpd
drwxr-xr-x 2 root daemon 512 Nov 18 10:31 mqueue
drwx------ 2 root daemon 512 Jul 18 22:23 opielocks
drwxr-xr-x 3 root daemon 512 Jul 18 22:23 output

I can send email when testing as root (email addr "obfuscated"):

vm# date | sendmail -v -Am postmaster
postmaster... aliased to root
root... aliased to taosecurity at gmail dot com
taosecurity at gmail dot com... Connecting to gmail-smtp-in.l.google.com. via esmtp...
220 mx.google.com ESMTP n10si1312258qcu.1
>>> EHLO vm.taosecurity.com
250-mx.google.com at your service, [98.218.35.11]
250-SIZE 35651584
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
>>> MAIL From: SIZE=29
250 2.1.0 OK n10si1312258qcu.1
>>> RCPT To:
>>> DATA
250 2.1.5 OK n10si1312258qcu.1
354 Go ahead n10si1312258qcu.1
>>> .
250 2.0.0 OK 1290094272 n10si1312258qcu.1
taosecurity at gmail dot com... Sent (OK 1290094272 n10si1312258qcu.1)
Closing connection to gmail-smtp-in.l.google.com.
>>> QUIT
221 2.0.0 closing connection n10si1312258qcu.1

That worked. However, I cannot send email as a user:

$ date | sendmail -v -Am postmaster
postmaster... aliased to root
root... aliased to taosecurity at gmail.com
collect: Cannot write ./dfoAIFVDIG019327 (bfcommit, uid=1001, gid=25): Permission denied
queueup: cannot create queue file ./qfoAIFVDIG019327, euid=1001, fd=-1, fp=0x0: Permission denied

Behavior is the same on FreeBSD 7.3 with a fresh install.

I did a ton of research and usually found references to incorrect permissions, etc. In fact, in this post I got the idea to check directories using mtree:

r200a# mtree -p /var -e -U -f /etc/mtree/BSD.var.dist
run changed
permissions expected 0755 found 0777 modified
r200a# mtree -p /var -e -U -f /etc/mtree/BSD.sendmail.dist
./var missing (created)
./var/spool missing (created)
./var/spool/clientmqueue missing (created)

Computer r200a was another FreeBSD system where I tried to fix this problem. However, these changes made no difference.

Any ideas? Thank you.

Update: The reason I investigated this activity was I found errors like this in /var/log/messages on another FreeBSD system, r200b:

Nov 13 03:01:11 r200b sm-mta[40505]: oAD81AUR040505: Losing ./qfoAD81AUR040505: savemail panic
Nov 13 03:01:11 r200b sm-mta[40505]: oAD81AUR040505: SYSERR(root): savemail: cannot save rejected email anywhere

As you can see, whatever was trying to send email using sm-mta was failing.

Comments

Sevan Janiyan said…
after making changes to your aliases file run:
make install restart

Have you specified anything in relation to sendmail in your /etc/rc.conf??
Wu said…
Perhaps something related to the use of smrsh ? (http://urlcorta.es/3lrz) perhaps you have to add your local user to a given group so it can execute commands through sendmail or something like that.

I do not allow users to send email locally (only after a TLS-secured connection and using SMTPauth) so I think having this disabled by default is quite a good idea (+1 for FreeBSD)
Hi Sevan,

Good tip --

vm# cd /etc/mail
vm# make install restart
cp freebsd.mc vm.taosecurity.com.mc
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 vm.taosecurity.com.mc > vm.taosecurity.com.cf
install -m 444 vm.taosecurity.com.cf /etc/mail/sendmail.cf
cp freebsd.submit.mc vm.taosecurity.com.submit.mc
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/ /usr/share/sendmail/cf/m4/cf.m4 vm.taosecurity.com.submit.mc > vm.taosecurity.com.submit.cf
install -m 444 vm.taosecurity.com.submit.cf /etc/mail/submit.cf
Restarting: sendmail sendmail-clientmqueue.

vm# logout
$ date | sendmail -v -Am postmaster
postmaster... aliased to root
root... aliased to taosecurity at gmail dot com
collect: Cannot write ./dfoAILdgEv019784 (bfcommit, uid=1001, gid=25): Permission denied
queueup: cannot create queue file ./qfoAILdgEv019784, euid=1001, fd=-1, fp=0x0: Permission denied
$ cat /etc/rc.conf

# -- sysinstall generated deltas -- # Fri Nov 12 16:36:42 2010
# Created: Fri Nov 12 16:36:42 2010
# Enable network daemons for user convenience.
# Please make all changes to this file, not to /etc/defaults/rc.conf.
# This file now contains just the overrides from /etc/defaults/rc.conf.
defaultrouter="10.10.1.1"
hostname="vm.taosecurity.com"
ifconfig_em0="inet 10.10.1.13 netmask 255.255.255.0"
sshd_enable="YES"

Unfortunately that isn't it. Hmm.
Wu, that's an interesting idea! Let me take a look at that.
Sevan Janiyan said…
I should've been paying closer attention (again) :)
invoking sendmail as an ordinary user wont work because of the sendmail drop privilege mechanism, the command you should be using instead is mail(1)

date |mail -s "some subjectline" someoneoralias
Sevan Janiyan said…
RE: update
http://www.brandonhutchinson.com/savemail_panic_in_Sendmail.html
Sevan, you're definitely correct about using mail instead of sendmail -- thank you!

For your URL, I see rejected emails in /var/spool/mqueue, which appear to be caused by a change introduced by Gmail. So, I guess my testing with using 'sendmail' instead of 'mail' wasn't relevant to that problem. Thanks for your help!
a couple of things:

collect: Cannot write ./dfoAILdgEv019784 (bfcommit, uid=1001, gid=25): Permission denied
queueup: cannot create queue file ./qfoAILdgEv019784, euid=1001, fd=-1, fp=0x0: Permission denied

these are definitely file system permission errors, most likely the user the program runs as is not a member of the correct group or suchlike.

One other thing to keep in mind is that mxes tend to check the reverse lookup for the hostname your sendmail uses in the helo/ehlo sequence. It's not uncommon to reject messages coming in from hosts with wrong or no reverse.
Sevan Janiyan said…
a pleasure :)
Anonymous said…
strange i have the same error on a RHEL 4.8 box
Anonymous said…
Is /usr/sbin/sendmail setgid to smmsp?
Anonymous said…
Let me add - the README file in the source specifies what the directory and file permissions should be.

- Bruce
Everyone, please see my next post for more details.

Popular posts from this blog

Zeek in Action Videos

New Book! The Best of TaoSecurity Blog, Volume 4

MITRE ATT&CK Tactics Are Not Tactics