Mercury Suggestions
SPF Support ?

wikipedia defines SPF as Sender Policy Framework (SPF), as defined in RFC 4408, is an e-mail validation system designed to prevent e-mail spam by tackling source address spoofing, a common vulnerability. SPF allows administrators to specify which hosts are allowed to send e-mail from a given domain by creating a specific SPF record in the public Domain Name System (DNS). Mail exchangers then use the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain's administrators

 and DKIM
DomainKeys Identified Mail (DKIM) is a method for associating a domain name

to an email, thereby allowing an organization to take responsibility

for a message in a way that can be validated by a recipient.

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.

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.

Cheers,

 Jim

 

<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>

Anyone know if SPF support will be added to Mercury32 or if there is a 3rd party addon that will work with it ?

Thanks

<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>

No official plans to support SPF to my knowledge, nor any external tools as Mercury alone does all IP.

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>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>

I guess most of these could be done with a daemon now - like Lukas does with greylisting.

Personally, I would only be interested in ptr lookup and possibly DKIM. SPF isn't useful enough for me.


<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"]

I guess most of these could be done with a daemon now - like Lukas does with greylisting.

Personally, I would only be interested in ptr lookup and possibly DKIM. SPF isn't useful enough for me.


[/quote]

 

Now, there's an idea!  Greylisting exemption for SPF pass or best-guess MX ...

 

Cheers,

Sabahattin

 

[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>

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>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>

This is why I think spf or dkim is so important,  google has been doing this for quite a while now.

Fighting phishing with eBay and PayPal

Tuesday, July 08, 2008 | 7:01 AM



Phishing

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.

<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>

That article (pre-dating all this thread) is just about DKIM - nothing to do with SPF.

It would probably be better to start a new thread if you want to discuss DKIM.

<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>
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft