Upon further reflection the best format may be:
* (^Content-Type: +text/(plain|html).*(^.*)?^Content-Transfer-Encoding: +base64)
Not sure if that quite works but hopefully it would
allow for a potential, and perhaps(?) valid,
'Content-Disposition: inline' or some such line
in-between.
It would, with the "or", match for plain text encoded
email but I don't know if many spammers actually bother
with plain text.
I am not sure if it is legit to put stuff other than
spaces between the header and argument but I suppose
you could substitute ' +' with '(.*\<)?' or some other
non-newline variant.
One other thing I am not sure of is the order. I
believe it may be legit to reverse the order of
'Content-Type' and 'Content-Transfer-Encoding'. I
guess in that case you may need the reverse regexp
as well.
PS. I don't quite understand why you original recipe:
* Content-Type:(.*\<)?text/(html|plain)
* ^Content-Transfer-Encoding:(.*\<)?base64
failed in the examples you gave. OTOH I also don't
know why it wasn't matching all emails with any plain
text or html and a base64 attachment (ie. doesn't this
match those header on widely separated lines?), but I
am probably missing something and it is late :-).
Actually I just thought of the possible answer to the
second question; when examining headers does procmail
consider the headers of multipart mime sections part
of the body or header? If it considers them part of
the body then you don't have a problem. OTThridH the
any regexp we are talking about here perhaps needs
to be part of a BH scope to catch potential multipart
chicanery. I guess I need to look up how procmail
parses a message into headers and body.
--
Daryle A. Tilroe
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail