"Eric C. Hagberg" <hagberg(_at_)ms(_dot_)com> writes:
You're correct. MATCH is only getting assigned the last header line.
So, is it more efficient to use an includerc (which could, if my reading
is right, execute many, many copies of procmail), or just execute a copy
of formail once to extract the content of certain headers and assign
a variable the value of the concatenated list? That variable could be
matched against, with scoring, to get the right result without recursion.
The recursive INCLUDERC doesn't invoke procmail multiple times: it just
tells the current procmail process to open the specified rcfile on a
new file descriptor and process it. The rcfile in the message I cited
form the archive uses one recursion (and therefore one file descriptor)
per header field that matches the desired regexp (^TO_ in this case).
If you're paranoid, you can prefix the setup with a simple test to see
how many header fields that is and scream bloody murder if the message
has more than, say, 60 recipient headers. That should keep procmail from
running out of file descriptors, and if the sender can't figure out how
to put multiple addresses in a single To: field, they deserve to lose.
In case you can't guess, I think the recursive INCLUDERC will be faster.
Feeding the message header into formail requires two forks, two pipes,
an exec, and a bunch of reads and writes. The recursive INCLUDERC needs
an open, some reading, and a close per loop. Looks cheaper to me.
Philip Guenther