Andrew Farrell <afarrell(_at_)baltimore(_dot_)ie> writes:
In message
<93311736716634(_at_)kahu(_dot_)cs(_dot_)auckland(_dot_)ac(_dot_)nz>you write:
From the "Why on earth hasn't anyone done this before?" department: I've
just spent the last hour or so adding zlib-based compression to an existing
S/MIME implementation. All this needs to work is a new content type,
CompressedData.
Jim Schaad brought this up about 14 months ago,
Ah, I thought I'd seen it mentioned before somewhere, just couldn't remember
where.
the consensus was that this made a lot more sense applied on a MIME level.
What actually happened next isn't recorded :)
Nothing happened, which is the problem with applying it on a MIME level - it's
never going to happen because you'd have to convince an infinite[0] number of
MUA's and MTA's to implement it (I present as exhibit 1 the fact that it's
gone nowhere after 14 months). Given that people are still using mailers
dating from the stone age, and that there's no incentive to implement it (look
at how long it's taking to disable relaying and other spammer aids, which is
probably the No.1 critical mail problem at the moment) it's never going to
happen if you leave it at the MIME level. In contrast putting it in CMS means
you automatically get it when you use CMS, so any new mailer which supports
CMS would also support compression. In contrast noone can afford to support it
at the MIME level because 99.999% of all implementations won't be able to do
anything with it. Technically it might make more sense at the MIME level, but
in practice all that putting it there is doing is guaranteeing that it'll never
eventuate.
On a related point, there's my standard refrain that CMS stands for
Cryptographic Message Syntax, not MIME Bit-Bagging Scheme - having it at the
MIME level is of no use if you're using CMS without MIME.
Peter.
[0] Figures exaggerated slightly for effect.