At 17:34 2002-07-05 +0100, Luis Oliveira wrote:
Hi,
Hi. Please consider turning off your fonts and other nifty features in
your email to this list. It's unix. We like plaintext.
I'm just trying to put procmail at work, but I'm having some problems that
I hope to fix with you guys. I think I followed the basic instructions,
like creating the .forward file in the user home directory with the
following contents:
[snip]
... and what exactly is or is not happening? What is your procmai log showing?
Are you sysadm of the machine, or just some user? If sysadm, have you
checked the system and mail log(s) to see if there are errors listed there,
say about "suspicious rcfiles" or other security issues? Almost
universally, when people have a problem even getting procmail to invoke on
their messages, it's because their files have bad security settings.
See the "procdiag" script linked from my .sig.
"|IFS=' ' && p=/usr/bin/procmail && test -f $p&&exec $p -f-||exit 75
#username"
Q: are you sure that procmail isn't your LDA already? If it's the LDA (as
defined by the MTA), then the .forward construct isn't even required.
On the .procmailrc file I have this:
PATH=/usr/bin:/bin:/usr/local/bin
You shouldn't need to redefine this unless you have a specfic situation
that demands it. Procmail will set a reasonable path to start with.
MAILDIR=/var/spool/mail
No. MAILDIR should be the a directory belonging to *YOUR* user. Setting
it this way won't suddendly cause failures, but when you opt to include an
RCfile, or write messages to another dir, procmail will attempt to do it in
THAT directory (unless you're providing a hardcoded path to elsewhere). In
effect, procmail is changing directories to the specified directory when
you define this variable. That isn't called for here - not THAT directory
at least. More typically, it is set to something like:
# dir must first EXIST though
MAILDIR=$HOME/Mail
(or wherever your MUA puts read email)
DEFAULT=$MAILDIR/username
There should be absolutely no reason for you to redefine this. It gets
redefined for advanced uses - leave it alone unless you have an express
reason to change it. Refer to 'procmail -v' to see what procmail believes
it should be delivering to.
LOGFILE=$HOME/.log
LOCKFILE=$HOME/.lockmail
Don't set lockfile unless you have a specific need to.
VERBOSE=yes
What does the verbose logfile say at this point?
:0
* ^From.*username2
! username3
Syntactically correct, though you should note that this will Match within
either "From " (the mailbox header - the _sender_), or "From:" (the mail
header), or any other construct beginning with "From". You should
therefore either expressly include a space or a colon. Also, not that it
should have a bearing on your situation here, but where you might have dots
'.' in the username2 address (used in the condition expression), you should
escape them: '\.', because by itself, a dot is a wildcard (as in '.*' -
which is zero or more of whatever), where within an address, you want them
to be interpreted as dots: someuser(_at_)their\(_dot_)domain\(_dot_)tld
No doubt, your script isn't _EXACTLT_ as you provided it, and you exercised
some license in changing things to protect the innocent -- in the process,
you might actually change the reason something doesn't work.
Note that you really really really don't want to do a simple forward if
that forward address might resolve to you (or they might forward to you).
This must be something very simple but I'm not just getting it done. The
MTA is sendmail, procmail v3.13.1, and this on a SuSE 6.3 machine.
FTR, you really should upgrade procmail, at least to 3.15.2.
---
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