From: "Daniel Taylor" <dtaylor(_at_)vocalabs(_dot_)com>
From: "Scott Kitterman" <spf2(_at_)kitterman(_dot_)com>
I can't speak for anyone else, but since I've published a -all record,
the
number of bounce messages I've gotten due to forgery of my domain
I've been saying since day one - Relaxed polices are bad and it invites
trouble. As long as the relaxed provisions is around, SPF will always
be
plaqued with the same issues that SMTP had with its loopholes for
decades. SPF has help closed a hole in SMTP, yet, left a window
cracked open. It never made sense to me.
In my opinion, I highly suggest at the next opportunity to begin having a
"limited" or expiration concept for the relaxed provisions. Allow them
for
legitimate systems to migrate, but it can't be a perpetual policy.
In essence I agree with you (we publish strict), but I do not agree
with your conclusion.
There is a valid place for relaxed provisions during the transition
period, but it is the reputation systems that will result in the
actual change, not any arbitrary time limit.
Since relaxed provisions still say "this might be from us" forged
mail will count against reputation in any well designed reputation
system. This is obviously against the interests of the publishing
entity, so most publishers will gravitate toward strict policies
wherever they can.
However, since reputation systems are not part of SPF, I expect this
will take a while.
I see. Good point. I can see a combined solution, but in lieu of something
(like reputation) that puts weight of the relaxed results or any result for
that matter, it will be exploited and continue to be a "thorn on the side"
for SPF. In other words, it will be a common topic. Someone will always
bring up the issue on how to best handle the relaxed policies, especially
when you see its being used for over a year or more.
So while it might not be a big issue today, when we have a large adoption of
SPF protected domains, and it becomes harder to "completed" hide a return
path domain, the spammer will intentional seek relaxed domains as the most
targeted sites. They will not seek the strong policy domains.
I predict that if this isn't address in the relatively near future,
Developers of SPF servers will enforce it themselves by caching the first
time SPF transaction with a relaxed policy and setting its own time limits.
I started to program such a logic but didn't put into practice.
I can see the following:
1) First time SPF transaction with relaxed results arrives
2) Transaction is recorded with an EXPIRE = DATE + X months.
3) A one time message is sent to the domain sysop saying
Dear Sysop,
This is one time SPF Server Notification.
A transaction with the following details:
Date:
From:
To:
IP Address
has arrived. The message was accepted with
SPF SoftFail, Neutral result.
This system has set a local policy to no longer accept
softfail or neutral results from your system after X months.
This should give your rnetwork the time to migrate to
a 100% secured SPF network.
If you feel this notification is unwarranted, please
contact, spf-sysop(_at_)xxxxxxx
Thank you.
4) After X months, if the SPF relaxed policies still
exist, upon the next attempt is made to send email
from this SPF domain, it will be rejected with another
final notification indicating the rejection reason with
a reference the first notification.
Dear Sysop,
This is final SPF Server Notification.
A transaction with the following details:
Date:
From:
To:
IP Address
has arrived. The message was rejected due to
a expired local policy on your usage of
SPF SoftFail, Neutral results.
This system has set a local policy to no longer accept
softfail or neutral results from your system after X months.
If you feel this expiration notification is unwarranted, please
contact, spf-sysop(_at_)xxxxxxx
Thank you.
Don't laugh. <g> I see it happening if its gets to be a real problem down
the road. :-)
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com