Gaven,
Your intuition is correct. Relaxed SPF (non-exclusive) policies is a major
source of contention for SPF. It is a flawed concept. SPF attempts to
close an SMTP loopholes but opens up new ones with such policies.
My recommendations has always been that they are limited or come with an
expiration concept.
The original goal of relaxed policies was to give implementators a change to
migrate to a strong exclusive policies. However, with no time limit or
expiration of such policies, all it has done is give the spammers the "mile"
to exploit with ease.
For our system, our stats show 44% of all SPF transactions are relaxed. Of
these, 66% are rejected using a CBV (Callback Verification). The statistics
is consistent month after month after month.
Until this is finally addressed, SPF will continue have a major thorn on its
side and give its pundits a reason for living.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Gaven Henderson" <Gaven(_at_)GavDogg(_dot_)net>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Saturday, September 03, 2005 6:32 PM
Subject: [spf-discuss] Exclusive v. Open SPF records
My apologies if this has already been discussed. I'm new to this forum and
the archives don't support searches. That said....
Does anybody else think that allowing for non-exclusive (?all) SPF records
completely kills the goal of Sender Policy Framework? Before everyone
responds to that, please consider my reasoning.
1. Non-exclusive SPF records do not improve the status quo in identifying
spoofed senders. Without SPF, MTAs know that a message is either sent by
the domain it claims to be from, or it MAY not be. With non-exclusive SPF
records, MTAs are left with the same determination. If all SPF records were
exclusive, then MTAs would know that messages are either real or not -
effectively changing the existing "grey area" to black by providing real
results.
In other words, if an SPF record allows for a soft fail, then it does not
allow for a hard fail. In that case, the SPF test either returns the result
"this is legit" or "this may not be legit" which is exactly where SMTP is
WITHOUT SPF
2. Non-exclusive SPF records force domains to publish a list of all
outbound servers. I can't believe that anybody thinks this is a bad thing.
For one, if the point of SPF is to separate valid from spoofed senders,
where do anonymous senders fit in? Is it not appropriate for a domain to
funnel all it's outbound messages through specific servers? After all, SMTP
authentication can be used to verify all stages of a domains internal
routing without having to publish anything on the internet. Does anybody
want to make the argument that workstations should send messages directly
instead of through its domain's official SMTP servers?
3. Non-exclusive SPF records make SPF a 'half-ass' solution. I know it's
the same basic point but if SPF still allows for spoofed MAIL FROMs then
it's not solving anything. While there are some creative ways out there for
MTAs to handle a soft fail, they all involve excessive connections,
bandwidth and delays which increases infrastructure demands while slowing
down message delivery. Keep in mind that with all that wasted money (and
time if it's not the same thing to you), you still don't know for certain if
a message is legitimate.
Spammers and hackers are smart and aggressive people, if you provide them an
inch, they will take a mile.
-Gaven
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com