John Hardin wrote:
On Thu, 29 Apr 2010, Kris Deugau wrote:
> I don't see anything obviously wrong with the root From == To meta
> subrules:
> > header __TO_EQ_FROM_1 ALL =~ >
/\nFrom:[^\n<]{0,80}<?([^\n\s>]+)>?\n(?:[^\n]{1,100}\n)*To:[^\n]+\1/ism
> header __TO_EQ_FROM_2 ALL =~ >
/\nTo:[^\n<]{0,80}<?([^\n\s>]+)>?\n(?:[^\n]{1,100}\n)*From:[^\n]+\1/ism
If there were no angle brackets it would only capture the last character
of the first address. The part of the RE before <? grabs the rest.
Ahhh, OK, I see that now.
The current versions are:
header __TO_EQ_FROM_1 ALL =~
/\nFrom:\s+(?:[^\n<]{0,80}<)?([^\n\s>]+)>?\n(?:[^\n]{1,100}\n)*To:\s+(?:[^\n]+<)?\1[>,\s\n]/ism
header __TO_EQ_FROM_2 ALL =~
/\nTo:\s+(?:[^\n<]{0,80}<)?([^\n\s>]+)>?\n(?:[^\n]{1,100}\n)*From:\s+(?:[^\n]+<)?\1[>,\s\n]/ism
I stuck these in a tmp.cf on one of the production servers; that seems
to have fixed things. Until the next edge case comes through the mail
stream here. <g>
Yow. If you can provide me with a couple of examples of that I'll see if
I can figure out what's going on...
I went through so many combinations and permutations I lost track of
specifics, but starting with the message I posted here:
http://pastebin.com/X2ZUNAYM should show the misbehaviour wrt other
headers' existence or contents interfering with this particular test.
Of course, now that I look at it again I can't trigger the problem...
*headdesk* Knowing about the last-char-of-first-address issue now I can
see how some of the tests I tried would produce odd results. I have a
feeling I also got some of the sets of changes munged together.
-kgd