Comments inline.
At 17:25 2003-12-08 -0800, Mike Richards wrote:
Have you checked the message to see whether X-Loop is indeed set on
the
received copy?
The received copy does indeed have the X-Loop header in it.
Well, as the COPY you're going to see will have been tweaked by formail
before finding it's way into $DEFAULT, this isn't unexpected - but what
about BEFORE formail tweaks it?
:0c
| formail -A"X-Loop: something_a_bit_more_unique_to_you" \
| $SENDMAIL copy(_at_)domain(_dot_)com
I've tried this exactly to no avail. The error message I get from
procmail
is as below:
That invocation works perfectly fine when invoked from my sandbox (I
didn't
check it BEFORE sending, but when you reported it didn't work, I did a
sanity check).
I'll just clarify a few things that might make this easier. I have a test
system that is built purely for the purpose of testing this procmailrc
script. I have written copies of the message in the procmailrc file both
before and after the header re-write. The first message through does NOT
contain the header until after formail writes to it. Every subsequent
"looped" message DOES contain the header but the header is NOT matched by
the regexp in the procmailrc to disregard further processing. I will give
an example of a fully bloated test procmailrc. I also control the system
that is receiving the one copy that is e-mailed out of the system.
originally I was using :0fwh with the formail command (from a previous
e-mail on this subject) which writes formail and then keeps the output after
that is done to be further processed (subsequently used in the next command
which was the carbon copy recipe in that case).
SHELL=/bin/sh
LOG="SHELL is $SHELL
SENDMAIL is $SENDMAIL"
LOGFILE=/var/log/procmaillog
VERBOSE=yes
:0c
/var/log/preprocess
:0
* ^X-Loop:\ copy
/dev/null
:0c
/var/log/archive
:0c
|formail -A"X-Loop: copy"\
|$SENDMAIL copy(_at_)domain(_dot_)com
:0c
/var/log/forward
I am 100% convinced that the regexp is simply failing to match, I have made
about every change to the regexp I can imagine that would cause it to fail
for spaces or whatever, the reason it is so simple is to bring it to least
possible margin of error. I know that the regexp worked in my sendmail
environment but not in my Qmail environment. I have suspected permissions
except that if formail is allowed (and has successfully) written the header
information "X-Loop: copy" for me why can't it be matched by procmail? It
NEVER sees it when in this Qmail environment. I just need to focus on this
one aspect of the problem as sending the mail and writing the header and
getting copies all work fine. Again your help is thoroughly appreciated.
procmail: Executing "formail -A"X-Loop: copy"\
|$SENDMAIL copy(_at_)domain(_dot_)com "
one: that's obviously not _exactly_, since you changed the tag text.
procmail: Unlocking "/var/mail/alias.lock"
two: you should show the logfile back to the point where it shows this
being LOCKED.
/nonexistent: Can't open /nonexistent: No such file or directory
three: that looks like a bogus SHELL definition.
You were right and defining the $SHELL=/bin/sh explicitly fixed this
particular problem. Thanks!
If you set up a SANDBOX (see my .sig for a starting point), it'd be a LOT
easier to diagnose this problem since you'd COMPLETELY ISOLATE YOUR
PROCMAIL ISSUES FROM YOUR MTA ISSUES. In a sandbox, you redirect messages
from a file, so you know exactly what you're sending in, and in the case
of
my sandbox setup, $SENDMAIL is redefined to a shell script that saves the
message to a file so you can see how the MTA was being invoked.
I have looked at the sandbox issue and will get into it if I have to
although I would prefer not to as I am quite confident of the information
flowing through procmail based on the carbon copies I make before , during
and after processing. Are you saying that the MTA might be hiding the
X-Loop header from procmail during that step somehow? If so it would also
be hte reason X-Header-Added: did not work? and if that is true it is
completely useless to me regardless :) I also might not want to learn that
that is true if it is :)
You could run it in the sandbox, then from the MTA, and compare the
VERBOSE
output to see where they differ.
Please add these to your rcfile:
LOG="SHELL is $SHELL
SENDMAIL is $SENDMAIL
"
Then send yourself a test message and see what gets logged. I'm going to
guess the SHELL is boffed. In which case, perhaps you could try setting
it
explicitly:
SHELL=/bin/sh
This would relate to trying to invoke a shell to run the pipelined
formail|$SENDMAIL, and failing if your $SHELL is defined oddly.
Please note that your original post did not include any log information,
so
I've no idea if this seems like a new error to you, or was appearing in
some form before.
This particular error wasn't new but I have used many different methods of
doing this but the regexp is the only part that matters and has stayed
mostly the same. It is the only part that is consistently failing through
all methods of trying to get a match.
---
Sean B. Straw / Professional Software Engineering
Thanks!
Mike
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail