At 12:34 2009-02-10 -0600, Christopher L. Barnard wrote:
I forced this by sending a test message. Yes, I could force this by
rerunning the message as well. Dumping the full message headers
indicate that the From: line does in fact have a single space after it:
From: root on nbmaster001
<root(_at_)rudun-nbmaster001(_dot_)cc1(_dot_)rush(_dot_)edu>
^^^^^^^^^^^^^^^^^^^^^^
The address isn't the first token after the From: leader, and the address
itself is encapsulated in brackets. This doesn't stand out at you that
your original regexp was matching for From: followed by EXACTLY ONE
CHARACTER followed by the address, or that the revised regexp is matching
for any number of spaces or tabs between the header name and the
address. Neither try is expecting other junk in between the From: and the
address.
Try replacing the condition line matching the From: content with:
* ^From:.*<root(_at_)rudun-nbmaster00(1|2)\.cc1\.rush\.edu>
If you'd started this thread by showing actual message headers along with
your attemped recipe, this would have been clear from the start.
the From: I am talking about; if I do not tell my mailer to explicitly
dump the headers it writes the 'From: ' as 'From '.
That's a unique interpretation of how to do things.
Note that what your MUA is displaying - especially if it does stupid things
like that - isn't necessarily what the message arrived as. Procmail
doesn't give a whit how your MUA will display things - it's operating on
the ACTUAL message as passed to it by the MTA. When you want to see
message headers, best to use a tool you know isn't "fudging" things.
So it looks like the From: line of the message should match the rule
exactly, but it still thinks there is no match...
I don't see how the rule would match the From: line you give above.
Oh, Sean, just to let you know since you mention this in your
disclaimer. I am running this on my server "sandbox.test.rpslmc.edu".
Thats why I can change things at will. This is my sandbox...
That's great - but a sandbox setup allows for pumping saved messages (from
a mailbox for instance) right into the test recipes:
procmail -m sandbox.rc < some_saved_message
Tweak the recipe, rerun message processing on the saved message. No
waiting for the next backup cycle to see if your most recent stab at trying
to get something to work is really going to work.
Got a pile of messages? Use formail to split them up:
formail -s procmail -m sandbox.rc < some_saved_mailbox
(caveat: in both cases, the source message/mailbox should not also be a
destination used by the recipes in the sandbox)
Along with some additional components, such as the sendmail shell script,
you can transparently capture messages which your recipes would forward -
which is useful when people are trying to figure out why they get mail
loops whenever they test their recipes in a live environ.
In my experience, the fewer things that need to be tweaked between testing
and deployment, the better - if the sandbox environ deals with setting up
verbosity and providing an envelope around the recipe, then the recipe
itself doesn't need changes to be tested, and can then be migrated directly
into a live mail environment once it has passed testing, without "fiddling".
BTW, my sandbox setup includes some extraction of commonly-desired message
elements (FROM as an address for instance, or the domain portion only),
useful for checking greenlists, blacklists, or doing simple checks like
you're trying to accomplish.
* CLEANFROM ?? ^^root(_at_)rudun-nbmaster00(1|2)\.cc1\.rush\.edu^^
---
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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail