----- Original Message -----
From: "Seth Goodman" <sethg(_at_)GoodmanAssociates(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, April 18, 2004 12:30 AM
Subject: RE: [spf-discuss] Security Paper on forgery bounce DDoS
-------------------------------------
I put forward the proposition that SES does everything that SPF+SRS does,
delivers more confidence in the end result and causes less breakage. Here
are some arguments to support this position.
Seth,
I'm exhausted discussion the merits of a CBV so I will try to keep this
short. I agree with you that a complete return path address verifier is
needed. However, you will find that no one system is sufficient. We use a
suite of methods we call wcSAP (Wildcat! Sender Authenticaion Protocol)
http://www.winserver.com/sslinfo
which is called by our wcSMTP mail system and also can be used as web
service. The web site shows statistics for the past 6-7 months with a
tester as well.
wcSAP does the following in this specific order (default)
sapfilter - internal white/black accept/reject rules
saprbl - rbl lookups
sapdmp - LMAP method: DMP support (deprecated)
sapspf - LMAP method: SPF support
sapcep - LMAP method: Microsoft CallerId Email Policy (CEP)
sapcbv - call back verifier
Before the LMAP methods were added, CBV proved to reject as high as 94% of
the spoofers. The proof of concept is overwhelming and honestly, anyone who
opposes it, simply hasn't put research into it. However, althought the
proof of concept that a dynamic return path verifier is desirable, the only
current way to do so is with a SMTP-based emulatiuon. This can also be an
expensive overhead item. So the search was on to perform logic that avoided
the CBV as much as possible.
We added DMP at first for its simplicity to see how it worked before adding
something more complex like SPF.
What we found is
1) High DNS overhead. This is especially true since 80% of all spam is
spoofed or bad domains (NXDOMAIN).
2) It worked EXCELLENT for LOCAL DOMAIN SPOOF protection.
Sorry for the caps, but I don't see that mentioned enough. The #1 benefit
the LMAP proposals gives you is protection for your own domains. Trust is
only available for remote domains when a REJECT is the result.
So to lower the overhead, options were added to do lookup DMP domains based
on a list the sysop defined.
Anyway, when AOL announced SPF support, we decided to add it too. We
eventually dumped DMP and also added CEP which was easy since it is a
basically a SPF clone.
Its been almost 1+ months now with all the LMAP methods and we have it
opened for all domain lookups, not just local domains to get some results.
Again, these are methods to help avoid the final CBV method if possible.
What I am finding so far is this:
1) It works great for rejection,
2) You still can't trust positive results. The SPF spammers are already
coming out.
3) It works great for a "Social Community" i.e. our customer base.
4) DNS issues still issue, especially when the DOMAIN doesn't exist, which
5) The CBV catches all that fall thru.
Once there is a wide deployment of sender machine DNS policies, it will help
in the spoofing area no doubt. But you also need to add your own DNS or
lookup result caching.
Finally, one thing we found is that you don't need do any validation of the
RCPT TO: fails. However, since many of the SMTP software or sysops who use
these systems are dependent on using a POST SMTP concept and/or don't have
or use a RCPT TO: validation step, this isn't often in their discussion
logic. However, this proved to be the #1 overhead reduction item. Why
bother if your receiver isn't going to accept the message anyway?. This
concept is actually highlighted in RFC 2821 with a delayed MAIL FROM
validation consideration statement. See RFC 2821 section 3.3.
See ya
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com