I assume Jon is talking about on-the-fly decryption of incoming
messages, i.e., when the decryption happens before the data hits
the MUA? A MUA usually includes the size of an 'object' in a
request and only expect that many bytes in the response. However,
the size after decryption is almost always different.
IMHO, this is not directly an issue with IMAP, but with the
actual implementation/interpretation of IMAP.
The message size handling is just one of the issues with IMAP ...
e.g., think about bodystructure requests and on-the-fly decryption.
That's precisely what I'm talking about.
However, it is an issue with IMAP itself. IMAP has a core assumption
that a message has a size that is constant and knowable even when all
you're getting is the headers. An IMAP server must reply accurately and
precisely the message size when it first informs the client about the
message.
If that message needs lots of transformations including decryption,
this makes determining the precise message size an interesting problem.
But I have to admit that I'm not sure what this has to do with
the original topic of this thread? :-)
I'm giving a warning that simply passing session keys around may not
give obvious solutions to the problem being solved. We've spent a lot
of time with advanced IMAP features at PGP Corporation. Admittedly, in
our case, we're building proxies and proxies don't have liberties that
client-server systems do. If IMAP were less fussy about message size,
then some of the difficult problems would have obvious solutions.
Jon