procmail
[Top] [All Lists]

Re: Slightly OT: Stripping Attachments

2001-11-29 01:09:17
At 23:22 2001-11-28 -0700, Ashley M. Kirchner wrote:

Does anyone know of some program I can drop between my MTA and LDA that will scan an incoming message for (MIME) attachments, strip them off, drop them into a (predefined) URL accessible address, stick a pointer in the message and pass it on to the LDA for delivery?

I'm not aware of anything which does all of that -- though that's not to say that there isn't something out there that might work.

I've used stripmime with success to at least strip out mime attachments (and that tosses in a text blurb to indicate that the attachments have been removed) - modifying it to decode and save the attachments probably isn't a big deal, though _managing_ the attachments in a sensible fashion is a bit more work. It is a perl script, and isn't all that complicated:

        <http://www.phred.org/~alex/stripmime.html>

I'd be surprised if someone hasn't already produced a solution (though it it entirely possible that it's commercialized - say targeted at ISPs or businesses), but if you end up rolling your own (as much as you might not want to do that), I'd suspect stuffing the individual files into an SQL database would be the no-fuss way to deal with it (you could also _compress_ them when storing them which would make them use somewhat less space), provided you have an SQL db server at your disposal. This would aleviate you from having to deal with conflicting filenames, though if you were clever about it, you could generate CRC-32 signatures for the decoded files (pre-compression, should you choose to compress) and store that, as well as the filesize as DB fields so that you could call up potential matches from the database when a new file arrives - you'd take potential matches and actually verify that they're a binary match, if they do, you merely add a filename link into another table that points back at the appropriate entry in the file table rather than storing another copy (this is important when there are large files being emailed to multiple recipients who may not delete them from the server right away). Your retrieval page would have an option for deleting the file, but you need to fret over how many local recipients there actually were. When a user goes to delete a file, the db would check to see whether there are any other filename links to the binary, and if not, deletes not only the filename link, but the binary as well (or perhaps the binary just gets flagged for a later purge). You could also run a purge of files which have remained on the server for over 'x' period of time.

If I had a need for such a thing, that is basically how I'd approach it.

To put it (or whatever your chosen solution is) between MTA and LDA, you'd invoke whatever you use from within a global procmailrc (/etc/.procmailrc). Note that the LDA is "Mlocal". There's also "Mprog" (at least within sendmail), which means addresses which are aliased to programs _would_not_ be handled automatically. You could replace the Mprog with a script instead of the more typical /bin/sh.

---
 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

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