Re: zip up attachments and deliver modified message

At 09:29 2009-01-22 -0700, dan wrote:
> I know that this may seem a bit odd but here it goes:
>
> Id like to take messages containing doc, xls, etc etc files over a 
> specific size and split off the attachments, zip the attachments, then put 
> them back on the original message.
Some of these formats employ a certain amount of compression to start 
with.  You may not make the huge gains you hope for.  If part of your pain 
is users who attach huge files without thinking about it, then you're 
chuffed when they attach a video, or a powerpoint with video chunks, 
etc.  The process of requiring the recipient to extract things from a 
compressed archive at their end also complicates matters.
Seemigly more appropriate (presuming that users can opt in to the whole 
"fsck with my email format" thing), would be to extract attachments and 
store them to a secured webserver, then insert a URL into the email 
message.  You shed weight several ways:
        * BASE64 encoding of a binary attachment in an email boosts the 
size about 25% -- if you took the same bandwidth that was required to 
download the email, you could download it via http directly.  When storing 
the file, you can compress it then, or you could compress it as part of the 
web retrieval.
        * Users can get to the email content, and THEN decide if they want 
to download the associated attachments - no waiting to download the whole 
thing only to find that it's an attachment they've already got or that 
doesn't apply to them ("Ugh, I was away for the weekend and then checked 
email, and I've got the OLD copy of some spreadsheet followed by four 
updates to it, when only the most recent copy is meaningful").
        * If you store the attachment into an SQL db, you could compute a 
signature.  Only ONE copy of any given attachment would need to be stored, 
so if there are 30 recipients, there aren't 30 copies of the attachment 
files being stored.  Also, when emails are forwarded, the attachment isn't 
reintroduced.  Someone else could generate a new email and send along 
"their copy" of an attachment, and when processed by the system, it'd be 
recognized as a duplicate to something already stored, and the new message 
would just make reference to the current entry (though perhaps generate a 
different transaction record, which in turn references the common file).
        * mailbox full bounces would be minimized, and where the recipient 
host rejects a message and sends back the ENTIRETY of the original, if it 
was reduced in size to start with, the bounce itself won't be of 
significant size.
You could do this based on attachment type and/or size.  Attachments below 
a certain threshold wouldn't be diddled with.
> I can make the procmailrc to pick relevant messages, I just dont know the 
> combination of utilities like formail or metamail that will do the job..
IMO, you're going to need something more than a pipeline of canned 
utilities.  Since procmail doesn't comprehend the attachments as separate 
items from the body of the message, you need to extract it all into 
component pieces via an external utility - but rewriting the message really 
should be overseen by a purpose-written utility (even if you're not going 
the SQL route I suggest above).
> Alternatively, anyone know of a free plugin for outlook to zip up 
> attachments before sending?
Dunno about free, but you may want to check out "dilbertfiles.com" (yes, 
THAT Dilbert).  There's a plugin for OutBreak for uploading files directly 
from the email client.  I don't use the service (or OutBreak) though.
---
 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 homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail