Mailx command not working from one sudo ID

lisha
lisha used Ask the Experts™
on
Few days back any mail related command ( mailx, mail ,mpack  ) stopped working from one sudo id .
in the logs i get error as dsn=5.6.0, stat=Data format error
but this happens with only one sudo ID-sudo1@my_hostname
another id -sudo2 works fine with any of the mail command

sudo su sudo1
mailx -s "Test mail" someone@example < /tmp/test.file
/home/sudo1/dead.letter... Saved message in /home/sudo1/dead.letter
where from=sudo1@my_hostname
message fails to sent


sudo su sudo2
mailx -s "Test mail" someone@example < /tmp/test.file
where from=sudo2@my_hostname
message successfully sent and received.

Not getting why with one prefix it is sent and other fails ... ?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Panagiotis ToumpaniarisSystem Architect

Commented:
The mail server is on the same machine? Can you see in the logs (/var/log/mail*) if there are entries concerning this failure?

Author

Commented:
yes they are on same machine ...
and i only found syslog ..in /var/log

cd /var/log
ls -l mail*
mail*: No such file or directory

ls -l sys*
syslog
syslog.0
syslog.1
syslog.2
syslog.3
syslog.4
syslog.5
syslog.6
syslog.7
Panagiotis ToumpaniarisSystem Architect

Commented:
which mail server are you using? If you are using sendmail then you are right, the logs should be in syslog under the LOG_MAIL facility.
How to Generate Services Revenue the Easiest Way

This Tuesday! Learn key insights about modern cyber protection services & gain practical strategies to skyrocket business:

- What it takes to build a cloud service portfolio
- How to determine which services will help your unique business grow
- Various use-cases and examples

Author

Commented:
yes we are using sendmail...
Most Valuable Expert 2015

Commented:
Perhaps it's not a sudo mailx issue but a sudo permission issue for that file in the tmp directory.

Author

Commented:
the file has 777 permission on it ... we thought so initially ... but it did not work
Most Valuable Expert 2015

Commented:
Have you run strace?

Author

Commented:
as i said earlier we were able to send the file using another sudo id .. sudo1 is not working but sudo2 is
Most Valuable Expert 2015

Commented:
I read what you said earlier and obviously this is broken otherwise you would have asked for help.  Have you run strace?

Author

Commented:
nope not able to run it as it gives error
strace mailx
 
ERROR: unable to open /dev/log

not having permission
but the log last update date was Mar  4  2014

Author

Commented:
sorry (Jan Springer) if u felt i was rude earlier .... but i am exactly not getting what have happened ... as nothing has changed from our side
Most Valuable Expert 2015

Commented:
grep sudo1 /var/log/maillog*

Author

Commented:
we have syslog ... since we use sendmail ... not maillog*... i could paste you the content of that if u like ...
Most Valuable Expert 2015

Commented:
Sendmail uses syslog and typically writes to maillog.

What is your OS?  What version?  Does it use selinux?

Author

Commented:
my OS is sun solaris ... version SunOS 5.10
Most Valuable Expert 2015

Commented:
Try running that command with "truss" instead of "strace"

Author

Commented:
ran the command with both sudo1 and sudo2 id for mpack
truss mpack ...
but no diff in any thing between the both id...
russ -c mpack
An input file must be specified
mpack version 1.5
usage: mpack [-s subj] [-d file] [-m maxsize] [-c content-type] file address...
       mpack [-s subj] [-d file] [-m maxsize] [-c content-type] -o file file
       mpack [-s subj] [-d file] [-m maxsize] [-c content-type] -n groups file
 
syscall               seconds   calls  errors
_exit                      .000       1
write                     .000       6
open                     .000       6       1
close                     .000       5
getpid                   .000       1
execve                  .000       1
sigfillset               .000       1
getcontext          .000       1
setustack            .000       1
mmap                 .000      26
munmap            .000       8
getrlimit              .000       1
memcntl             .000       6
sysinfo                .000       1
resolvepath        .000       7
stat64                   .001      18      12
fstat64                  .000       1
                     --------  ------   ----
sys totals:              .003      91     13
usr time:                .004
elapsed:                 .040
Most Valuable Expert 2015
Commented:
This:

sudo su - sudo1

strace mailx -s "Test mail" someone@example < /tmp/test.file
Distinguished Expert 2017

Commented:
More /etc/syslog.conf to see whether you are dumping mail.* to /dev/null
/var/adm/messages might contain mail related error, refer to syslog.conf

You might have restrictions mailx is a graphical,
Try
echo "To: somerecipient
From: sender
subject: test

This is a test" | /usr/lib/sendmail -oi -fsender_email -t

See what happens

Author

Commented:
hey .. i tried using truss to check with mpack ...
the only diff that came is ..
/home/suod1 => truss mpack -s "`date '+%m%d%y'` TEST MAIL" -d /tmp/test_mail_msg1.txt -m 6000000 /tmp/test_mail_attach1.csv "someone@example.com"
    Manu(8:40:14 AM):execve("/usr/bin/mpack", 0xFFBFE794, 0xFFBFE7BC)  argc = 9
/home/suod2 => truss mpack -s "`date '+%m%d%y'` TEST MAIL" -d /tmp/test_mail_msg1.txt -m 6000000 /tmp/test_mail_attach1.csv "someone@example.com"
 execve("/usr/bin/mpack", 0xFFBFE794, 0xFFBFE7BC)  argc = 9

Manu is one of the users present in the server .. but does not have the sudo access ...
Most Valuable Expert 2015

Commented:
This is not copy/paste?

Author

Commented:
yeah ... was a copy paste error ... now i see the first diff comes here..
stat64("/usr/bin/mpack", 0xFFBFE258) = 0
stat64("/usr/SUNWspro/lib//libsocket.so.1", 0xFFBFD9B8) Err#2 ENOENT
Most Valuable Expert 2015

Commented:
You probably need assistance with someone that's familiar with Solaris.   I'm sorry but the debug does not help me.
Distinguished Expert 2017
Commented:
truss -f if you want the display to follow any and items that get triggered as a consequence.

Check sendmail configs in /etc/mail whether you are explicitly permitting/authorizing users..

I doubt the issue is with the client,  /var/adm/messages and/or look at /etc/syslog.conf to see where mail.* events are directed to...


ps -ef | grep sendmail

Author

Commented:
thanks !! the mail was getting blocked as id was blocked... now the id is unblocked... everything seems to be fine ..

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial