Mailx command not working from one sudo ID

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 ... ?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Panagiotis ToumpaniarisSystem ArchitectCommented:
The mail server is on the same machine? Can you see in the logs (/var/log/mail*) if there are entries concerning this failure?
lishaAuthor Commented:
yes they are on same machine ...
and i only found syslog /var/log

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

ls -l sys*
Panagiotis ToumpaniarisSystem ArchitectCommented:
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.
Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

lishaAuthor Commented:
yes we are using sendmail...
Jan SpringerCommented:
Perhaps it's not a sudo mailx issue but a sudo permission issue for that file in the tmp directory.
lishaAuthor Commented:
the file has 777 permission on it ... we thought so initially ... but it did not work
Jan SpringerCommented:
Have you run strace?
lishaAuthor Commented:
as i said earlier we were able to send the file using another sudo id .. sudo1 is not working but sudo2 is
Jan SpringerCommented:
I read what you said earlier and obviously this is broken otherwise you would have asked for help.  Have you run strace?
lishaAuthor 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
lishaAuthor 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
Jan SpringerCommented:
grep sudo1 /var/log/maillog*
lishaAuthor Commented:
we have syslog ... since we use sendmail ... not maillog*... i could paste you the content of that if u like ...
Jan SpringerCommented:
Sendmail uses syslog and typically writes to maillog.

What is your OS?  What version?  Does it use selinux?
lishaAuthor Commented:
my OS is sun solaris ... version SunOS 5.10
Jan SpringerCommented:
Try running that command with "truss" instead of "strace"
lishaAuthor 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
Jan SpringerCommented:

sudo su - sudo1

strace mailx -s "Test mail" someone@example < /tmp/test.file
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,
echo "To: somerecipient
From: sender
subject: test

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

See what happens
lishaAuthor 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 ""
    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 ""
 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 ...
Jan SpringerCommented:
This is not copy/paste?
lishaAuthor 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//", 0xFFBFD9B8) Err#2 ENOENT
Jan SpringerCommented:
You probably need assistance with someone that's familiar with Solaris.   I'm sorry but the debug does not help me.
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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
lishaAuthor Commented:
thanks !! the mail was getting blocked as id was blocked... now the id is unblocked... everything seems to be fine ..
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.