<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Verifying Smime content with openSSL</title>
	<atom:link href="http://lair.moria.org/blog/archives/123/feed" rel="self" type="application/rss+xml" />
	<link>http://lair.moria.org/blog/archives/123</link>
	<description>Unix, Information Security &#38; Systems Administration</description>
	<lastBuildDate>Fri, 25 Jun 2010 08:09:59 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.5</generator>
	<item>
		<title>By: Shaun Dewberry</title>
		<link>http://lair.moria.org/blog/archives/123/comment-page-1#comment-79</link>
		<dc:creator>Shaun Dewberry</dc:creator>
		<pubDate>Mon, 01 Sep 2008 22:23:17 +0000</pubDate>
		<guid isPermaLink="false">http://lair.moria.org/blog/?p=123#comment-79</guid>
		<description>Ah yes, the old corporate email disclaimer that gets bolted on haphazardly at the mail gateway, often using nothing more than a sendmail rewrite kluge. I&#039;ve been fighting the battle against email disclaimers for over 5 years, specifically because of the integrity damage it does to a message. (and also cos its just a damned waste of bandwidth)

I came up with three solutions - 
1. Add an extra message header at the gateway, which references the URL of a message disclaimer (i.e. X-Disclaimer: Visit http://x.y/disclaimer). Not sure how well this gets through the legal minefield, but at least it doesn&#039;t mess with the email.
2. Plead ignorance, stupidity or incompetence when asked to add this functionality to corporate mail servers. (&quot;Sorry boss, I have no idea how to do that, but I think if we spend $$$++ we can get it&quot;)
3. Try and get everyone to add the standard corporate sig/disclaimer directly in their email client.

Perhaps some sort of &quot;network notaries&quot; system could be setup similar to Firefox extension Perspectives (http://www.cs.cmu.edu/~perspectives/firefox.html) which could turn the above &quot;strip and verify&quot; manual process into something more automated.</description>
		<content:encoded><![CDATA[<p>Ah yes, the old corporate email disclaimer that gets bolted on haphazardly at the mail gateway, often using nothing more than a sendmail rewrite kluge. I&#8217;ve been fighting the battle against email disclaimers for over 5 years, specifically because of the integrity damage it does to a message. (and also cos its just a damned waste of bandwidth)</p>
<p>I came up with three solutions &#8211;<br />
1. Add an extra message header at the gateway, which references the URL of a message disclaimer (i.e. X-Disclaimer: Visit <a href="http://x.y/disclaimer)">http://x.y/disclaimer)</a>. Not sure how well this gets through the legal minefield, but at least it doesn&#8217;t mess with the email.<br />
2. Plead ignorance, stupidity or incompetence when asked to add this functionality to corporate mail servers. (&#8220;Sorry boss, I have no idea how to do that, but I think if we spend $$$++ we can get it&#8221;)<br />
3. Try and get everyone to add the standard corporate sig/disclaimer directly in their email client.</p>
<p>Perhaps some sort of &#8220;network notaries&#8221; system could be setup similar to Firefox extension Perspectives (<a href="http://www.cs.cmu.edu/~perspectives/firefox.html">http://www.cs.cmu.edu/~perspectives/firefox.html</a>) which could turn the above &#8220;strip and verify&#8221; manual process into something more automated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Barry Irwin</title>
		<link>http://lair.moria.org/blog/archives/123/comment-page-1#comment-46</link>
		<dc:creator>Barry Irwin</dc:creator>
		<pubDate>Tue, 26 Aug 2008 11:04:30 +0000</pubDate>
		<guid isPermaLink="false">http://lair.moria.org/blog/?p=123#comment-46</guid>
		<description>Yes this does seem to be a failing in the way Thunderbird processes the S/MIME packaging. With encrypted content it does seem to work however.  The question also comes on whether the CERTIFICATE is valid, or whether the Signature is valid?  It would appear that no warning is issued when the signature of the .s7m is found to be valid.  Certificates are ignored it appears.</description>
		<content:encoded><![CDATA[<p>Yes this does seem to be a failing in the way Thunderbird processes the S/MIME packaging. With encrypted content it does seem to work however.  The question also comes on whether the CERTIFICATE is valid, or whether the Signature is valid?  It would appear that no warning is issued when the signature of the .s7m is found to be valid.  Certificates are ignored it appears.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anonymous</title>
		<link>http://lair.moria.org/blog/archives/123/comment-page-1#comment-42</link>
		<dc:creator>Anonymous</dc:creator>
		<pubDate>Mon, 25 Aug 2008 20:19:10 +0000</pubDate>
		<guid isPermaLink="false">http://lair.moria.org/blog/?p=123#comment-42</guid>
		<description>So, if I tell Outlook to just send the signed bit and not send the clear text mail as well, Thunderbird reads and displays the e-mail just fine, and the sif relay attaches the disclaimer as a seperate attachment (because there is no text portion for it to append to). But, to Thunderbird&#039;s discredit, it has happily parsed the .s7m attachment, without mentioning whether the cert is valid!</description>
		<content:encoded><![CDATA[<p>So, if I tell Outlook to just send the signed bit and not send the clear text mail as well, Thunderbird reads and displays the e-mail just fine, and the sif relay attaches the disclaimer as a seperate attachment (because there is no text portion for it to append to). But, to Thunderbird&#8217;s discredit, it has happily parsed the .s7m attachment, without mentioning whether the cert is valid!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

