I see that the draft has recently expired. Are there any news about it?
No. If there are people who would actually implement it, it's easy
enough to send in a new rev.
In case a -01 version is scheduled, I would like to point out a fairly
recent updated draft regarding the COMPRESS extension for NNTP:
I've looked at it, being one of the 14 people in the world who still
runs a news server. Despite the superficial syntactic similarities,
SMTP and NNTP are not all that similar. Most notably, SMTP traffic is
very asymmetric, with only tiny amounts from server to client, and
potentially large messages from client to server. NNTP can go either
OK, I understand that COMPRESS would not be that useful for SMTP
(contrary to IMAP or NNTP).
Regarding implementation of COMPRESS in the NNTP world, interoperability
is already proven: we have a widely used news server (INN) and a news
client (flnews) that implement it. Cyrus NNTP server also added support
If the draft ever becomes a proposed standard, we can hope other clients
and servers will adopt it. Only 13 news servers left to upgrade :)
=> COMPRESS for IMAP permits to use other compression schemes. We also
permit that for NNTP. Better foresee future better algorithms from the
Does anyone actually use other compression algorithms? Options that
nobody actually uses are about the best way to create hard to diagnose
Sean spoke about LZMA/LZMA2 here. That algorithm also arrived in the
discussion in the news.software.nntp newsgroup. Though still not
supported, it could in the future (or any other algorithm).
Supporting from the start a syntax permitting to use other algorithms
than DEFLATE is easy to do. I do not see why supporting that would
If the client asks for an unknown algorithm, the server will just
[C] COMPRESS X-SHRINK
[S] 503 Compression algorithm not supported
Besides, the server advertises the algorithms it knows:
[S] 101 Capability list:
[S] VERSION 2
[S] AUTHINFO USER
[S] COMPRESS DEFLATE
[S] LIST ACTIVE NEWSGROUPS
Let's activate a compression layer using DEFLATE:
[C] COMPRESS DEFLATE
[S] 206 Compression active
[Henceforth, all traffic is compressed]
Incidentally, are you sure a separate CDAT command is the wisest
solution for SMTP (instead of a compression layer, like TLS)?
Yes, see previous discussion. The compression layer requires a
three-way coroutine system which is a lot more fragile than sending
the data through already debugged TLS connection code, and this
completely avoids the CRIME issue and its relatives.
A separate command will be "easy" to implement in case SMTP software
cope well with null bytes, as Russ hinted at in the discussion.
Otherwise, a compression layer is easier to add (the same way a TLS
layer or an SASL layer are).
« Il ne faut jamais pleurer d'avoir perdu la lune car les larmes
empêchent de voir les étoiles. »
ietf-smtp mailing list