[imp] pgp-encrypted emails blowing up session

[Michael M Slusarz]

Quoting Oliver Kuhl <okuhl at netcologne.de>:

> Hi,
>
> it's me again! ;-)
>
> There seems to be another issue with encrypted emails. As I found out,
> decrypted emails are saved in the session. But those data seems not to
> be reused when I open the same enctypted email again.
>
> I looked at the size of my session and found out that reading encrypted
> emails blows the session, because the decrypted email seems to be saved
> in the session everytime I open it again and again.
>
> Here is the size of my session after every time I opened the same email:
>
> # ls -la /tmp/sess_7e2b79b579fc0baf37603f9e464e4d22 (several times)
>   914386 Apr 14 08:02 /tmp/sess_7e2b79b579fc0baf37603f9e464e4d22
> 1575316 Apr 14 08:03 /tmp/sess_7e2b79b579fc0baf37603f9e464e4d22
> 2236257 Apr 14 08:03 /tmp/sess_7e2b79b579fc0baf37603f9e464e4d22
> 2897198 Apr 14 08:04 /tmp/sess_7e2b79b579fc0baf37603f9e464e4d22
> 3558139 Apr 14 08:04 /tmp/sess_7e2b79b579fc0baf37603f9e464e4d22
> 4219080 Apr 14 08:05 /tmp/sess_7e2b79b579fc0baf37603f9e464e4d22
>
> Sorry I don't come up with patches. But the MIME-stuff in IMP is really
> magic and nothing for patching around without understanding it. Maybe
> one of the developers has an idea and quick solution... :)

There is nothing wrong here.  An unfortunate side effect of a session-based
environment (i.e. PHP) is the need to cache information between page loads
since we can not keep that information in memory as it will be lost when the
pageload is terminated.  Thus, we have to cache all MIME objects to prevent us
from having to redo the (potentially expensive) process of building up 
the MIME
Structure/contents/etc.

In the case of embedded PGP messages, it is even more difficult/complex.
Imagine the scenario where you have a PGP encrypted message (IMAP index 
1), and
the PGP data is located in MIME Part ID 2 (as is the case with 
multipart/signed
messages).  Pretend the encrypted data contains a MIME message with two parts,
and we want to view the second MIME part (which we will say is in image/jpeg
file)).

Normally, this part will be identified as Part 2.2, so the viewing page can
simply be told to grab the data in IMAP index 1, Part 2.2 and display it.
However, in a PGP (or S/MIME) message, there is no Part 2.2, there is only an
ID 2, so this would fail.  Therefore, we need to cache *ALL* details of the
internal structure of the embedded MIME message so we are able to view it
later.  Then, we can tell the view page to look at the cached object (by
passing it the cache id) and then grab Part 2 from that cached object.  This
allows us to view/download that attachment.

So, if you have a large amount of data in these embedded MIME parts, they will
take up a large amount of space in the cache backend.  Since our caching
algorithim does not recognize that we have already cached an item (it won't
know that we cached IMAP index 1 once you leave the page), it has to create a
new cache object every page load.  This is why you are seeing the increase in
size.

However, note there is a limit to how large this cache will be - the maximum
number of objects is located in the SessionObjects::$_size variable (by 
default
it is 20).  So the session size will eventually reach a plateau - it will not
infintely grow larger.

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder