Dallman Ross wrote:
Kevin Wu [mailto:tessar(_at_)bigfoot(_dot_)com] wrote:
Dallman Ross wrote:
On Tue, Apr 29, 2003 at 04:45:01PM -0700, Kevin Wu wrote:
I confess that I didn't look that hard at your log output; but
I did skim it briefly, and I didn't see why. However, if your
mail is arriving on a separate server to that under which your shell
account is running, that could be one explanation. That is how
things operate at the shell provider I use as my main account
and under which I run procmail. Can you rule that out categorically
as a possibility?
Yes. I use a server behind my company's firewall as both my IMAP server
and NFS file server. My home directory is on a local disk of this
server. My mail is delivered to this server. My workstation uses NFS to
mount my home directory from that server. My mail client accesses my
mail drop via IMAP, and the mail folders are in my home directory. I can
log into the server since my network password is the same on all the
machines here thanks to NIS. I did this to test the message in a test
directory. The platform should be the same for production mode and
subsequent testing when I log onto the server.
Try putting this near the top of the .procmailrc,
from the recipe through the close-quote below the log entry:
:0 hi # this is an assignment recipe, not a delivering one
PROCV_OUT=| procmail -v 2>&1 | sed '2,10d; s/^/ /'
LOG = "
HOST is $HOST
Version info is
$PROCV_OUT
"
I just put something similar inside the traffic report recipe since I
don't want the debugging output for every delivered message. I also want
the information to be correct when I test in a test directory so I did this:
:0
* ^From:.*(\<)KPIX\.Traffic\.Router
{
# Debug traffic report filtering.
#
LOG = "HOST is $HOST
Procmail version: $PROCMAIL_VERSION
"
[ remainder deleted ]
After receiving a traffic report, I can confirm that the mail server and
the test machine (after logging into the server) are the same.
Well, as I said, I haven't tested it; but the logic I had in
mind should, indeed, work. The negation (bang on the condition)
says that if we find a $LOCATIONS *not* within two (or was it
three?) lines of "road work", perform the action. It won't
matter how many times a $LOCATIONS *is* next to "road work",
as long as there's one or more times when one *isn't*.
Try it and let me know!
I tried it in my test directory, and it does not work when the traffic
report only contains road work incidents. Both conditions are satisfied
and the action is executed (delivered to me). This a traffic report that
I don't want to see since it has only road work events so it should be
deleted instead of delivered.
I think I finally have a proper spin on my question now. Suppose that I
am submitting a bug report for procmail. The bug report contains the
original recipe and sample message body as before, both of which cannot
be altered. The diagnostic output for the two cases is part of the bug
report description too. So the question becomes, "Is this a valid
procmail bug for the given input? If so, is the source of the problem in
procmail itself or the system components used by procmail?". I don't
know enough about the internals of procmail and its dependencies on
system libraries to answer that question. If I could get some pointers
on how to instrument procmail to yield more information, that would be a
big help.
Thanks,
Kevin
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail