spf-discuss
[Top] [All Lists]

Re: SPF: Some Problems to Face but Seems Pretty Fair

2005-06-21 22:17:05
Boyd,

In my opinion, the only worthy note was from Jonathan de Boyne Pollard

| In Risks 23.23, Jonathan de Boyne Pollard bitterly points out
| that SPF is a short-term move in an arms race and that it fails
| to solve the underlying problems of SMTP (which include failure
| to authenticate message origins). He ends:

| "Perhaps the fact that widespread adoption of SPF will do
| serious damage to the SMTP mail architecture is a good thing. In
| the battle against unsolicited bulk mail, we've concentrated
| upon the wrong problem time after time, with mechanisms that
| address the wrong thing and that don't address the actual
| 'unsolicited' and 'bulk' qualities of undesirable mail. SMTP has
| become less usable, more patchy, and more balkanised with each
| new bodge, yet continues to bend and not quite break completely.
| Perhaps the adoption of SPF will turn out to be the straw that
| finally breaks the camel's back, and that thus finally forcibly
| weans us off this bad habit of addressing the wrong.

I am of  the opinion, that inevitably, there will be a new level of SMTP
operations that addresses the "Anonynmous sender, no
authorization/authentication requirement."  using new enforement rules.

The problem today is that none of it is enforcable and this is exactly what
the target malicious segement of the email population (aka spammers and
spoofers) are exploiting.

Until they are force to change, they have no reason to adopt to any new
scheme.

As only as the MAIL server wants to serve users in an open public internet,
the mail server needs to allow for senders that our not within their
domains.

The problem is that the senders are not be checked, and if so, it is based
on pre-existing considerations which is unreliable information.

With that said, I said a long time ago that at BEST,  SPF 100% protects your
own domains.  Your Local domains or hosted domains that are under your
control.

The unreliability comes when you attempt to use SPF to check other people's
domains (remote domains). This is where the confidence level drops simply
because you don't control remote domains and you don't know if they are
telling the truth or not.

In my opinion, the unreliability is multiplied 100 folds with the SPF
relaxed provisions concepts which attempt to address migration concepts and
forwarding problems.

So in my opinion,  a system that uses SPF needs to get their network ASAP in
order so that it is a PASS or FAIL system.  Nothing inbetween.  By keeping
relaxed provisions without any concept of expiration or limitations, well,
it is a "loophole" into the specification - plain and simple, and it will
get exploited, and has.  What happens is that the system needs to do more
when a SPF relaxed policy record is used.

For the pundits that say that a pure PASS/FAIL system can still be exploted
with zombie SPF sites,  my response will be that this is ok, because now we
have an accountability concept and if a zombie SPF site is finally detected,
it will be blocked.

For those who say, vanity domains is are inexpensive and the zoomie SPF site
now becomes gypsy zoombie site, then I say, there is no lost or gains
because this already happens today where we have NO form of checking at all.

Maybe this can be resolved by increasing the cost of domain registrations to
make it harder for spammers to bounce around.

In any case, I think SPF is good enough today to give us a baseline. It is
not the pot of gold, so R&D will continue and hopefully, one day, common
minds will finally realize "I give up - we really need to change SMTP" and
begin to write ESMTP v3.0.
(original SMTP = v1.0,  ESMTP = v2.0).

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



<Prev in Thread] Current Thread [Next in Thread>