I have a similar rule that so far seems aggressive enough to catch
variations in headers which describe attachments. For instance, I've seen
just "name=" instead of "filename=", so I've made the "file" part
optional. I never expect any of the following extensions at my address:
:0
* [ ]*(Content|(file)?name=).*\.(scr|exe|p(if|as)|v(bs|xd)|ba[kt]|\
wab|cp(p|l)|asp|xls|mpe?g|reg|ini|d(iz|ll)|sys)
{ do stuff }
Although for double extensions, Barton Schaefer has an elegant solution
as part of his "viriirc.txt", which I'm sure you can google or find in
the archives.
--
Robert Arnold
On Mon, 02 Dec 2002 10:28:19 -0500 (EST), "Mark T. Valites"
<valites(_at_)geneseo(_dot_)edu> said:
I'm looking to implement a (crude?) attachment filter. So far, I've
been matching with something like this for file extensions:
: H
*^Content-type: (multipart/mixed) {
: B
*^Content-Disposition: (attachment|inline)
*filename=".*\.tar\.gz" /path/to/Maildir/ }
I'm not actually blocking .tar.gz's, but I'd like to block files with
double extensions of .pif, .com, etc...
I feel like I'm missing some attachments - are
*^Content-type: (multipart/mixed) && *^Content-Disposition:
(attachment|inline)
enough, or can attachments slide past in additional ways? Would it be
worth the pain of chewing through an RFC for this?
Any suggestions are appreaciated in advance.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail