Just curious - has the idea of doing on the fly compression at the ESMTP
level ever been considered?
I think there are two major problems this proposal tries to solve:
(1) Big attachments take forever to download over a slow link with
POP or IMAP, or to submit with SMTP.
(2) Big attachments take up a lot of disk space on the mail server
or in mail folders where you save them.
Enhancing SMTP doesn't solve either problem.
We need a deployment mechanism first. And that's precisely what we're
trying to get through RESCAP.
Not being familiar with RESCAP, do you have a URL for it?
Some ideas for deployment:
(1) Provide a free tool that will convert the compressed format to
the uncompressed format, open source and also compiled for the
various platforms.
(2) Put up some mail relays on the net. You forward your message to
a mail relay - it returns it to you with uncompressed attachments.
(3) Have a phased deployment of clients. We choose a date, say, 2
years off, by when we expect most clients will be upgraded. Each
client has a switch setting for whether to compress binary attachments,
with 3 settings:
Always compress
Never compress
Compress if the send date is after <the chosen date>
The default setting could be the third one.
In addition, the Compose window should let you override the default
setting for a specific message.
That, and the fact that currently, the average text/plain being sent
around is relatively small (2-3K or so) and won't be a BIG win (you can't
save mor than 3 K, and that's only 2 packets on an ethernet ;)
The things that chew up the bandwidth are things like .GIF, .JPG,
etc attachements, which usually tend to have some compression already
done on them. Now, if you have some big spreadsheets from some big
company that specializes in bloatware, perhaps the right thing to do
is convince them to make it take less disk space. Yes, disk is cheap,
but that hardly justifies intentional waste....
I would think one would want a setting in the client saying "only
compress attachments if they are larger than ___ KB." My experience
is that MS Office files are the usual large attachments that cause
problems. While I am hopeful that Microsoft will eventually have a
reasonably small default Office format, their web page says Office 2000
files are the same format as Office 97, and that their HTML versions
are actually larger than the proprietary format.
Has anybody done any studies at all on whether said compression would
actually *win* us enough to be worth it? As a data point, my MH folders
live on a compressed file system (each 4K block is LZ-compressed
individually),
and takes about 110M compressed and 198M uncompressed. *HOWEVER*, a *very*
large chunk of that is Received: headers and the like, which would NOT
be compressible...
I tried compressing (with winzip, which seems to be universally available
on PCs) a lot of large Office files I have around. The results were
spectacular - 90% compression was common. I really had to hunt to find
files that compressed to the expected 50%.
I would guess that GZip would do even better.
Mark