procmail
[Top] [All Lists]

Re: Regexp fails in scoring recipe

2003-04-30 20:14:46
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