Archive for the 'SPR' Category

New approach to SPF to stop receving spams from yourself!

Hello,

You probably have received  a spam from  your e-mail address  to yourself in the past. To stop this kind of abuse, people invested SPF technology.

A quick introduction to SPF

SPF(Sender Policy Framework)  allows administrators to specify which hosts  are allowed to send e-mail from the domain. To achieve this,  you  should create a TXT entry for you domain(s).

How it works

First of all, defining SPF record for your domains is not enough.  The receivers must also enable SPF query on the MTA or messaging gateway.

If SPF enabled on the remote box that receives email from you or spammers that use your domain,  the remote box issues a DNS TXT query to get your SPF records. It tries to match sender IP with the SPF records. If the sender remote IP does not match. It may accept the mail or not. It also depends on your SPF rule. If you create a rule ending with -all (deny does not match) the receiver will simply reject the mail during the SMTP session. If your rules have something else then -all (maybe ?all) , the receiver will continue the accept email from “your domain”.   You can visit http://www.openspf.org for details

The problem:

SPF sounds good but unfortunately, it has a problem!

SPF breaks SMTP forwarding case where an MTA forwards e-mail to someone. In this case SPF does not match the allowed host in SPF,even if the mail originated by your one of the allowed server.

Example. You send a mail to your friend’s Gmail account. But your friend forwards his mail at Gmail to his company email.

When your friend company email receives your email, it will try to match the sender IP (in this case it is Gmail IP address) with your SPF record(Because from is still your @domain). Hence you did not put  Gmail IPs to SPF records. The mail server will reject your legitimate mail.

If this rejected mail belongs to your boss,  it is inevitable to disable your SPF record immediately! So you will lose all functionality of the SPF. Also you will continue to receive spam from your domain! And again, your boss will not happy when he receives email from himself…

This scenario is vice-verse, your MTA/Gateway may reject someone’s mail because of forwarding issue.

What we did?

As SurGATE Labs R&D team, to stop receiving forgery mail from yourself, we did not want to create a solution by defining allowed hosts for your domains  in MTA/Gateway.

We changed behavior of SPF to work only for your own hosted domains on SurGATE. As you can see below, you can choose to SPF work only for your domains.  If you set SPF level 4(Reject mail when SPF resolves to softfail) and “Only for hosted domains”  your SurGATE will  not try SPF query for external domains. But If a spammer set from address to one of your domain, It will be rejected.

I believe that this is safer approach than native SPF. And your boss will not worry about issues mentioned above.

Ismail YENIGUL

SurGATE Labs CTO

method to prevent sender address forgery.