Sender Policy Framework: details revealed

Sender's identification problem

 E-mail has recently become so popular that it penetrated to all the spheres of
human life. Of course you can use e-mail for chatting with friends but on the
other hand it can be used for sending such extremely important messages that may
influence senders or receiver's welfare, health and even life.

At the same time one of the main problems of using electronic messages
transmission protocol (SMTP simple mail transfer protocol) is the absence of
sender's identification. That means that you are never quite sure whether the
person that is mentioned as sender really sent this e-mail. Such defect leaves
lots of possibilities of using e-mail by fraudsters or for sending spam and
viruses.

There are some examples of messages with forged sender's addresses: spam, which
was sent to contacts contained in the address book on behalf of the owners of
the address books, fishing messages Ж messages masqueraded as being sent from
well known banks that are sent by the malicious people to get the logins and
passwords of clients.

Main SPF principles

SPF and Sender ID technologies appeared two years ago and were intended for fast,
easy and clear identification of the e-mail sender. Their essence is quite easy:
system administrator publishes the rules in the DNS information fields,
connected to his domain name, so that it's possible to check whether the sender
with such address sent the letter from this domain. Rules are quite easy and in
general these are the list of IP-addresses of the servers that can send e-mail
with the domain's return address.

 At first it seems that checking message conformity with SPF rules, which were
published by system administrators, can solve the problem of forged sender's
address. But even two years ago there were some doubts about its effectiveness.

The main argument against SPF is that valid mail can be sent through other
servers. It can happen, for example, if receiver has several mailboxes, and one
of them was chosen as main, so messages are forwarded there by means of mail
system. In this case sender is the same but mail relay would be changed and
sender check on receipt will fail. But if we admit that, while forwarding a
message, sender will be changed then if there are some problems on the
receiver's main mailbox real (original) sender will never know about it because
he will not get the bounce message.

That's why while using SPF checking as a characterizing way of declining
messages there is a possibility of having false positives. As it will be shown
below, they are not only possible but form significant part of mail stream and
that leads to being unable to use SPF checking for blocking junk mail.

SRS (Sender Rewriting Scheme) was developed to solve the problem of forwarding
messages through the mail servers. It allows finding out through which servers
and mail addresses the message has passed. But, in spite of SPF, SRS needs each
server that is transmitting messages to support SPF and SRS technology. This
leads to the necessity of modifying software on each server in the world and
that is practically impossible. Although doubts that the easy solution will
allow to get rid of SMTP protocol's defects appeared two years ago, during the
year of 2004 practically all big mail systems published their own SPF policies,
some of them started using SPF checking in their anti-spam products.

On the wave of SPF popularity within framework of MARID working group the
development of unified Sender ID standard, joining SPF and developed by
Microsoft Caller ID technology, was started. But they were finished quickly due
to deployment problems, connected with incompatibility with open-source licenses,
and incompatibility between Sender ID and classical SPF version. In July 2005
IETF (Internet Engineering Task Force) established two proposals of standard for
sender's authentication: Sender ID and SPF, as experiment. Since then no
innovations were planned.

SPF today 

We can use the results of analyze, taken on a small mail stream of not very big
hosting provider to mark the SPF's effectiveness.

 Logs per week were analyzed. For marking SPF effect they used the work results
of anti-spam filter that doesn't use SPF checking. We assume that at the time of
analyzing the filter didn't have false positives.

According to this statistics, 89% of messages were spam. This number is greater
than average capacity of spam because of the large number of spam-traps
installed by this provider. It turned out that 18% of analyzed messages had SPF
records for message senders' domains. Table 1 represents the results of
analyzing the messages sent from domains with SPF records divided into statuses
fail, soft-fail and pass (we do not take into account status neutral because it
is not informative).

Here "% of messages with SPF" Ж messages that gained such status and had SPF
record for sender's own domain as part of all messages. "% of the whole stream"
Ж messages with such status as part of the whole stream. "Crossing with spam" Ж
messages, which were marked "Spam" by spam-filter that didn't use SPF checking,
as part of the whole number of messages that gained such status.

If a message gained status "Fail", it means that provider had to refuse this
message as not corresponding to published strict policy of domain owner. It's
interesting to see that if the status was used this way, the process of
discovering spam would increase by a rate of 0.01%. On the other hand manual
investigation of log records of mail system by messages, which gained status
fail and were not recognized as spam by anti-spam filters, displayed that not
less than 1% of messages with status fail were followings of legal
correspondence from another address that means these were false positives.

If we consider that there was no other spam besides recognized by filter and
status fail then number of false positives by status fail is not less than 0.3%.
Actually this number is higher as undoubtedly there was spam that was not
recognized by any methods (in this case the number of non-spam messages
decreases, while number of false positives accordingly increases).

Gaining status soft-fail does not mean complete refusing messages by mail system,
but can be counted in addition to other methods. In fact, above-mentioned
figures show that approximately 0.3% of cases status soft-fail could increase
"spamity" a little in terms of multiple criteria spam filter.

Status pass means that sender was confirmed and the message with such state had
to be delivered to the recipient. But 20% of messages that gained status pass
were declared by installed filter as spam. As far as was assumed that there were
no false positives, these messages were put to the junk mail. In fact, it means
that if spammers use their own addresses as the sender's address they can
register their own SPF policy for their domain. Actually spammers use this
technique.

That's why in general while provider is receiving messages, SPF checking doesn't
have to affect the message receiving: gaining status fail doesn't mean that it
must be refused otherwise gaining status pass doesn't mean it must be accepted.

So, the characterizing SPF message checking can be provided only for determined
senders, about whom recipient clearly knows that firstly, he wants to receive
messages from them, secondly, their messages will be sent directly to
recipient's server, without relaying.

But putting such conditions on using the technology, which must have been clear
to the recipient, makes it useless. If recipient is willing to make some steps
to identify sender than the easiest way to do so would be just using sender's
signing and sign checking by recipient.

Reasons of SPF's failure 

Main reason of SPF's failure is that the new technology does not suite the
practice of mail using in quite simple question Ж e-mail sending. That's why in
spite of the fact, that the numbers of messages forwarded from one mailbox to
another is not big, incompatibility of forwarding with the new technology led
SPF to being practically useless.

The two years history of SPF development shows ones more how complicated
changing or adding a new functionality to widely used protocol of data
transferring can be. Technologies that propose ways of widening SMTP should
provide complete support of the protocol in all little peculiarities otherwise
they can't be developed properly.