At 15:57 2001-04-01 -0400, Timothy J. Luoma wrote:
I have sworn off email attachments for the rest of my life.
For some simple lists I run through procmail recipes, I run the incoming
messages through an attachment filter called stripmime
<http://www.phred.org/~alex/stripmime.pl> that strips them entirely, then
emits a footer text into the message indicating pieces have been removed
(problem was having a stated policy of "no attachments" didn't sink in with
people). I did some of my own tweaks to the helper app, and I would think
it could be tweaked to support what you're trying to do as well -- the
message itself could have the URL tacked right into the footer.
Actually, in the procmail rules on that account, I separatley check for
multipart and bounce a reminder text, THEN the MIME stripper is invoked as
a filter to eliminate everything except text/plain.
If you wanted to get really clever, the helper app could check to see if
the extracted attachment was the same as another (CRC32/size signature
possibly, followed by an outright comparison), and just point to
that. Then you don't have multiple copies of the same binary hanging on
your system (or of those damn .VCFs). With a helper script on the
webserver (perl cgi, or a PHP-enabled page), the URLs could point into this
helper which could manage renaming things to their original names (multiple
attachments with different names but the same content) and enforcing http auth.
Content-Disposition: inline; filename="../../../../../../../../../../.rhosts"
1. Would require that the user under which procmail is being executed has
write perms to that _system_ file (arguably just another reason why root
email should be aliased to another account).
2. I don't think there should be any slashes in the filename (i.e. I don't
think clients support sending directories), so having procmail rewrite the
filename with a sed rule might be a good first operation to perform. In
fact, perhaps just checking to see if there ARE any slashes (backslash or
otherwise) might be a good check for malicious attachments. If you find
one, just store the message in a "DANGER" folder or something and emit a
summary message about the content.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail