<?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: Email Authentication (SPF)</title>
	<atom:link href="http://dmiessler.com/blog/email-authentication-spf/feed" rel="self" type="application/rss+xml" />
	<link>http://dmiessler.com/blog/email-authentication-spf</link>
	<description>in search of intervals</description>
	<pubDate>Thu, 04 Dec 2008 03:41:59 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7-RC1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Exothrmicus</title>
		<link>http://dmiessler.com/blog/email-authentication-spf/comment-page-1#comment-143042</link>
		<dc:creator>Exothrmicus</dc:creator>
		<pubDate>Thu, 08 May 2008 04:45:29 +0000</pubDate>
		<guid isPermaLink="false">http://dmiessler.com/blog/email-authentication-spf#comment-143042</guid>
		<description>&lt;p&gt;I would suggest that a parse friendly syntax be used in the header line, that way I can use a rule in a brain dead e-mail client to redirect such messages into a suspect mail folder.&lt;/p&gt;

&lt;p&gt;I have always favored spam filtering to simply flag a message with a header, than drop a message from reaching me.  I see way too many false positives getting flagged as spam to trust a filter deleting messages without my review.&lt;/p&gt;

&lt;p&gt;Exo&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I would suggest that a parse friendly syntax be used in the header line, that way I can use a rule in a brain dead e-mail client to redirect such messages into a suspect mail folder.</p>

<p>I have always favored spam filtering to simply flag a message with a header, than drop a message from reaching me.  I see way too many false positives getting flagged as spam to trust a filter deleting messages without my review.</p>

<p>Exo</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Cement Head</title>
		<link>http://dmiessler.com/blog/email-authentication-spf/comment-page-1#comment-134943</link>
		<dc:creator>Cement Head</dc:creator>
		<pubDate>Fri, 04 Apr 2008 22:35:09 +0000</pubDate>
		<guid isPermaLink="false">http://dmiessler.com/blog/email-authentication-spf#comment-134943</guid>
		<description>&lt;p&gt;The issue here isn't Google's, but rather Paypal's - they publish an SPF record that's weeny. Instead of declaring that they are sure that they are publishing all their potential mail relays and using a "-all" at the end of the SPF record, they use a "~all", which is the soft failure. Google is doing the "right" thing per the SPF standard and not failing for this, because Paypal said they weren't sure.&lt;/p&gt;

&lt;p&gt;So, the real question is, when will &lt;em&gt;PayPal&lt;/em&gt;, not Google, bite the bullet and change their SPF record to be certain.&lt;/p&gt;

&lt;p&gt;Cement Head&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>The issue here isn&#8217;t Google&#8217;s, but rather Paypal&#8217;s - they publish an SPF record that&#8217;s weeny. Instead of declaring that they are sure that they are publishing all their potential mail relays and using a &#8220;-all&#8221; at the end of the SPF record, they use a &#8220;~all&#8221;, which is the soft failure. Google is doing the &#8220;right&#8221; thing per the SPF standard and not failing for this, because Paypal said they weren&#8217;t sure.</p>

<p>So, the real question is, when will <em>PayPal</em>, not Google, bite the bullet and change their SPF record to be certain.</p>

<p>Cement Head</p>]]></content:encoded>
	</item>
	<item>
		<title>By: Steven G. Harms</title>
		<link>http://dmiessler.com/blog/email-authentication-spf/comment-page-1#comment-122160</link>
		<dc:creator>Steven G. Harms</dc:creator>
		<pubDate>Tue, 12 Feb 2008 03:23:28 +0000</pubDate>
		<guid isPermaLink="false">http://dmiessler.com/blog/email-authentication-spf#comment-122160</guid>
		<description>&lt;p&gt;Tough call on this one.  I mind a fairly large mail system and I doubt that we would ever want to move to using DKIM as a 'reject' ruleset ( I'm more in the Yahoo-Cisco DKIM vs. Microsoft SPF camp, but all protocols of this nature are an improvement ).&lt;/p&gt;

&lt;p&gt;I think there are some vendors out there  that provide &lt;em&gt;exceedingly good&lt;/em&gt; reputation blacklists -- but who wants to wager that that one critical client's email just &lt;em&gt;happens&lt;/em&gt; to run afoul of the filter?  &lt;/p&gt;

&lt;p&gt;As such I think the most common implementation will be rulesets which respond to the level of failure by injecting an X-header, altering the subject or setting some other flag.  Based on that flag big box mail architecture systems ( notes, exchange ) can alter the display to signify the level of failure.&lt;/p&gt;

&lt;p&gt;Deciding to write a local rule to do a deletion should be up to the user.&lt;/p&gt;

&lt;p&gt;I think that may be a good rule of mail systems administration in large organizations:  Only users have the power to write autodelete rules.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>Tough call on this one.  I mind a fairly large mail system and I doubt that we would ever want to move to using DKIM as a &#8216;reject&#8217; ruleset ( I&#8217;m more in the Yahoo-Cisco DKIM vs. Microsoft SPF camp, but all protocols of this nature are an improvement ).</p>

<p>I think there are some vendors out there  that provide <em>exceedingly good</em> reputation blacklists &#8212; but who wants to wager that that one critical client&#8217;s email just <em>happens</em> to run afoul of the filter?  </p>

<p>As such I think the most common implementation will be rulesets which respond to the level of failure by injecting an X-header, altering the subject or setting some other flag.  Based on that flag big box mail architecture systems ( notes, exchange ) can alter the display to signify the level of failure.</p>

<p>Deciding to write a local rule to do a deletion should be up to the user.</p>

<p>I think that may be a good rule of mail systems administration in large organizations:  Only users have the power to write autodelete rules.</p>]]></content:encoded>
	</item>
</channel>
</rss>
