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] [mdevour@eskimo.com ] [Speaking only for myself... ]