Rui asked,
| I have successfully been using the following recipe to catch a number of
| attachments:
|
| :0 HB
| * a number of conditions I omit here
| * ^Content-(Type|Disposition).*(\.doc|xls|ppt|pps|exe|vbs|bat|and other
| file extensions I also omit)
| {
| ...
| some actions
| }
|
| Unfortunately it turns out that that condition I show above only matches
| if the attached file name string is on the same line "Content-".
When real header lines in the actual head are continued onto extra text
lines that start with whitespace, procmail understands that (and in fact
temporarily translates the newline to a space), but in the body a line of
text is a line of text, even when it's the pseudo-header for a component
part.
| Some nice guy is using a fancy mail client to send me this kind of thing
| which goes through my sieve and ends up in my main inbox:
|
| Content-Type: application/msword;
| name="Ranking.doc"
| Content-Transfer-Encoding: base64
| Content-Disposition: attachment;
| filename="Ranking.doc"
Deep and serious shame on him for sending multipart mail in the first place.
| Does any of you have any clue as to how to match the file extension
| after the line break? I am not exactly a regexp expert...
Hmm. Well, I'll tell you, this may work, but unfortunately it would also
catch mail like your post, where you were just illustrating someone else's
transgression. Note that the \. should be before the last set of
parentheses, not inside it attached to "doc"; you wouldn't want to throw
something out for having an attachment name "pps.txt," for example.
:0B # slow regexp there's no other way
* ^Content-(Type|Disposition):(.|$[ ])*\.(list|of|bad|ex|ten|sions)
action
The brackets enclose a space and a tab.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail