<?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: Encryption tutorial for Mail.app</title>
	<atom:link href="http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/</link>
	<description>Tips and add-ons to make Apple Mail / Mail.app even better</description>
	<pubDate>Fri, 09 Jan 2009 04:28:21 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: TenaciousMC</title>
		<link>http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-141155</link>
		<dc:creator>TenaciousMC</dc:creator>
		<pubDate>Wed, 16 May 2007 18:59:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-141155</guid>
		<description>I've read that the certificate is only good for the computer it was issued on. Does this mean that I can't use it on another Mac with the same user profile and settings? I was able to sync my keychain between 2 Macs using .Mac and see my public/private keys on the other Mac's keychain. Should it still be able to work on the other Mac? I would like to be able to encrypt/sign email from a portable Mac when I'm away from home. Thanks!</description>
		<content:encoded><![CDATA[<p>I&#8217;ve read that the certificate is only good for the computer it was issued on. Does this mean that I can&#8217;t use it on another Mac with the same user profile and settings? I was able to sync my keychain between 2 Macs using .Mac and see my public/private keys on the other Mac&#8217;s keychain. Should it still be able to work on the other Mac? I would like to be able to encrypt/sign email from a portable Mac when I&#8217;m away from home. Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Michael</title>
		<link>http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-107240</link>
		<dc:creator>Michael</dc:creator>
		<pubDate>Sun, 18 Mar 2007 10:15:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-107240</guid>
		<description>PGP is another nice option, but it won't interface it with Mail. Sente's have written a plugin:

http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html

But, as they say, it taps into a "private internal API", so it's not an ideal solution.

There's also a little more for the user to do in setting up PGP; and there's a passphrase to remember. I don't know that the latter is too great a handicap, since if you follow one recommendation and make up a "shocking nonsense" phrase -

http://www.informationweek.com/management/showArticle.jhtml?articleID=164303537&#38;pgno=2&#38;queryText=

- you can have a very long but quite memorable passphrase. Lines out of Lewis Caroll or Lear are probably memorable partly _because_ they're nonsensical. Similarly, you're not likely to forget a silly sentence you make up (not that you shouldn't write it down and lock it away somewhere).</description>
		<content:encoded><![CDATA[<p>PGP is another nice option, but it won&#8217;t interface it with Mail. Sente&#8217;s have written a plugin:</p>
<p><a href="http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html" rel="nofollow">http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html</a></p>
<p>But, as they say, it taps into a &#8220;private internal API&#8221;, so it&#8217;s not an ideal solution.</p>
<p>There&#8217;s also a little more for the user to do in setting up PGP; and there&#8217;s a passphrase to remember. I don&#8217;t know that the latter is too great a handicap, since if you follow one recommendation and make up a &#8220;shocking nonsense&#8221; phrase -</p>
<p><a href="http://www.informationweek.com/management/showArticle.jhtml?articleID=164303537&amp;pgno=2&amp;queryText=" rel="nofollow">http://www.informationweek.com/management/showArticle.jhtml?articleID=164303537&amp;pgno=2&amp;queryText=</a></p>
<p>- you can have a very long but quite memorable passphrase. Lines out of Lewis Caroll or Lear are probably memorable partly _because_ they&#8217;re nonsensical. Similarly, you&#8217;re not likely to forget a silly sentence you make up (not that you shouldn&#8217;t write it down and lock it away somewhere).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Peter</title>
		<link>http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-104953</link>
		<dc:creator>Peter</dc:creator>
		<pubDate>Wed, 14 Mar 2007 17:20:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-104953</guid>
		<description>I went ahead and wrote a short write up on installing GnuPG and all its other goodies in Mail.app... I personally prefer GnuPG for my email encryption... since its based on PGP a lot of people are familiar with it.  In any case my short write up is &lt;a href="http://www.threehorsemen.org/2007/03/14/gnupg-and-mailapp-plus-other-assorted-gnupg-goodies/" rel="nofollow"&gt;here&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>I went ahead and wrote a short write up on installing GnuPG and all its other goodies in Mail.app&#8230; I personally prefer GnuPG for my email encryption&#8230; since its based on PGP a lot of people are familiar with it.  In any case my short write up is <a href="http://www.threehorsemen.org/2007/03/14/gnupg-and-mailapp-plus-other-assorted-gnupg-goodies/" rel="nofollow">here</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gibbons Burke</title>
		<link>http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-99312</link>
		<dc:creator>Gibbons Burke</dc:creator>
		<pubDate>Fri, 09 Mar 2007 19:06:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-99312</guid>
		<description>My only problem using encryption is that some of my correspondents have mail systems that don't know S/MIME from a hole in the ground, and in some case are openly hostile to them - treating them as potential malware.

In other cases, posting a 'signed' message to some mailing lists will munge the message so the recipient sees a warning about a possible man in the middle attack, which is perfectly justified - it's doing exactly what a signed message is intended to do - let the user know the message has been tampered with en route to the destination.

So, given the current technological reality, it would be great if Apple Mail would allow you to specify signature and encryption preferences on a per user basis. Currently Mail defaults to the setting for your most recent email sent. That way if I'm sending an email to a Yahoo Group or a Google Group mailing list it will be sent unsigned. To recipients whose certificates I have it would automatically encrypt those messages, etc.

IF I know that so and so uses a particularly brain-dead version of some mail program that doesn't recognize them, or folks who don't understand the technology and think it is suspicious, I can elect not to sign messages to them - but I'd like to be able to make that determination once and not have to remember to change my encryption settings with each email I send.</description>
		<content:encoded><![CDATA[<p>My only problem using encryption is that some of my correspondents have mail systems that don&#8217;t know S/MIME from a hole in the ground, and in some case are openly hostile to them - treating them as potential malware.</p>
<p>In other cases, posting a &#8217;signed&#8217; message to some mailing lists will munge the message so the recipient sees a warning about a possible man in the middle attack, which is perfectly justified - it&#8217;s doing exactly what a signed message is intended to do - let the user know the message has been tampered with en route to the destination.</p>
<p>So, given the current technological reality, it would be great if Apple Mail would allow you to specify signature and encryption preferences on a per user basis. Currently Mail defaults to the setting for your most recent email sent. That way if I&#8217;m sending an email to a Yahoo Group or a Google Group mailing list it will be sent unsigned. To recipients whose certificates I have it would automatically encrypt those messages, etc.</p>
<p>IF I know that so and so uses a particularly brain-dead version of some mail program that doesn&#8217;t recognize them, or folks who don&#8217;t understand the technology and think it is suspicious, I can elect not to sign messages to them - but I&#8217;d like to be able to make that determination once and not have to remember to change my encryption settings with each email I send.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jrk</title>
		<link>http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-97897</link>
		<dc:creator>jrk</dc:creator>
		<pubDate>Fri, 09 Mar 2007 00:02:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-97897</guid>
		<description>I used just such a setup for some time, but found that some servers -- notably, I believe, some Exchange configurations (all of Nokia, for example) -- filtered the 100% of Mail.app S/MIME-signed messages as likely virus/spam.  In a time when it's already worrying enough, wondering if your messages are ever arriving at the intended recipient, having unexpected per-recipient (rather than per-message) black holes is much worse, still.

Has anyone had any better luck or noticed if this issue has generally been resolved?</description>
		<content:encoded><![CDATA[<p>I used just such a setup for some time, but found that some servers &#8212; notably, I believe, some Exchange configurations (all of Nokia, for example) &#8212; filtered the 100% of Mail.app S/MIME-signed messages as likely virus/spam.  In a time when it&#8217;s already worrying enough, wondering if your messages are ever arriving at the intended recipient, having unexpected per-recipient (rather than per-message) black holes is much worse, still.</p>
<p>Has anyone had any better luck or noticed if this issue has generally been resolved?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Elwing</title>
		<link>http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-96930</link>
		<dc:creator>Elwing</dc:creator>
		<pubDate>Thu, 08 Mar 2007 14:53:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.hawkwings.net/2007/03/08/encryption-tutorial-for-mailapp/#comment-96930</guid>
		<description>One thing I'll warn people about if they really get into using (S/MIME) encrypted e-mail is a "bug" in Tiger.  In order to check the revocation information of the certificate, Tiger downloads CRLs into a local database for caching.  Only problem is that it doesn't clear this cache, and after a year (or so) of using certificates, it will appear that Mail is crawling.  The solution to this is to run
/usr/bin/crlrefresh r p
on a "regular" basis.  I have it in my /etc/weekly.local file because I use certificates so much, but it could probably go in monthly.local just as easily (or run manually from time to time).</description>
		<content:encoded><![CDATA[<p>One thing I&#8217;ll warn people about if they really get into using (S/MIME) encrypted e-mail is a &#8220;bug&#8221; in Tiger.  In order to check the revocation information of the certificate, Tiger downloads CRLs into a local database for caching.  Only problem is that it doesn&#8217;t clear this cache, and after a year (or so) of using certificates, it will appear that Mail is crawling.  The solution to this is to run<br />
/usr/bin/crlrefresh r p<br />
on a &#8220;regular&#8221; basis.  I have it in my /etc/weekly.local file because I use certificates so much, but it could probably go in monthly.local just as easily (or run manually from time to time).</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.498 seconds -->
<!-- Cached page served by WP-Cache -->
