At 15:26 2002-02-27 -0700, Jeremy Wadsack did say:
As I said before I know nothing about Sendmail. I use usually use
Qmail because it's much simpler to configure. Likely the Sendmail is
set up with smrsh or some such. I didn't install it.
Sendmail isn't a hassle if you learn it. <g>
-rwxr-xr-x 1 billing site73 34 Feb 26 17:05 .forward
-rwxr-xr-x 1 billing site73 228 Feb 27 10:52 .procmailrc
I have changed them to this (as suggested by your disclaimer page) and
tried without any effect.
-rwx------ 1 billing site73 34 Feb 26 17:05 .forward
-rwx------ 1 billing site73 228 Feb 27 10:52 .procmailrc
Hmm, oversight on my part on that page - .forward must be world
readable. perms 704. I've updated the disclaimer page, but the procdiag
script would have raised a caution if the perms were unacceptable.
DOH! I assumed that procmail would log to the logfile I told it to
use. I didn't think to check the mail log for procmail messages. I
have this error:
procmail[17876]: Suspicious rcfile
Heh, if procmail won't OPEN the rcfile to process it, then log commands
WITHIN that rcfile won't be paid much attention to. That includes anything
defining the LOGFILE, etc.
> It will gather some info about your configuration which can help us figure
> out what is going on. Review what is returned, then post it to this list.
You'll understand if I don't release ALL that information,
It specifically blocks out the password field from the account password
line which was extracted (in case someone is enough of a looser to still be
running a non-shadow password config). The other bits are helpful for
determining some weirdnesses some people may have with external tools
they're using.
but I think
this will cover the important issue. If you need more pieces, let me
know which ones. Also, I removed the .forward file since you (and the
documentation) have stated I don't need it.
... provided that procmail is the LDA, which if /etc/procmailrc HAS been
running, is a pretty good bet.
----------------------------------------------------------------------
# formail and procmail information (as per versions in the current path):
0755 1 root root 27776 Fri Sep 3 23:21:13 1999 /usr/bin/formail
formail v3.13.1 1999/04/05, Copyright (c) 1999, Stephen R. van den Berg
Eewww. Time to upgrade. At a minimum 3.15.2
# Determining Mlocal in sendmail.cf
In /etc/sendmail.cf:
Mlocal, P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30, R=20/40,
T=DNS/RFC822/X-Unix,
A=procmail -Y -a $h -d $u
NOTE: procmail appears to be the LDA
NOTE: There is no /etc/mail/sendmail.cf file.
yup, definatley you don't need to be using .forward to run procmail, since
if it simply finds a good $HOME/.procmailrc, it'll run it.
2771 4 billing site73 1024 Wed Feb 27 16:50:36 2002
/home/sites/site73/users/billing/
CAUTION: /home/sites/site73/users/billing perms exceed 7755: curb back to 2751
Note that if "site73" us a user=group type of identifier, this sort of
caution isn't a big deal in real life, but procmail doesn't know this --
further, if user=group, there's no need to grant the group any write perms
in the first place, since the only member of that group SHOULD be the user,
who'll have whatever user perms they have as the owner.
I see the caution on the user's directory there. All user directories
are like this:
drwxrws--x 4 billing site73 1024 Feb 27 16:50 billing
Apparently the group readable
No, group WRITEABLE. 7 = rwx, 5 = r.x
is causing procmail to skip the file. Somehow I didn't get this out of the
faq / docs. So I apologize if it's there.
I suggest you check 'man procmail' and search for "suspicious rcfile" (that
message you found in the syslog after I suggested you check there). Find
anything?
Just to appease my curiosity, why is procmail concerned about group
writable ability on the user's directory when the .procmailrc file is
not group writable?
Anyone from that group can WRITE in your directory, which means they can
delete files and replace them, which is a security risk. Procmail doesn't
know who else is in the group, or whether someone else may ever be added to
the group later, and it is viewed as a security risk.
Anyway, changing this seems to have fixed the problem. I don't think I
could have found it without the diagnostic shell though.
That'd be why I scrawled that bugger up, to deal with these little gotchas
that people often overlook or otherwise involve 20 questions to dig up.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail