[pmmail-list] Feature Request: Encrypt when key present

[John Bridges]

On Mon, 22 Jan 2001 19:51:00 -0400 (AST), PMMail OS/2 Support wrote:

>This requires the same change that the other people were asking for:
>encrypt if a PGP key exists.

NO! No! NO!

It does not ask or check anything, if you reply to a PGP'd message, check the
damn PGP button by default!!!!

If it doesn't have the key, you will get a nice error/warning when you
finally send the message.

But it should ALWAYS default to PGP ON when replying to a PGP'd message.

That's where I differ from all the other suggestions.  No new "check if key
is available" code is required, just ALWAYS default to PGP On when replying
to a PGP'd message, simple.

>Just because someone sends you an encrypted email does *not* mean
>that you have their public PGP key. Therefore you might not be able
>to send them an encrpyted reply.

Again, the default case should be PGP ON, if you actually use PGP for day to
day communication, you obtain keys, you have keys, you find keys, you don't
have one way encrypted conversations where you reply with open text!

If you do, then you can uncheck the damn PGP button!!  Why make all other
secure conversations unsecure by default!

It should not be the default to quote encrypted messages as open text. I
still cannot believe people are advocating this?  Do you actually use PGP
daily?

>Again, PMMail will have to check if the key exists.

No, it will work as it does now, if you have the PGP button checked and send
a message to someone you don't have they key for, it will give you can
error/warning message. You can then CHOOSE to send the message uncrypted, or
go get that persons key, and then click on Send again.

>(Not that I'm arguing against this. I personally want this feature
>very much too.)

It sure sounds like you are....

I hate to even call it a feature!!  It's like 1 IF statement, more like a bug
fix!

I know it would be nice to have all kinds of key checks and PGP addressbook
and so on and so on. But I'm realistic, I just want to conduct secure
communications, and this one TINY change would make a dramatic difference in
the usability of PMMail for this task.  Each time a feature request becomes
blured with side features, I fear nothing will happen (as we've seen for
YEARS). But keep it insanely simple, have the users speak with one voice, and
poof, it happens.

- pmmail-list - The PMMail Dicussion List ---------------------------
To POST to the list, send your message to
pmmail-list@blueprintsoftwareworks.com

To UNSUBSCRIBE, send a message to mdaemon@bmtmicro.com with the first 
line of the message body being...

UNSUBSCRIBE pmmail-list@blueprintsoftwareworks.com
---------------------------------------------------------------------