Hi all,
So, I have been dealing with spam filtering for some time now for my
organization. I became aware of SPF today and after looking it over a bit,
I have some concerns that, in practice, it will do little to deliver on what
it promises, make it easier to detect spam.
First off, I am assuming that a majority of spam comes from people who are
tech savvy or at least, have access to tech savvy consultants and
programmers. This seems to be evident in the way the tactics of spammers
have continued to evolve in such a fashion that it is extremely hard to tell
spam is spam based on tactics that would have worked a year or two ago.
Furthermore, things are scarier now that spammers have enlisted hackers and,
as a result, have a virtual army of zombified home work stations that
continues to grow. The reason I bring this up is that any solution should
be evaluated from the perspective of what holes it leaves open, not
necessarily what holes it closes.
So, on the surface SPF sounds really good and it seems to be a good way to
prevent mail coming from unauthorized sources. However, this data will only
be available for those domains that configure it... the good guys. I should
also mention that it is going to be a lot of work for a lot of DNS admins to
set this up, especially those at large ISPs that support a lot of domains.
So, the cost of this solution is not necessarily trivial.
To compensate for the fact that not all domains will have the extra TXT
records added either through user and admin ignorance as well as actual lack
of support in some DNS configuration interfaces, I would think that most
MTAs could do nothing to determine whether mail from a sender domain that
had no SPF records was spam or not. At least, not until this became a
widely accepted standard on the order of having to have matching reverse DNS
records set up for your mail server. This could be a long road and it
depends entirely on how effective SPF is on preventing spam.
The biggest problem I see is that it breaks or is broken by "store and
forward" per RFC 974 and RFC 2821. How do you set up SPF so that mail can
be safely received by a secondary mail server and forwarded on to the
primary? I could see it being possible if a header is created by a mail
server that indicates it has already SPF marked an email validly or
invalidly. Then, a primary mail server could check this header when
receiving mail from its secondary. There are two issues with this: A) MTAs
would have to implement this mechanism and B) a security method would have
to be developed so that the primary mail server could ensure that the header
it sees was actually written by the secondary mail server and not injected
by the spammer or some other mail server along the way.
Until issues A and B are fully handled, SPF can not effectively work for any
site that has secondary, tertiary, etc mail servers set up for the domain.
Nothing prevents the spammers from writing an MTA that avoids sending spam
to the primary mail server for a domain. As stated above, spammers must be
assumed to be smart and able to find these holes.
At this point, it seems to me that SPF, in its current incarnation, does not
have much hope of being effective in detecting spam. However, on the
surface, it looks enticing. Thus, you can imagine why Microsoft has
announced they will start checking SPF records on Oct 1. Unfortunately,
what that means to me and other domain admins who are paying attention is
that we will have to publish SPF records or risk having less of our users'
valid email making it through to recipients. So far, it seems that SPF has
delivered a higher cost to administering mail services with little benefit
being delivered.
Joe Gilbert
Unix System Administrator
InsureSuite, Inc.