Re: [SLE] Local mail delivery refused
Hi As has been obvious from the start, there is a permission problem - but what and where? I have been able to track the problem down. During my experiments, I noticed that occasionally mails got through, and when that happened the header file (qfg*) and data file (dfg*) in /var/spool/clientmqueue seemed to have the permissions 600 rather than 660. Systematic checking proved the point. When run by root, 'mail' dumps the two files with permissions 660. When 'sendmail -q -v' was run, the header was declared bogus. I looked through 'sendmail.cf', and found that under the 'options' sections, the file permissions were required to be 600. Changing the latter to 660 and restarting sendmail enabled mails from root to work perfectly. However, when mail was run as user bjfowler, the data file was never written to clientmqueue. But when the permissions to the clientmqueue directory were set to 777 (dangerous permissions according to /var/log/mail), everything worked perfectly. To use sendmail as mailer for Kmail still requires sendmail to have suid set. I still have to try to find a solution that gets rid of the necessity for dangerous permissions, but at least I have _a_ solution. What are the settings in your sendmail.cf file? Thanks for your help Basil On Saturday 27 Jul 2002 00:54, you wrote:
Hi again, so I checked also the comp.mail.sendmail newsgroup ... it is a permission problem ... but I cannot see where because your permissions on the /var/spool directory are o.k. ... what says your /usr/sbin/sendmail?
Oliver -- ... don't touch the bang-bang fruit
On Sat, 27 Jul 2002, Basil Fowler wrote:
Hi
As has been obvious from the start, there is a permission problem - but what and where?
I have been able to track the problem down. During my experiments, I noticed that occasionally mails got through, and when that happened the header file (qfg*) and data file (dfg*) in /var/spool/clientmqueue seemed to have the permissions 600 rather than 660. Systematic checking proved the point.
When run by root, 'mail' dumps the two files with permissions 660. When 'sendmail -q -v' was run, the header was declared bogus.
Your problem is to send local mail ... but local mail is send directly to the user and not stored in /var/spool/clientmqueue.
From /usr/share/doc/packages/sendmail/SECURITY file you get:
[...] If the option UseMSP is not set, sendmail will complain during queue runs about bogus file permission. If you want a queue runner for the client queue, you probably have to change OS specific scripts to accomplish this (check the man pages of your OS for more information.) You can start this program as root, it will change its user id to RunAsUser (mail by default, recommended uid: 8). This way mail does not need a valid shell. [...]
I looked through 'sendmail.cf', and found that under the 'options' sections, the file permissions were required to be 600. Changing the latter to 660 and restarting sendmail enabled mails from root to work perfectly.
However, when mail was run as user bjfowler, the data file was never written to clientmqueue. But when the permissions to the clientmqueue directory were set to 777 (dangerous permissions according to /var/log/mail), everything worked perfectly.
From /usr/share/doc/packages/sendmail/SECURITY file you get:
[...] That is, the owner of sendmail is root, the group is mail, and the binary is set-group-ID. The client mail queue is owned by mail with group mail and is group writable. The client mail queue directory must be writable by mail, but it must not be accessible for others. That is, do not use world read or execute permissions. In submit.cf the option UseMSP must be set, and QueueFileMode must be set to 0660. submit.cf is available in cf/cf/, which has been built from cf/cf/submit.mc. The file can be used as-is, if you want to add more options, use cf/cf/submit.mc as starting point and read cf/README: MESSAGE SUBMISSION PROGRAM carefully. [...]
To use sendmail as mailer for Kmail still requires sendmail to have suid set. I still have to try to find a solution that gets rid of the necessity for dangerous permissions, but at least I have _a_ solution. What are the settings in your sendmail.cf file?
What you need to change is your submit.cf ... here is my submit.mc setting: include(`/usr/share/sendmail/m4/cf.m4') divert(0)dnl VERSIONID(`$Id: submit.mc,v 8.5 2001/09/08 01:20:53 gshapiro Exp $') define(`confCF_VERSION', `Submit')dnl define(`__OSTYPE__',`')dnl dirty hack to keep proto.m4 from complaining define(`_USE_DECNET_SYNTAX_', `1')dnl support DECnet FEATURE(`use_ct_file')dnl FEATURE(`msp')dnl To summarize: Using Kmail as your MUA shows problems when sending local mail via sendmail ... internet mail works o.k.(?) ... sendmail complains during queue runs about bogus file permission ... you configured sendmail.cf via YAST ... and your permissions are as this: [...] -r-xr-sr-x root mail ... /PATH/TO/sendmail drwxrwx--- mail mail ... /var/spool/clientmqueue drwx------ root wheel ... /var/spool/mqueue -r--r--r-- root wheel ... /etc/mail/sendmail.cf -r--r--r-- root wheel ... /etc/mail/submit.cf [Notice: On some OS "wheel" is not used but "bin" or "root" instead, however, this is not important here.] [...] So to find a solution you have to change your submit.cf because of: [...] sendmail.cf For the MTA (mail transmission agent) The MTA is started by root as daemon: /PATH/TO/sendmail -L sendmail -bd -q1h it accepts SMTP connections (on ports 25 and 587 by default); it runs the main queue (/var/spool/mqueue by default). submit.cf For the MSP (mail submission program) The MSP is used to submit e-mails, hence it is invoked by programs (and maybe users); it does not run as SMTP daemon; it uses /var/spool/clientmqueue by default; it can be started to run that queue periodically: /PATH/TO/sendmail -L sendmail-client -Ac -q30m [...] Oliver -- ... don't touch the bang-bang fruit
participants (2)
-
Basil Fowler
-
Oliver Fuchs