<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Nevada Businesses MUST Encrypt Email Starting Next Week Under Law</title>
	<atom:link href="http://www.theinternetpatrol.com/nevada-businesses-must-encrypt-email-starting-next-week-under-law/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.theinternetpatrol.com/nevada-businesses-must-encrypt-email-starting-next-week-under-law/</link>
	<description>Internet Safety, Windows Updates, Internet News, and More</description>
	<pubDate>Sat, 21 Nov 2009 20:28:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Jim</title>
		<link>http://www.theinternetpatrol.com/nevada-businesses-must-encrypt-email-starting-next-week-under-law/#comment-820491</link>
		<dc:creator>Jim</dc:creator>
		<pubDate>Mon, 29 Sep 2008 14:39:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.theinternetpatrol.com/?p=1946#comment-820491</guid>
		<description>Do you have any idea how this might impact marketers sending email to businesses in Nevada? Are there any additional steps that must be taken by marketers sending to Nevada?

What constitutes a Nevada business? Does the mail server need to be in Nevada to qualify?</description>
		<content:encoded><![CDATA[<p>Do you have any idea how this might impact marketers sending email to businesses in Nevada? Are there any additional steps that must be taken by marketers sending to Nevada?</p>
<p>What constitutes a Nevada business? Does the mail server need to be in Nevada to qualify?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill Cole</title>
		<link>http://www.theinternetpatrol.com/nevada-businesses-must-encrypt-email-starting-next-week-under-law/#comment-817116</link>
		<dc:creator>Bill Cole</dc:creator>
		<pubDate>Fri, 26 Sep 2008 17:17:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.theinternetpatrol.com/?p=1946#comment-817116</guid>
		<description>Speaking as a mail geek, this is not really as onerous as it sounds. There are essentially two kinds of email encryption: content encryption and transport encryption. Content encryption has to be done by end users' mailer programs (aka "MUA's": Mail User Agents)   and encrypts the mail before it leaves the machine that it is composed on. Recipients have to also support the same kind of content encryption and have enough of a relationship with the sender that they can decrypt the mail sent to them. There are two incompatible standards for content encryption, PGP and S/MIME, and both of them have problems that are visible to end users.   Transport encryption  is done using TLS (and its predecessor SSL) and is handled almost  invisibly to end users, sometimes between MUA's and the mail servers (MTA's: Mail Transport Agents) they hand mail to and commonly between MTA's. Transport encryption means that the entire communications channel between machines is encrypted, i.e. not just the contents of mail but the entire conversation that is carried out between sending and receiving systems to offer mail from a sender to one or more recipients. Because businesses transfer mail outside of their own realms almost only through MTA-MTA communications and because it protects the sender and recipient addresses from snooping in transit, using transport encryption would satisfy the Nevada law and do so better than having everyone who writes email get personal mail encryption certificates or publish PGP keys. 

All modern mail server software can support TLS, and a significant fraction of corporate mail servers have that support active. The big part of the Nevada mandate for encryption is that if Nevada companies follow it by the simplest approach of only sending mail over TLS sessions, they will have to stop  sending mail to MTA's that do not offer TLS service. Few if any of the major consumer ISP's and mail providers in the US offer it today.</description>
		<content:encoded><![CDATA[<p>Speaking as a mail geek, this is not really as onerous as it sounds. There are essentially two kinds of email encryption: content encryption and transport encryption. Content encryption has to be done by end users&#8217; mailer programs (aka &#8220;MUA&#8217;s&#8221;: Mail User Agents)   and encrypts the mail before it leaves the machine that it is composed on. Recipients have to also support the same kind of content encryption and have enough of a relationship with the sender that they can decrypt the mail sent to them. There are two incompatible standards for content encryption, PGP and S/MIME, and both of them have problems that are visible to end users.   Transport encryption  is done using TLS (and its predecessor SSL) and is handled almost  invisibly to end users, sometimes between MUA&#8217;s and the mail servers (MTA&#8217;s: Mail Transport Agents) they hand mail to and commonly between MTA&#8217;s. Transport encryption means that the entire communications channel between machines is encrypted, i.e. not just the contents of mail but the entire conversation that is carried out between sending and receiving systems to offer mail from a sender to one or more recipients. Because businesses transfer mail outside of their own realms almost only through MTA-MTA communications and because it protects the sender and recipient addresses from snooping in transit, using transport encryption would satisfy the Nevada law and do so better than having everyone who writes email get personal mail encryption certificates or publish PGP keys. </p>
<p>All modern mail server software can support TLS, and a significant fraction of corporate mail servers have that support active. The big part of the Nevada mandate for encryption is that if Nevada companies follow it by the simplest approach of only sending mail over TLS sessions, they will have to stop  sending mail to MTA&#8217;s that do not offer TLS service. Few if any of the major consumer ISP&#8217;s and mail providers in the US offer it today.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
