<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>dmiessler.com | grep understanding - Latest Comments in Email Authentication (SPF)</title><link>http://danielrm26.disqus.com/</link><description>dmiessler.com/about/</description><atom:link href="https://danielrm26.disqus.com/email_authentication_spf/latest.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Thu, 08 May 2008 00:45:29 -0000</lastBuildDate><item><title>Re: Email Authentication (SPF)</title><link>http://dmiessler.com/blog/email-authentication-spf#comment-4357650</link><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;&lt;br&gt;&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;&lt;br&gt;&lt;/p&gt;&lt;p&gt;Exo&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Exothrmicus</dc:creator><pubDate>Thu, 08 May 2008 00:45:29 -0000</pubDate></item><item><title>Re: Email Authentication (SPF)</title><link>http://dmiessler.com/blog/email-authentication-spf#comment-4357649</link><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;&lt;br&gt;&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;&lt;br&gt;&lt;/p&gt;&lt;p&gt;Cement Head&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Cement Head</dc:creator><pubDate>Fri, 04 Apr 2008 18:35:09 -0000</pubDate></item><item><title>Re: Email Authentication (SPF)</title><link>http://dmiessler.com/blog/email-authentication-spf#comment-4357648</link><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;&lt;br&gt;&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;&lt;br&gt;&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;&lt;br&gt;&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;&lt;br&gt;&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><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Steven G. Harms</dc:creator><pubDate>Mon, 11 Feb 2008 22:23:28 -0000</pubDate></item></channel></rss>