Prev: Cannot open file for writing Version 7.0.1.0 Paid mode
Next: SSL Negotiation fails
From: John H Meyers on 1 Jun 2007 04:51
On Thu, 31 May 2007 09:55:16 -0500, Tim Streater:

> There are two extra buttons in the new-mail-compose window
> for sign and encrypt.

Okay, I wasted some time because I had the wrong plugin!
(and had found it not to work, and had removed it)

The PGP 7.0.3 installer has Eudora plugins *both* for
Eudora V3 and Eudora V4 (and later); I had installed PGP
before I installed the later versions of Eudora,
so I had never found the plugin file "PGPEudoraPluginv4.dll"
(PGP "current window" operations do not depend upon the plugin anyway,
so it had never concerned me, as I had never bothered with PGP/MIME).

With *both* the S/MIME and (the correct) PGP plugin installed
for Eudora V6 and V7, I end up with two sets of Encrypt/Sign
buttons in my compose windows -- one set for S/MIME,
and another set for PGP, and exactly the same results as yours.

By the way, keep in mind that this plugin is a product of
former PGP vendor NAI (Network Associates Inc), *not* Qualcomm --
Eudora provides only a framework for making plugins,
and other people make the plugins, more or less analogous
to "extensions" for Thunderbird which are made by others,
most of them not by the TB developers themselves.

o PGP/MIME messages *sent* by the plugin itself arrive as *unnamed*
attachments; since a null-named file is generally a problem,
it is up to the receiving application how to handle it -- Gmail,
for example, decides to assign it the name "noname," while Eudora
decides to use the message "Subject:" as the file name (no doubt
fixing it up to make it legal for Windows, if necessary).

o The received attachment *extension* is set to .ems
(that's a Eudora plug-in-based name, as in "EMSAPI")

o NAI's Eudora plugin ignores the "automatically decrypt/verify"
option, set in the separate *main* PGP component.

o NAI's Eudora plugin does obey the "use PGP/MIME when sending"
option, but you have to pre-set that in the main PGP component.

o PGP "inline" messages are sent like a text attachment, but received
as if they were inline to begin with (i.e. in the message body).

o If you use the PGP "sign/encrypt" compose buttons when sending,
you will end up with *no*copy* of your original outgoing message,
except in the temporary file (in a Windows temp file folder)
which is attached (actually appended) to the outgoing message;
this is the case even if you *only*sign* the message!

You might thus wish either to "Bcc:" yourself whenever using
the PGP "compose" buttons, or else use only "inline" operations
via the PGP operations found in the Edit > "Message Plug-ins" menu
(corresponding optional custom main toolbar buttons may also be found
in the "plugins" tab of the toolbar "customize" tool).

o When you click an incoming PGP ".ems" attachment, you'll be asked
whether you want to save the resulting message afterwards, but you
will *not* be asked if you "Decrypt/Verify" an "inline" PGP message
(so remember to save it before closing the message, if you want
to have the results saved, instead of having to repeat next time).

NAI's PGP plugin is thus different operationally than
Eudora's own S/MIME plugin, which upon sending messages
does save your original; incoming PGP/MIME or S/MIME messages
seem to act similarly, for as little as I looked.

So you've selected NAI's PGP 7.0.3, and you've got NAI's plugin,
which does things its own way, and "that's the way it is."

If you were to get the current PGP, I understand that it would
be less reliant upon plugins, and more designed to simply
intercept the SMTP and POP conversations on the TCP ports --
in other words, it would instead act as a "proxy,"
somewhat distanced from the email application.

"Pretty Goofy Privacy" :)
 | 
Pages: 1
Prev: Cannot open file for writing Version 7.0.1.0 Paid mode
Next: SSL Negotiation fails