Bug 137216 - sendmail drops outgoing mail - even if configuration seems correct
sendmail drops outgoing mail - even if configuration seems correct
Product: Fedora
Classification: Fedora
Component: sendmail (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Woerner
Depends On:
  Show dependency treegraph
Reported: 2004-10-26 14:57 EDT by carlos puchol
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-28 01:43:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description carlos puchol 2004-10-26 14:57:14 EDT
Description of problem:

outgoing sendmail on an fc3t3 stock system with minor changes
drops email on the floor (losing data), even
as the configuration seems correct.

Version-Release number of selected component (if applicable):


How reproducible:

100% on my system

Steps to Reproduce:
1. default system
2. /etc/mail/sendmail.mc has
     - smart host definedm and
     - masquerade (as my domain)
   different from base config (but this "should not matter").
3. send email from mutt
Actual results:

mo mail is ever sent.

Expected results:

mail should go out.

Additional info:

i put one fct3 machine into near "production."
i noticed that sendmail dropped outgoing messages
on the floor. the error is as follows:

Oct 25 14:25:40 rome sendmail[9106]: NOQUEUE: SYSERR(cpg): can not
chdir(/var/spool/clientmqueue/): Permission denied

now - at this time, i checked and sendmail (the outgoing process)
was running as user smmsp. the /var/spool/clientmqueue/ directory had
these permissions.

drwxrwx---  2 smmsp smmsp 4096 Oct 26 00:53 /var/spool/clientmqueue/

which should have been fine, according to my research, these
permissions should be the correct ones, and the owner/group as well
is the correct one (much more so when the process is running with that
user id).

at any rate, i changed the permissions for that directory to 777
and things started working - mail would go out as expected.
i notice that now there is a process that nicely warns that these
permissions are (very appropriately!):

Oct 25 15:23:12 rome sm-msp-queue[2375]: dangerous permissions=40777
on queue directory /var/spool/clientmqueue/

since there is data loss - and this is the default configuration,
this seems like a potential issue (thus i set it as priority high).
Comment 1 carlos puchol 2004-10-27 19:06:48 EDT
note, to be more precise,
the only thing different than standard config is something that
most people downloading email will have to do and that is:

Comment 2 carlos puchol 2004-10-28 01:43:36 EDT
hi alexander,

Alexander Dalloz wrote:
> Am Do, den 28.10.2004 schrieb Carlos Puchol um 1:09:
> > Oct 25 14:25:40 rome sendmail[9106]: NOQUEUE: SYSERR(cpg): can not
+Permission denied
> > noone running into this?
> No. A test with "date | mail -s test recipient" succeeded without a
> problem.
> > -c
> With which MUA do you try to send mail? Seems the mail client running as
> user cpg tries to directly feed the submission queue. So it is a task to
> configure your client properly.

i use mutt. from what you say, i am guessing that the cpg in
SYSERR(cpg) means
that the id under which it is run is cpg. in that case, the issue
is understandable that the process cannot go into the clientmqueue.

> Or which permissions does the /usr/sbin/sendmail.sendmail binary have?

interesting that you ask that. turns out that it was actually owned
by cpg.cpg.

hmmm. not sure how that happened, since i typically
do all my work under either sudo or su.

at any rate, i changed it to smmsp.smmsp and tried again, but got the
same issue. furthermore, i got it with the example you mention:

[22:12:50](2)rome:~$ date | mail -s test myuser@mydomain.com
WARNING: RunAsUser for MSP ignored, check group ids (egid=100, want=51)
can not chdir(/var/spool/clientmqueue/): Permission denied
Program mode requires special privileges, e.g., root or TrustedUser.

that clearly indicates that the user id _is_ the issue.

[22:23:38](2)rome:~$ id cpg
uid=500(cpg) gid=100(users) groups=100(users)
[22:23:43](2)rome:~$ id smmsp
uid=51(smmsp) gid=51(smmsp) groups=51(smmsp)

i removed the rpm, but i took a look at the permissions before doing that:

22:24:38](3)rome:cpg# ll -L /usr/sbin/sendmail*
-rwxr-xr-x  1 smmsp smmsp  748296 Sep  1 03:20 /usr/sbin/sendmail
-rwsr-xr-x  1 root  root  2089729 Sep 13 09:20 /usr/sbin/sendmail.exim
-rwxr-xr-x  1 root  root   141344 Aug  5 08:03 /usr/sbin/sendmail.postfix
-rwxr-xr-x  1 smmsp smmsp  748296 Sep  1 03:20 /usr/sbin/sendmail.sendmail

and the reinstalled. i got this:

[22:27:55](3)rome:cpg# ll -L /usr/sbin/sendmail*
-rwxr-sr-x  1 root smmsp  748296 Sep  1 03:20 /usr/sbin/sendmail
-rwsr-xr-x  1 root root  2089729 Sep 13 09:20 /usr/sbin/sendmail.exim
-rwxr-xr-x  1 root root   141344 Aug  5 08:03 /usr/sbin/sendmail.postfix
-rwxr-sr-x  1 root smmsp  748296 Sep  1 03:20 /usr/sbin/sendmail.sendmail

which clearly _would_ make things work. if it weren't for the fact that
the settings (masquerade and smart host) also reset. then i set them up

[22:31:12](3)rome:mail# diff sendmail.mc.rpmsave sendmail.mc
< define(`SMART_HOST',`smtp.comcast.net')
> dnl define(`SMART_HOST',`smtp.your.provider')
< FEATURE(masquerade_envelope)dnl
> dnl FEATURE(masquerade_envelope)dnl
< MASQUERADE_DOMAIN(mydomain.com)dnl
< MASQUERADE_AS(mydomain.com)dnl
> dnl MASQUERADE_DOMAIN(localhost)dnl
[22:31:33](3)rome:mail# cp sendmail.mc.rpmsave sendmail.mc
cp: overwrite `sendmail.mc'? y

then restarted sendmail a couple of times from the command line
and also from the services GUI, in case i could reproduce it.

i can't. so -- i am baffled as to how the user/group and
the setuid was changed. i am 100% certain i did not change the
permissions or user/group by hand.

thanks for your help, even though this will remain a mystery.
if nothing else, this prompted me to finally switch to postfix,
at least for outbound mail.


Note You need to log in before you can comment on or make changes to this bug.