procmail
[Top] [All Lists]

Re: attachment extention filter

2002-12-04 14:44:09
In the context of MIME-conformant 2822/2045-conformant e-mail message
bodies, an "attachment" is narrowly cast and rigorously defined by 2183 as
an attribute of the Content-Disposition header which occurs on MIME parts
*in the body of the e-mail*. Specifically this is the attachment
disposition type.

Popularly, attachments are the detritus which collects in the user's
"attachments" folder, or additional content which is denoted by an icon
such as a paper clip within the users MUA.

Attachments are not the only non-text payload which may be incorporated
into a MIME-conformant message body; indeed, this was one of the drivers
for the development of MIME.


Procmail is usually best approached as either a tool to accomplish a
specific, common purpose
(http://www.inwa.net/~m3047/pfsk/artless-generator.html et al) or as a
platform or framework within which to craft a mail handling/delivery
application or solution.

Within the latter, a survey of existing works available reveals some
obvious criteria for categorization:


1) Applications for managing e-mail in aggregate, such as the SmartList
mailing list management package.

2) Blacklist/whitelist/PYLM schemes, although strong arguments can be made
that this should be handled by the MTA at the time of receipt, and not by a
delivery agent on behalf of the MTA.

3) Filtering schemes, usually targeted at spam or malicious/undesirable
payloads, such as SpamAssassin or the recent promising hybrid technique
discussed by Tom Allison on this very list.

4) Techniques and tools for processing email in a MIME-aware fashion. It
should be noted and recognized by all competent practitioners in this
specialty that Procmail per se is *not* MIME-aware. Many packages exist for
processing the MIME content of e-mail. The CPAN::MIME module is often
utilized, and hybrid tools such as PerlJacket will also be found. Such
tools are often not targeted specifically at Procmail, although design
criteria utilized usually imply that such tools are usable from Procmail.


In all of the above cases, the authors have arrived at a cogent and
informed problem statement, and invariably chosen widely differing
solutions and implementation paths. A survey of available packages is
advisable for anyone venturing into this field. To this end, a search of
the archives of this very list, and some time spent reviewing several of
the many excellent guides to getting started with Procmail and mail
filtering will invariably prove cost-effective.


In Mr. Valites' case, given that his crusade to redefine "attachment" to
mean something which automagically adapts to his needs of the moment will
take some time, several junkets to Vermont, Atlantic City and possibly
Australia and finally the filing of petitions with the relevant authorities
and curriculum advisors in triplicate, his
(ab)users^H^H^H^H^H^H^H^H^Hcustomers might be best served in the interim if
he availed himself of one of the alluded to OTS packages.

OTOH if this is self-abuse, what do I care?


At Wed, 04 Dec 2002 08:37:27 Mark T. Valites had nothing useful to say:


Once again demonstrating the value of a college degree.

--

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>