procmail
[Top] [All Lists]

Re: attachment extention filter

2002-12-02 18:19:14
Hey Mr. Systems Analyst! :-)

Peer to peer, may I suggest that you create a formal problem statement and
work from there?

I'll try to disentangle you:

1) Either you are not actually interested in filtering attachments, or you
are slightly confused about the definition of attachments.

2) What you're proposing isn't going to filter the "attachments", it is
going to filter the mails containing the attachments.

"Mark T. Valites" writes about filtering attachments:
I'm looking to implement a (crude?) attachment filter.  So far, I've been
matching with something like this for file extensions:

:0 H
*^Content-type: (multipart/mixed)
{
       :0 B
       *^Content-Disposition: (attachment|inline)
       *filename=".*\.tar\.gz"
       /path/to/Maildir/
}

So breaking down cases, sir, we have the case of an inline which MUST HAVE
a filename. Interesting. Not impossible, but interesting.

I'm not actually blocking .tar.gz's, but I'd like to block files with
double extensions of .pif, .com, etc...

Files don't have double extensions, technically speaking, do they?
Technically, file extensions are a Windows brand cockup, aren't they?

(Leaving aside that this may be your problem!) Is this part of your problem
statement, or is it at the core of your problem statement?

I feel like I'm missing some attachments - are

*^Content-type: (multipart/mixed) &&
*^Content-Disposition: (attachment|inline)

Rigor, man! Rigor! Reducing what you've got above, yes, you are correct,
you are asserting A *and* B.

enough, or can attachments slide past in additional ways?

Well IMO multipart alone is probably enough of a clue. Then instead of
Content-Disposition, you would probably be more profited by examining
Content-Type of the parts. You examined it for the header, now do it for
the parts.

Would it be
worth the pain of chewing through an RFC for this?

Buhahaha! *ONE*? Buhehehe!

  http://www.inwa.net/~m3047/procmail/rfc-tree.pdf

Try the MIME track. Also read 2557. Love the fact that Microsoft helped
write it. 1844 is dated, but might be illuminating; plus it (still)
provides a good starting point for a multimedia-aware UA checklist.

Any suggestions are appreaciated in advance.

Reading RFCs is always profitable, both for the rigor displayed, as well as
for the refreshing lack of so-called "professionalism".

Whether you'll find what you're looking for is another matter entirely.


(Congrats, Don, you've made it into a .sig!)

--

Fred Morris
m3047(_at_)inwa(_dot_)net

      Not impugning your artwork - but what a rat's nest! -- Don Hammond



_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail

<Prev in Thread] Current Thread [Next in Thread>