--Boundary-02=_Xu27+Xe7kfdy96S Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline
On Tuesday 17 June 2003 02:31 pm, will hill wrote: > That and it stands out like a sore thumb when you only take the trouble to > encrypt 1% of your mail. true. more encryption is better. That's why I run everything I do through= =20 ssh, ssl, or an IPSEC vpn ;). > Let's see, the only person with access to the mail spooler on my computer > is ... me. If everyone ran their own mail and had TLS, everyone would ha= ve > end to end encryption. Sure, admins here and there could see who I > emailed, but that' not as important as them not getting at what I'm up to > when I don't want them to know. said it before and I'll say it again. TLS does not prevent admins on=20 intervening SMTP servers from making copies of your unencrypted emails. Th= at=20 is a fact. =20 > Some people don't think that's possible or practical. They are correct > only when they confine themselves to Microsoft and dial up limits. Cable > now reaches the majority of US homes. There's no reason everyone could n= ot > have an always on connection with a fixed IP address. Free software is Also untrue. IP address shortages are currently quite real. There's nothi= ng=20 wrong with DHCP per se. It would be really nice if Cox would sell static=20 addresses which are essentially addresses reserved to your NIC MAC address = in=20 the DHCP pool. Did it with Charter. it was actually easy for me to manage= =2E =20 But the notion of static IPs for all is a little starry eyed. DHCP actuall= y=20 prevents some very real issues in cable. For one, it helps prevent the rea= l=20 problem of users stealing one another's static IPs. By tying the IP to a= =20 MAC address, there is some accountability and ability to prevent this theft= =2E =20 And that is the tip of the iceberg. Even if Cox does start selling consume= r=20 static IPs, they will still be simply reserved DHCP addresses. And that is= a=20 _good_ thing. > That is the big problem here. If you can't trust that your email is > private, email loses much of it's value. *chuckle* If you believed that before this discussion, you were deluded. = =20 Welcome to the real state of the internet today. These protocols (as in=20 TCP/IP) were NOT designed with security/privacy in mind.=20 > you can secure IM but not email? Why do people think that you need a rel= ay > for mail but not IM? Because ITS NOT THE SAME PROTOCOLS. And rewriting the global email transpo= rt=20 protocols will take a LONG TIME to do. TLS is not even close to the answer= =20 for the long term and it's really not much of one for the short term. TLS= =20 for SMTP primarily exists for businesses. It offers very little real valu= e=20 for consumers. It is not designed, nor is it capable of solving the proble= m=20 you want to solve (global end-to-end) encryption of email. You can conside= r=20 that an opinion if you like. But I'm going to assert that you really don't= =20 have a full and clear understanding of how email servers actually work. =2D-=20 Scott Harney <[EMAIL PROTECTED]> "...and one script to rule them all." gpg key fingerprint=3D7125 0BD3 8EC4 08D7 321D CEE9 F024 7DA6 0BC7 94E5 --Boundary-02=_Xu27+Xe7kfdy96S Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA+72uX8CR9pgvHlOURAiFMAJ9pRlDOpo9+EVNPyBvBCU0SyFWOcwCgivhL eZ9Q0ofxX6WNmIiyaG/MEh4= =mjBC -----END PGP SIGNATURE----- --Boundary-02=_Xu27+Xe7kfdy96S--
