BBC 'vague' reporting again!

[Roland Perry]

In article <4934F3D1.4090203@gmx.co.uk>, Dave Howe <DaveHowe@gmx.co.uk> 
writes

>>> I do recognise, though,  there'd be an interesting case to be made in
>>> respect of an email delivered to the PC but not yet read by the owner
>>> - a fact which could be established by looking at the flags within the
>>> email archive.
>>
>> How many different email clients would a typical trojan be able to
>> extract individual messages from?
>>
>> For example: a relatively well known, but low volume client such as
>> Turnpike. I am led to believe that the messagebase itself is encrypted,
>> and would be surprised if the algorithms required to unpack and examine
>> individual emails were 'in the wild', even if the encryption key could
>> be discovered/broken.
>>
>> Therefore, the only way to read the emails might be to intercept (sic)
>> them as they arrived.
>
>I would have thought the opposite could well be true - while a first
>"wave" of reconnaissance could identify installed packages, a second
>tailored "module" could presumably be written to do actual package
>analysis (and once written, can be deployed to other instances of that
>client) intercepting using dll injection the actual password used the
>next time the instance is run.

I don't follow the terminology used here. What's "package analysis", for 
example?

>On the other hand, interception would not get them historic message
>traffic,

That was my thought too.

>and if there were any use of TLS, not even get them current
>traffic without having to demand the TLS keypair from the ISP (and not
>even then, if PFS modes are in use)

In theory I can exchange email with my office (aka home) on an ssh 
tunnel and therefore have no ISP servers, or external unencrypted 
traffic, involved at all. But it's all a bit too fiddly.
-- 
Roland Perry