<p>wikipedia defines SPF as <b>Sender Policy Framework</b> (<b>SPF</b>), as defined in <a href="http://tools.ietf.org/html/rfc4408" class="extiw" title="rfc:4408">RFC 4408</a>, is an <a href="http://en.wikipedia.org/wiki/Email" title="Email">e-mail</a> validation system designed to prevent <a href="http://en.wikipedia.org/wiki/E-mail_spam">e-mail spam</a> by tackling <a href="http://en.wikipedia.org/wiki/E-mail_spoofing" title="E-mail spoofing">source address spoofing</a>, a common vulnerability. SPF allows administrators to specify which <a href="http://en.wikipedia.org/wiki/Host_%28network%29" title="Host (network)">hosts</a> are allowed to send e-mail from a given domain by creating a specific <a href="http://en.wikipedia.org/wiki/List_of_DNS_record_types" title="List of DNS record types">SPF record</a> in the public <a href="http://en.wikipedia.org/wiki/Domain_Name_System">Domain Name System</a> (DNS). <a href="http://en.wikipedia.org/wiki/Mail_exchanger" title="Mail exchanger" class="mw-redirect">Mail exchangers</a> then use the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain's administrators</p><p> and DKIM <b>DomainKeys Identified Mail</b> (DKIM) is a method for associating a <a href="http://en.wikipedia.org/wiki/Domain_name">domain name</a> to an email, thereby allowing an organization to take responsibility for a message in a way that can be validated by a recipient.</p><p>I understand the difference but they are both trying to accomplish the same thing which to me translates into if I get an email from the bank I KNOW it really came from the bank.  I don't really care which route Mercury goes but wish it would choose one.</p><p>I also knew the date of the article was from 2008 and was using it to simply show how long Google and others have been doing this for their users and I wish I could provide to to mine.</p><p>Cheers,</p><p> Jim</p><p> </p>

<P>Anyone know if SPF support will be added to Mercury32 or if there is a 3rd party addon that will work with it ?</P> <P mce_keep="true">Thanks</P>

<P>No official plans to support SPF to my knowledge, nor any external tools as Mercury alone does all IP.</P> <P>I hope we're getting there though, also regarding Reverse Lookup - but I imagine a lot needs to be accomplished in respect to multiple domain support first, also thinking about how to configure restrictions like these - and in the longer run including IPv6, IPSEC and DKIM.</P>

<p>I guess most of these could be done with a daemon now - like Lukas does with greylisting.</p><p>Personally, I would only be interested in ptr lookup and possibly DKIM. SPF isn't useful enough for me. </p><p> </p>

[quote user="PaulW"] <P>I guess most of these could be done with a daemon now - like Lukas does with greylisting.</P> <P>Personally, I would only be interested in ptr lookup and possibly DKIM. SPF isn't useful enough for me. </P> <P> </P> <P>[/quote]</P> <P mce_keep="true"> </P> <P>Now, there's an idea!  Greylisting exemption for SPF pass or best-guess MX ...</P> <P mce_keep="true"> </P> <P>Cheers,</P> <P>Sabahattin</P> <P mce_keep="true"> </P>

<p>I simply want to add my voice as being in support of SPF.  Even if you could only tag messages as having passed SPF you could use it on certain domains like banks, ebay, paypal, etc where it is more important that these kind of emails don't slip through.   I have content control setup now that seems to catch everything, but if someone ever changes their ip I need to change my filter rule. although so far that has never actually happened. </p><p> </p><p> </p>

<h3><b>This is why I think spf or dkim is so important,  </b>google has been doing this for quite a while now. </h3><p><a href="http://gmailblog.blogspot.com/2008/07/fighting-phishing-with-ebay-and-paypal.html">Fighting phishing with eBay and PayPal</a> </p> <p class="post-subhead"> Tuesday, July 08, 2008 | 7:01 AM </p> <div class="post-body"> <p><span class="byline-author">Posted by Brad Taylor, Software Engineer and Gmail Spam Czar</span> <a href="http://googleblog.blogspot.com/2008/04/how-to-avoid-getting-hooked.html">Phishing</a> messages are a form of spam that attempt to deceive recipients to gain access to their personal information. A classic one is a message that appears to come from PayPal and attempts to get someone's PayPal password in order to drain his or her account. These fraudulent messages often look very official and can fool people into responding with personal information. Gmail does its best to put a red warning label on phishing messages, but it can be hard for us to know sometimes and we can't be 100% perfect. So, for the fraction of a time when Gmail misses it, you may end up squinting three times and turning the message sideways before suspecting that it's phishing. Wouldn't it be better if you never saw phishing messages at all, not even in your spam folder? Since 2004, we've been supporting email authentication standards including DomainKeys and DomainKeys Identified Mail (DKIM) to verify senders and help identify forged messages. This is a key tool we use to keep spam out of Gmail inboxes. But these systems can only be effective when high volume senders consistently use them to sign their mail -- if they're sending some mail without signatures, it's harder to tell whether it's phishing or not. Well, I'm happy to announce today that by working with eBay and PayPal, we're one step closer to stopping all phishing messages in their tracks. Now any email that claims to come from "paypal.com" or "ebay.com" (and their international versions) is authenticated by Gmail and -- here comes the important part -- rejected if it fails to verify as actually coming from PayPal or eBay. That's right: you won't even see the phishing message in your spam folder. Gmail just won't accept it at all. Conversely, if you get an message in Gmail where the "From" says "@paypal.com" or "@ebay.com," then you'll know it actually came from PayPal or eBay. It's email the way it should be. eBay and PayPal have worked hard to ensure that all their email is signed with DomainKeys and DKIM. Armed with this information, Gmail can easily reject as a fake anything that doesn't authenticate. We've been testing this for a few weeks now and it's working so well that few people really noticed. We think it's great that PayPal and eBay have taken on the challenge of securing email, and we're pleased to have put our best efforts together to make this work. It's a bold move, but one that will really help fight phishing. Our hope is that this will set a good example for other organizations to follow (yes, it can be done!) and that over time more and more email will become trustworthy. </p> </div>

<P>That article (pre-dating all this thread) is just about DKIM - nothing to do with SPF.</P> <P>It would probably be better to start a new thread if you want to discuss DKIM.</P>