This is similar to the S/MIME case where we can't yet process messages we have
not received with gpgol installed and active. The solution will be the same as
for S/MIME - we talked about this.

I wasn't aware this is true of OpenPGP as well.
I adjusted the subject.

However, I guess for OpenPGP it should be easier to solve?

In fact this is a critical problem, so I raised priority.

We could has a hack to detect PGP/MIME messages right before displaying. This
requires to use code similar to older versions of GpgOL. I hesitate to add such
a hack because it makes the way more complicate and is nto a full solution
because we need anotehr solution for S/MIME anyway.

To save time, I'll better add the feature we need for S/MIME anyway.

I think most concern is with inline-PGP, not PGP/MIME.
Will the solution apply to this type as well?

Yes it also applies to inline PGP. In fact inline PGP is internally converted
to PGP/MIME.

With new version 0.10.4-svn205
I was able to decrypt a newly arrived inline-PGP mail
exactly once.

If I select decrypt/verify a second time, nothing seems to happen
(why do I do this a second time? Because there is absolutely
no visible information on the fact that the email is an
encrypted one - it simply looks like a normal email).

If I restart Outlook, I only see this text (german):

[Der Inhalt dieser Nachricht ist nicht sichtbar, da sie in einer anderen
Outlook Sitzung entschlüsselt wurde. Verwenden Sie den
Menüpunkt "entschlüsseln/verifizieren" um den Inhalt wieder sichtbar zu
machen.]

first, I still can not decrypt (following the above advice).
Second: this text is really confusing as it lacks rationale for
a normal user. Perhaps just say the user needs to decrypt/verify?

The current SVN (207) might fix this.

I am currently looking on how to automatically install modified forms with icons
showing the type of the message.u

I think the text is fine. It tells what was going wrong and gives a hint on how
to solve it. Background: To avoid storing decrypted data in the clear we need
to encrypt them with a session key. This is so that if MAPI decides to save
temporary data it won't bein the clear.

Still the same problem with svn212.

Should I collect debug output and post it here?
If so, which one?

No need, I should be able to duplicate this.

Fixed in svn 217.

The problem was actually worse. GpgOL deleted the ciphertext from the BODY
property and thus is was later not able to decrypt it. Deleting the BODY
property is done to removethe plaintext of decrypted messages which end up due
to Outlook internal syncronization issues in the BODY property. Obviously this
can't be done if the body has the ciphertext. The problem does not occur with
PGP/MIME and thus PGP/MIME becuase we use our own parser on the ciphertext which
is stored in an internal attachment.

Well, not really. IT requires a more complicated solution.

Now fixed in SVN 222.

To avoid any data loss we keep a copy of the original PR_BODY in a special
attachment.

...some problems with svn 732:
I created testcases with gpg4win 1.1.3
(testcases_InlinePGP_withGpg4win1.1.3.pst sent by PM to werner)
and imported the pst file into outlook.
GpgOL doesn't show cleaned contents of the mails (without BEGIN ... END).
Decryption doesn't work.

Werner, please check!

Well it depends on what you send. If you start the message with an empty line
everything is fine. If not, it will not be shown because the MIME parser does
not find the body; it skips all header lines. I need to detect this situation
and restart the operation without employing the MIME parser on the plaintext
(which is needed for some message, though (IIRC, CryptoEx). It is all not that
easy because we work in streaming mode. I'll try to save the header lines and
employ a heuristic to detect whether this is a MIME message or plain text.

Additional problem is that the test messages don't contain a final LF. This is
a usual problem with PGP armored messages. I have added a hack to overcome this
problem.

Decryption works now.

Outlook crashed after import .pst file and double click on the encrypted or
signed+encrypted email.
Signed messages (with/without attachment) don't show cleaned mail body content.
Still the same problem... Tested with svn739.

GpgOL error log:
464/ERROR/mimeparser.c:start_attachment: can't set attach long filename:
hr=0x80070057
464/ERROR/mimeparser.c:mime_decrypt: failed to open the RFC822 parser: Invalid
argument

The SVN number seems to be from the gpg4win installer. The current GpgOL
revision is 233.

Found it. The code to bypass the MIME parser missed to cleared info fields used
to colelct the mime structure. Fixed in svn 235.

OK, no crashes anymore.
Also, the only encrypted email works, but not the ones
with attachement or signed& encrypted.

It might be that the problem is with email bodies
that do not have any newlines.

However, Werner has all test files to work on it.

Fixed in 0.10.9. The detection of multipart/mixed messages with old-style PGP
parts was not implemented. However, the signature verification of the old-style
PGP messages with attachments fail, i.e. they say the signature is bad.

That might be due to the missing railing linefeed - I am not sure. I don't want
to keep on hacking on this. Fixing this is orthogonal to the general operation
of GpgOL. Thus it can be fixed later without the risk of breaking other parts.
Needs a lot of code+test cycles, though.

I confirm I can at least decrypt all my test mails
and see signed text.

As Werner said, I have problems with verification of signatures.

Werner: I leave to you wether this issue can be resolved and the
remaining issues to open a new issue or wether to keep this
issue for the remaining problems.

Note: The emails I tried to decrypt with the previous versions
of GpgOL were somehow totally damaged and there was no way
to decrypt them with the current GpgOL. I had to reload them from my
pst backup.

Right, older version of 0.10.x garbled the messages. We now take a copy of the
PR_BODY propery and work on it.