From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
On Mon, 04 Jul 2005 14:07:37 EDT, Hector Santos said:
Sure, it's *LIKELY* to be a spoof, but:
1) It isn't a *positive* proof.
2) As a result, bouncing mail because of a failure
is quite the anti-social thing to do.
I agree with you with this legacy issues. But that is not what we are
talking about or dealing with here.
In short, we are talking about the IP::DOMAIN association defined by the
LMAP methodology which by the way, you support via your SPF record for your
email domain: vt.edu:
c:> nslookup - query=txt vt.edu
"v=spf1
ip4:128.173.0.0/16
ip4:198.82.0.0/16
mx
ptr a:lennier.cc.vt.edu
a:lyta.cc.vt.edu
a:dagger.cc.vt.edu
a:vivi.cc.vt.edu
a:steiner.cc.vt.edu
a:zidan e.cc.vt.edu
~all"
I intentionally separated each SPF directive by line to make it easier to
read for a reason discussed below.
For those not up to par with SPF, SPF allows one to expose a DNS policy
that defines this IP::DOMAIN association. It ask the question, "Can this
machine send mail on behalf of the email domain or possible client machine
domain?"
So the simple algorithm is to take the email domain from the 2821.MainFrom,
perform a DNS TXT lookup for this domain to get the above record.
Then you compare the connection IP address against the SPF directives and
mechanisms above to see if an IP is listed or
expanded from the directives. For your policy, if no match is found, you
have a "SoftFail" policy.
Before I discuss some opinions on your SPF record, I want to get this out of
the way:
In regards to the client domain name (HELO/EHLO), there is a 100% trusted
and reliable detection when the DOMAIN is your domain simply because you own
the domain. It is lightweight no-DNS SPF like consideration for local
domains checks on.
That is what I was referring to is 100% no false positive HELO spoof
detector when doing a LOCAL_IP::LOCAL_DOMAIN association check.
Now, I suppose you also want hear my PROS and CONS of your SPF policy. You
talk about me breaking the system? What you have done is in my view,
represents the bad side of SPF.
- relaxed provisions,
- wasted DNS overhead
First, look at what you just done with your SPF relaxed provision (~all).
You just invited all SPF spoofers to use your vt.edu domain to spoof and hid
behind your domain across the network.
Second, with such a long SPF policy you have added a higher DNS overhead on
the SPF server/receiver, and for what? Even if a mismatch is found, you
told the receiver "don't trust the result." So why bother?
Look at the number of DNS function calls needed here for your policy:
"v=spf1
ip4:128.173.0.0/16
ip4:198.82.0.0/16
1 mx
2 ptr a:lennier.cc.vt.edu
3 a:lyta.cc.vt.edu
4 a:dagger.cc.vt.edu
5 a:vivi.cc.vt.edu
6 a:steiner.cc.vt.edu
7 a:zidan e.cc.vt.edu
~all"
Although, you will argue DNS caching will save the day, the potential is
still there for long timeouts per attempt on a poorly setup system. You
just imposed 7 additional DNS lookups on the receiver. If you are sending a
significant amount of mail out, lets say, X number of systems, you have
just include the DNS overhead by a factor of 7 on each X system.
It big waste because you have RELAXED the results of the lookup. Why
Bother?
This is a prime example of where SPF attempts to close a loophole in SMTP
but opens up new ones.
So if you haven't guess by now, I am not a big fan of logic that has the
potential of creating more problems with any kind of relaxation,
specifically when its a new protocol. Here you are insinuating I am doing
things when in fact, I am not, but at the same time you have a much higher
potential in creating harm with your own setup.
I have been saying this since day one of SPF and now that more people are
implementing SPF, they are beginning to recognize the reason to have either
a HARD pass/reject or NOTHING at all.
But I understand the reasons for the relaxed results. The stated reason is
for migration which I agree. However, migration should come with an
expiration concept. So the first time a SPF receiver encounters a relaxed
SPF policy, a limit is set on its usage for X amount of time. It should not
be a forever thing.
In any case, with your SPF record, you have authorized SPF systems to add
more scrutiny to any email that has your domains associated with it. With
your relaxed policy, you added DNS overhead and you invited spoofers to
piggy back off your domain.
I should note that there is a recent discussion in the SPF-DISCUSS forum
regarding relaxed provisions. One fellow has discussed how he uses it with
an expiration concept augmented with a reporting/notification concept to get
a confirmation on its usage. Really cool. This has some merit and worth
exploring.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com