zip up attachments and deliver modified message
Professional Software Engineering
PSE-L at mail.professional.org
Thu Jan 22 18:48:55 CET 2009
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
* 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
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.
More information about the procmail