[Top] [All Lists]

Re: [ietf-smtp] Compressing SMTP streams

2016-01-29 11:35:04
On Thu, Jan 28, 2016 at 11:12 PM, Carl S. Gutekunst 
<csg(_at_)alameth(_dot_)org> wrote:

On 1/28/16 1:42 PM, Brandon Long wrote:

2) message sizes are increasing, but base64 isn't going away

Are they?

The averages aren't, but the distribution tends to have multiple peaks
where they include the most common sizes of images.

I guess, what I'm really saying, is the volume is increasing, but maybe the
difference only matters at a high enough volume.

It's an honest question; you have vastly better data to work from than I
do. But I have not seen much growth in message size once we got past the
bump from plain text to HTTP, and the occasional bump from another vendor
adding more cruft to the header. Attachments can be large, but the user
community seems to have generally accepted that Email isn't an appropriate
transport for "large" things and tends to avoid it. The most common
attachment types also are not compressible: PDF, JPEG, pkzip.

The exceptions can be spectacular; I see marketing types Emailing 150MB
powerpoint files every day, and those seem to be quite compressible. But as
annoying as they can be, they do seem to be the exception.

Most Office document types switched to be a compressed format several years
back, but if a powerpoint has a video or something in it, that's not going
to compress.

And the GfW folks are always pushing us to increase the max message size we

My main point was that with base64 encoding of a jpg, there's still a
recovery ratio in the 25% range.

Ie, a local mp4:
blong@blong-x1:~$ ls -l tom_nhl.mp4*
-rw-r----- 1 blong eng 21566364 Aug 10 02:09 tom_nhl.mp4
-rw-r----- 1 blong eng 29133510 Jan 29 09:29 tom_nhl.mp4.b64
-rw-r----- 1 blong eng 22092559 Jan 29 09:29 tom_nhl.mp4.b64.gz

so, not quite back to the original size, but close, 24% reduction.

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>