Procmail egrep regex problem...

I'm doing this on the system I have this e-mail account with, 
eskimo.com. It's an old-fashioned geek's ISP, where I have a shell 
account on a shared server, rather than a slice, or fancy web-thingies 
to handle everything. They're running up-to-date procmail, smartlist 
and sendmail.  

I've asked support if there are any local configuration considerations 
that might be affecting things. I should have a reply in a day or so.  

The issue I have is things that ought to work don't, and I suspect 
something about the context prevents it, or else I've missed something 
I'm supposed to be doing, like escaping characters or putting ticks or 
quotes around the regex... though I've not seen any examples that tell 
me I should.  

I'm trying to extract the boundary string from multipart MIME formatted 
messages into a variable so I can do futher processing. This is 
happening in rc.local.s00.  

The header data will look like a variation on these examples:

Content-Type: multipart/alternative
boundary="a=bunch-of/stuff:and_random=junk"

Content-Type: multipart/alternative;
   boundary=a=bunch-of/stuff:and_random=junk

What's reliable is Content-Type: multipart/* occurs on one line; the 
boundary string will not contain quotes, backslashes, semicolons or 
whitespace; the boundary string is either at the end of the first line 
or on a line of its own; whether multi-line or concatenated, the 
various pieces are separated by semicolons or whitespace.   

As I understand it, the egrep for procmail recipe condition lines 
assumes the c flag, and treats multi-line headers as single lines. 
Thus, the following recipe works up to a point, even though the '.' 
token should not ever match a newline.   

I know there are recipes out there for doing this, but I'm stumped as 
to why the following approach doesn't work (yet) and am trying to learn 
the reason before I just give up and do something else.   

Here's the basic strategy:

TESTVAR = 'some initial value'

:0 fhw
   * ^content-type:.*multipart.*boundary=\/.*
   {
       TESTVAR = $MATCH
   }

In the two examples above, it yields the following in $TESTVAR:

Example 1) "a=bunch-of/stuff:and_random=junk"

Example 2) a=bunch-of/stuff:and_random=junk

One initial oversight of this recipe is that it won't deal with a multi-
line header where there's another sub-header after the boundary= line. 
It would just tack on the rest of that header, right to the end of the 
last line. It ought to be easy to stop at the end of the boundary 
string, but it's not, as I explain below.  

At this point, I start to hit a brick wall. Nothing that's supposed to 
work seems to work in this context...   

I'd like to get rid of the quote marks. This recipe will strip the 
leading quote, at least, but will not match anything if the boundary 
string is unquoted, as it is on many messages:   

:0 fhw
   * ^content-type:.*multipart.*boundary="\/.*

The following ought to solve that problem by matching either 0 or 1
occurrences of the double quote after the equals sign:

:0 fhw
   * ^content-type:.*multipart.*boundary="?\/.*

It doesn't. The string still shows up in $MATCH and $TESTVAR with both
quote marks intact. WHY?

Every other syntax I've tried (dozens of them!) refuses to function in 
this context, either not changing the value of TESTVAR, setting it to a 
null string, or blithely ignoring the quote mark and letting it go 
through into $MATCH.   

After the \/ token, it seem to be TRIVIAL to match any character that 
wasn't a quote, semicolon or whitespace, and that would capture the 
entire boundary string... AND solve the multi-line problem -- but, 
again, absolutely none of the applicable syntax wants to work here.   

So, what is it about the context that refuses to let me do an elective 
match on the leading quote mark and prevents almost anything except .* 
from working after the \/ ? There must be something pretty basic I'm 
missing here, but, damn! I've been studying this for a week and a half 
steady, and I have *not* seen an explanation for this behavior.

Am I missing something else, obvious or not? Does it seem like 
something in my environment is screwing it up?  

I have not turned on logging yet, but will shortly. Am I right to 
assume procmail logging is more important than smartlist's for this?  

Any help or insight would be appreciated.  

Thanks,

Mike D.

[Mike Devour, Citizen, Patriot, Libertarian]
[[email protected]                        ]
[Speaking only for myself...               ]