If I can even find out why "? doesn't reliably match an optional double quote, I'd be much farther along. That's the first annoying failure.
That is puzzling, but it's probably not the only bug in procmail's RE handling. If a ? (or * or +) immediately precedes \/, it seems to screw up the RE processing. You could instead grab the whole boundary parameter in one step, then strip the quotes after that: :0 H # NOTE: The ^M in the RE needs to be a literal carriage # return, not the two separate characters ^ and M. # Procmail does not support control-character escapes. # This is necessary because some mail comes in with CR-LF # line endings, and you don't want the CR included in the match. * ^Content-Type:\W*\<multipart.*\<boundary=\/[^; ^M]* { TESTVAR = $MATCH :0 * TESTVAR ?? "\/[^"]* { TESTVAR = $MATCH } } In limited testing, this seems to work fine. -cary