This problem is really interesting.
Nenad Steric wrote:
Regarding the problem with adabas :
I tried as root to "chmod adabas /var/spool/mail/adabas",
What were the permissions/ownership on /var/spool/mail/adabas, before
and after you did this? When I try "chmod adabas foo" I get
"chmod: invalid mode" . Did you do "chown" rather than "chmod"? But
the ownership was already correct per your earlier message:
# -rw------- 1 adabas users 17319 Jan 16 13:21 /var/spool/mail/adabas
after this adabas could read the emails,
but then procmail showed error-messages that it wanted to
rename /var/spool/mail/adabas but didn't succeed,
Strange!
Here's a question: If as root you send email to a local user like
"hareter"... does the mail get delivered properly?
Yes.
Aha!
...
If you're logged in as root, can you say, e.g.,
mail -f /var/spool/mail/adabas
and read messages that way?
Yes.
Are there any /var/spool/mail/*.lock files?
No.
You say your local users can send to remote users but not to each
other. Can a remote person send mail to a local user successfully?
Yes .
Except for the "chmod adabas" thing, this sure sounds like a
permissions problem on / since the other directories look OK.
What was the result of
ls -ld /
?
By the way, can one of your non-root users (like hareter or adabas)
successfully execute
ls -l /var/spool/mail/[ah]*
? Just curious.
Here's what I think so far. When (e.g.,) hareter sends mail to
adabas, all locally, sendmail runs on hareter's behalf and with
hareter's uid. It then tries to write into /var/spool/mail/adabas,
which doesn't work because permissions are 600 with gid=users.
On the other hand, if mail is sent from a remote user (or if mail is
sent from root on the localhost), then sendmail is executing as root
and has enough permission to write everything.
Well, since I can't just login to your box, maybe I could suggest this.
First...
chgrp mail /var/spool/mail
chown 2775 /var/spool/mail
which forces all created files in /var/spool/mail to have gid mail.
You should also execute
chgrp mail /var/spool/mail/*
so that all EXISTING mailboxes have group-id "mail". Then...
chgrp mail /usr/local/bin/procmail # or wherever procmail is
chmod 2555 /usr/local/bin/procmail # ditto
forces procmail's gid to "mail" whenever it's executed.
Finally, you need to make sure all mailboxes have permissions 760
rather than 600. For new mailboxes, this line in /etc/procmailrc
should help:
UMASK=007
For existing mailboxes, say
chmod u+x,g+rw /var/spool/mail/*
or
chmod 760 /var/spool/mail/*
Rationale? The procmail(1) manpage says
If /var/spool/mail/$LOGNAME already is a valid mailbox,
but has got too loose permissions on it, procmail will
correct this. To prevent procmail from doing this make
sure the u+x bit is set.
All these combined should do the following.
1. make mailboxes have gid=mail with permissions at least 660
2. make procmail execute with gid=mail so it can read/write all
them mailboxes
--
Neither I nor my employer will accept any liability for any problems
or consequential loss caused by relying on this information. Sorry.
Collin Park Not a statement of my employer.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail