Lucky Green <shamrock@netcom.com> writes:
Anybody with half a brain, a copy of perl, and the PGP 5.0 source from http://www.pgpi.com/ could write a similar filter in a matter of hours.
Agreed. But PGP Inc may be able to deploy their system better than some lone hacker is able to deploy a perl hack. And deployment of pgp5.5 / 5.0 is required to provide automatic interoperability for this. (Yes I know you could bounce the mail, and demand a Cc: snoop@acme.com to go with all mails to fred@acme.com, and use a lot of pgp2.x setups to auto-encrypt to those recipients with pgp2.x crypto recipients, but this is not as convenient).
I am going to install PGP's SMTP filter on my box. To make it impossible to accidentally send unencrypted mail to certain people. :-)
Fine, a good, entirely separable functionality.
To make that a bit stronger, it seems like *any* model that uses persistent encryption keys essentially enables CMR-like functionality in a smtp filter -- it could be done using pgp 2.6.
Correct. But this isn't going to stop people from complaining.
You are right, it's not. Just because things are possible, doesn't mean you should _do_ them, nor attempt to massively deploy them. If the pgp5.5 functionality is designed to provide companies with a disaster recovery procedure (forgotten passphrase, or dead employee), there are much better ways to do it. We're not arguing against the user requirement, just against the methodology.
PGP 5.5 is considerably better than PGP 5.0. The LDAP support alone is reason to upgrade. The UI is improved and if you don't want to use message recovery, just don't turn it on.
Sure, that works. For now. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`