At 18:22 2009-04-17 -0400, RGBall wrote:
The difficulty is that regexp is looking at a bunch of header information
so without the full headers of the test message(s) it isn't possible to
even start to determine what is getting caught. From your expansion of the
FROM_DAEMON headers like Resent-from:, Sender:, X-Envelope-From:, etc. are
all getting looked at not just the From: address.
The place to start is with the full email of something that always gets
caught, then break the above rule into two individually scored ones
(FROM_DAEMON as one, the rest is the other) to see which one triggers.
That should get you closer.
Let me further elaborate Rich's suggestion:
Take one of the rejected messages, complete with headers, and store it into
a file.
Take the core of the recipe which is your bane, and put it into a
standalone rcfile, like so:
# RCFILE BEGIN ---------
LOGFILE=funky.log
VERBOSE=YES
# we're not delivering the message, just checking it over and over.
DEFAULT=/dev/null
# we're simplifying this - no need for inverted scoring
# However, we've prefixed the regexp with ()\/ so that we can store the
# matched text - you should see precisely what it is matching on.
:0
* ()\/^FROM_DAEMON|\
^(((Resent-)?(From|Sender)|X-Envelope-From):|>?From )\
([^>]*[^((_dot_)%(_at_)a-z0-9])?(\
LIST(SERV|proc)|NETSERV|bounce|autoanswer|echo|mirror\
)(([^).!:a-z0-9][-_a-z0-9]*)?[%@>
][^<)]*(\(.*\).*)?)?$([^>]|$)
{
}
# RCFILE END ---------
Now, pipe your message into it:
procmail -m funky.rc < funky.msg
Or, if you have multiple test messages in a mailbox:
formail -s procmail -m funky.rc < funky.mbx
Then examine the logfile. Somewhere in there, you might find:
procmail: Assigning "MATCH="
procmail: Matched "
Precedence: junk"
or any number of other possibilities - the key thing is that by adding the
()\/ before the regexp, the verbose log will report what it matched on -
not the actual syntax of the regexp that matched, but at least the actual
text which it saw fit to trip on. Once you have that - rather than an
address - which may or may not be part of the field it is tripping on -
THEN you're prepared to examine the regexp to modify it to not trip on
these users.
I'm going to offer up my suspicion: these users may have challenge-response
systems at their ISPs which may be setting up an envelope that involves a
unique bounce handler alias (so that delivery notices get delivered to the
user rather than being challenged). As such, the envelope address may be
matching the regexp, and then rejecting these users.
You could of course just hack the smartlist rcfile, to add verbose logging
and the match construct, but I'm not a fan of using a live configuration
for testing - a typo could move you from having a couple of users who can't
mail the list to nobody being able to...
---
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