Jim, Bart, Cary,
Thanks for the responses. I had to be away for a couple of days to take
care of other stuff, which had the benefit of giving me some distance
from the problem, too.
Yes, it appears to be related to the match operator and greedy/stingy
behavior.
Here is a solution I've come up with which *SEEMS* to work:
:0 fhw
* ^content-type:(.*\<)?multipart.*\<(boundary=\/[^"; ]+|
boundary="\/[^"; ]+)
{
TESTVAR = $MATCH
}
Since I have two mutually exclusive cases, quoted and unquoted, only one
of the two branches will match at any time:
boundary=\/[^"; ]+ or boundary="\/[^"; ]+
For a quoted string, the first branch will stop matching on the first
character after the \/, but the second branch should match until the
trailing double-quote is reached.
For an unquoted string, the first branch matches the complete boundary
string, while the second branch will not match to the left of the \/.
It works on well behaved samples with both quoted and unquoted boundary
strings but doens't handle all possible whitespace characters after the
string.
I could try to create a [...] expression with all possible characters
(except ; and " and <space>), but it would break if I miss even one
oddball character that might turn up in a boundary string. The following
looks to be adequate after analyzing a few thousand recent list mails
and testing with several clients and webmail systems...
[-+=/_.:A-Za-z0-9]
Substituting this positive bracket expression in the above recipe
(twice!) seems to work decently well as long as the strings behave
themselves.
Instead of this, it would make the most sense to match anything except
double-quote, semi-colon, or whitespace, except that we don't seem to be
allowed to use control characters, POSIX character classes or shortcuts
( e.g.: [:space:] or \s ) inside bracket expressions in procmail? This
seems to be impossible to do:
[^";<something that stands for all whitespace characters>]
I wish I could understand why?
Cary, you say that procmail doesn't allow escaping of control
characters. Does that mean things like \f \n \r \n \t \v will not be
understood in any context? Or just inside bracket expressions? Can you
or anyone point me to where that's documented, please?
Thanks,
Mike D.
