I wasn't aware of the fact that /etc/procmailrc wouldn't work.
The real system accounts don't use the mail service, so I
could savely play with the mail config without risking any loss.
Within the past year, not a single user has received a mail on
his system accout; they don't even use it. All their mail-accounts
are hosted on diff servers.
The path generation in my procmailrc is correct so far, since
the system accounts aren't used at all. I now moved /etc/procmailrc
to /mail, defined a shell and everything is working now.
Thanks!
------------------------
At 11:44 2002-12-19 +0100, sven did say:
Ok, I continued playing around with procmail for about 2 hrs now...
I can't imagine that it would have taken nearly that long to implement what
I suggested.
I added the following line to /etc/aliases:
foo.bar.com: "|procmail -m /etc/procmailrc foo.bar.com"
Bzt. Uhm, no, let me hook these electrodes to you...
BZZZZT!
I *DID* *NOT* advise you to use /etc/procmailrc (which procmail invokes
when running as the LDA - for "normal" mail accounts - you know, the ones
that are already working fine), I specifically indicated to use some other
one:
foo.bar.com: "|procmail -m /etc/procmailrcs/popmail.rc
/mail/users/foo.bar.com"
Whether you want to specify the mailbox file, or just the username portion
for $1 is up to you and how you actually manipulate it - certainly, if
you're pulling up options from a database, it makes sense to specify it as
a username portion only.
and the /etc/procmailrc contains things like this:
<--snip-->
BASEDIR
LOGFILE
VERBOSE
LOGABSTRACT
USER
This is inappropriate for invocation as the LDA - $1 is this user id only
when being invoked from the alias above, not when /etc/procmailrc is
*AUTOMATICALLY* being used by the LDA. The paths you're specifying
certainly can't be right for the normal users who are supposed to take
delivery in /var/spool/mail?
I hope you don't receive a lot of normal mail on this host, because it's
all getting misdirected right now, and depending upon the parts of your
rcfile which you chose to not disclose, may have been discarded or bounced.
Remember, your _real_ local account holders don't take mail delivery the
same way as the 'phantom' pop-only users -- those are the people whose
email was processed fine through the /etc/procmailrc before - which has a
*DIFFERENT* procmail invocation and a *DIFFERENT* mail spool dir.
DEFAULT
[snip] - from outward appearances, it looks like everything past this point
is probably "common" to the normal mail accounts and your phantom
accounts. SO - and this is REALLY IMPORTANT - just take it all from here
down and PUT IT INTO A SEPARATE .RC FILE AND USE INCLUDERC TO INCLUDE IT
INTO YOUR POPMAIL.RC *AND* INTO THE /ETC/PROCMAILRC - THAT WAY, YOU HAVE TO
EDIT ONLY ONE SET OF FILTERS, AND THE PROCMAILRC AND POPMAIL.RC FILES SERVE
SIMPLY AS "WRAPPERS'.
# Delivering all other mail
:0:
${DEFAULT}
<--snap-->
$DEFAULT is the default action which procmail will take if it hasn't
delivered the message -- this type of rule is wholly unnecessary except
when you want to "short circuit" following recipes and take a default
delivery early. It really isn't necessary, and *REALLY* shouldn't be in
your /etc/procmailrc because for 'normal' users who may actually have an
~/.procmailrc, you'll be disabling it, and no doubt causing endless grief
for someone trying to figure out why their darned procmail config won't work
Surely you know what that's like.
procmail: Executing "formail -x"Subject:" | expand | sed -e 's/^[ ]*//g'
-e 's/[ ]*$//g'"
procmail: Assigning "SUBJECT
FTR, your "mail" user probably doesn't have a SHELL defined, since it
shouldn't normally be able to LOG IN. You need to define:
SHELL
One of the various differences between the popmail.rc and a normal
/etc/procmailrc file, and again, why I advised you to use a separate rc
file for the phantom users.
But hey, do your own thing if self-aggravation is fun for you.
FTR, in my own /etc/procmailrc, I temporarily define SHELL anyway, so that
all the recipes in there can execute even if the user account for which
mail is being processed doesn't normally have login permissions (wherein
the shell has been refefined to something that just displays a message and
terminates - in your case, that's apparently "This account is currently not
available") - at the end of the /etc/procmailrc (before passing control to
the regular user ~/.procmailrc if it exists), I undefine it, so that the
user's own setting will take effect just as if my /etc/procmailrc was never
there:
# For users who can't log in, they don't have a valid shell! Override
# with something sensible.
ORGSHELL
SHELL
(rcfile contents)
# do this, or else the SHELL will remain redefined even when personal
# .procmailrc are used. Be a good mushroom and undefine ORGSHELL.
SHELL
ORGSHELL
# drop root privledges. Specifically, this makes the message deliver as
# per the individual user without involving logging whether they have a
# .procmailrc or not.
DROPPRIVS
However, if I add a recipie like
:0:
* test
${DEFAULT}.bla
then the mail is delivered to /mail/users/foo.bar.com.bla. So it does
match "test" in the mail.
Because it isn't using a NONEXISTANT _SHELL_ to do so - that condition is
resolved entirely within procmail, not by running another program (more
specifically one which involves the shell because you're passing it through
a series of pipes).
I 'm also wondering why I get "This account is currently not available" if
I extract the Subject instead of the subject "bla".
Take a few moments and reflect. Try to log into your machine as user
"mail" (actually log in, not 'su mail' from root), or try adding:
LOG
"
to your rcfile, near the top (somewhere after you've defined a
logfile). Keep a mirror near the terminal so that you can see the
expression on your face when you check the logfile.
Sorry for keeping you busy, but I think I'm about to reach my limits in my
procmail knowledge :-)
The important thing is to try what is suggested by the people you're asking
for assistance from before trying something not quite what is
suggested. It's the differences between what I suggested and what you
actually did which are messing you up. Deviating from the suggestions help
no one - get it working as advised, THEN, as you gain understanding, tweak
it from there.
[big snip again]
---
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
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail