> > Do you want to say that if you use only the backslashes in the path to > > the mailbox (ex. mail\path\to\user.nsf) and DO NOT check the "Encrypt > > saved mail" box, the saved mail will still be encrypted? > > Yes - if the product functions correctly AND if you select "encrypt mail" > in the mail options while composing the new mail note. As far as I can > verify this, the saved mail stored in the "Sent mail" folder is encrypted > when these conditions are met - even if "encrypt saved mail" and "encrypt > sent mail" are NOT checked. Well, I have just checked this with my setup : a "no connection" location, with a plain file name (without directories prepended) for the mailfile, with "encrypt saved mail" and "encrypt sent mail" unchecked. My client (4.53b for France) indeed says (on the status bar) that it is encrypting the message with my private key, but the result is that the saved message is NOT encrypted... Then, with both "encrypt saved mail" and "encrypt sent mail" checked, the behaviour is the same... I would conclude that there are other cases (client versions, mail templates, usage cases etc.), beyond those already identified, provoking this bug, and I hope Lotus will help us to sort it out (right, Kevin? :-) > > It is reasonable to expect that if you do not check the "Encrypt saved > > mail" box, the respective message is stored in clear in the mail > > database, and as such is recoverable via sniffing the network traffic, > > be it the initial mail copy storing on the remote server, or any > > replication (via the network) of the database, unless you encrypt the > > network traffic, by checking the respective box in the File -> Tools -> > > User Preferences ->Ports menu. > > I disagree: when a user composes a mail and specifically requests > encryption for this mail she has good reason to believe that the product > will not pass any clear text of this message over the wire or store plain > text on external systems - regardless of any global settings elsewhere. I agree, from the intuitive basic user point of view, there's or there's not "encryption". Now with all the checkboxes provided by the product, a technical person should suspect that there could be multiple possible ways for the product to operate. It is a design decision, and it is up to the authors of the product to chose which buttons and whistles to provide, and what hidden logic to implement. But when the thing says it is encrypting and it is not, it is a clear BUG. Then, the mail server is not clearly an external system ; in a corporate environment, for example, the mail clients and servers are both part of the internal information system, and usually there is no privacy boundary between the two. If you wish to be really independent of the server's security, there would be more steps to make : you'll have to distribute your public key by a third means, you'll have to ensure that all the incoming mail is encrypted, as well as some other things. But then you'll have to know the product very well, to the point that you have checked that all the features you need work as expected... > In my opinion it is reasonable to expect that if I request encryption by > *any* means within the client, I do not want the clear text to leak out. > And I wish to be told about any problems if my software cannot perform > this action properly for some reason. > > In addition I do not think that the "enrypt network traffic" option does > help a lot - the message is still stored on the server in the plain. > It addresses a particular threat, the network sniffing. It is useful for retrieving unencrypted incoming mail or for accessing any other unencrypted data on the server, where the other encryption features (private/public key encryption) cannot be employed. A. Iakovlev --------------------------------------------------------------------------- --------- The statements and opinions expressed in this message are not and do not necessarily correspond to those of IBM Corporation.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:40:56 PDT