I have checked with gpg4win 1.1.3 (GnuPG: 1.4.7, GPGol: 0.9.92) and the
problem is still not solved. It continues to occur exactly the same way.

Thanks!, the problem was I've entered the complite asc key name. When I enter
only the ID of my key everything works OK.

Check that you entered the correct key id in the option dialog. It must be the
key id of your own key (one which has a secret key).

With gpgol 0.9.x you get a file dialog to specify the name of the attachment.
Use that. We won't fix that in 0.9.x.

Sorry, I can't test this now. As I noted in other bug reports, OL2007 may or
may not work. We will make it work later this year using the forthcoming GpgOL
rewrite.

The current - non fully working - code of GpgOL works fine under Vista and
OL2007. This is code more or less a rewrite of the old code; thus I am not sure
whether it makes sense to try making the old code working vor Vista.

Hopefully the last comment T778 (JohnA on Jun 19 2007, 01:03 AM / Roundup) didn't get lost... it should be pretty easy
to verify whether there's a blank line in a signed text!

Installed the latest version of GPG4Win including gpgol 0.9.91. One other
problem was noticed. If I encrypt and sign or just encrypt a text message,
everything is ok. If I just sign a text message, the verification fails when
reading it. I noticed there was no blank line between the Hash: statement and
the first line of the message as there is on other PGP signed messages.
Manually adding a line to the signed message after it has been sent allows it
to verify correctly.

Hello Werner,

Tomo, can you please check this?

Similar to T780 I guess.

I doubt that this is a bug. Do you have several secret keys? Some folks use
wildcard key specifications and gpg needs to do test encryptions using all
available keys.

Does this still happen with gpg4win 1.0.9?

Does this still happen with gpg4win 1.0.9?

That is not a bug - but a feature. For PGP/MIME messages GPGol uses its own
MIME machinery. Running this for the preview window would be too cumbersome.1

Duplicate of T780

We need nore information regarding this info. However, it is quite old and thus
it does not make sense to check it out.

Duplicate of T780

We have a couple of similar reports. Needs more investigation.

Note that there are similar reports in the tracker. Closing this one due to
lack of a response.

[Please don't set to testing unless a fix has been developed which needs testing.
chatting is in generalokay, setting the due data is helpful to sort out too old
reports. if more info is required, please set the state to "need-eg"]