----- Original Message -----
From: "jpinkerton" <johnp(_at_)idimo(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, December 16, 2004 2:48 AM
Subject: Re: [spf-discuss] Wildcat! SPF Support
A simple 2 lines of text, such as the following will work:
Santronics Software's Wildcat! Interactive Net Server (SMTP
Component)
See http://www.winserver.com/public/aup/antispamsupport.htm
Hector - it'll be on
http://spf.idimo.com/other_protocols.html
later today/tomorrow.
Thanks John! It is appreciated.
Have I missed any more "other protocols" which do something about
spoofing?
Personally, I believed the CBV (SMTP based call back verifier) is greatly
under-estimated form of a solution. There are many systems that use it.
Off hand, I know of about 4-5 systems that use it:
- Wildcat!
- Exim
- Verizon.net (big user of it, all mail to verizon.net are CBV checked)
and I don't recall special company names but there are definitely a few:
- 3rd party tools that offer CBV integration, I see them in our logs,
- Enterprise system mentioned using it, and
- Proxy services mentioned using it,
I am convinced from a proof of concept, it is one of the better methods to
address the spoof for the COMPLETE address. The beauty of a CBV is that it
inherently performs 3-4 levels of checks:
- Can you query the MX?
- Can you connect to the MX host(s)?
- Will it accept/reject the RCPT TO?
- It is a OPEN RELAY (accepts any RCPT TO)
From the earliest research, it proved to reject 94-98% of all spoofers and
we should not be surprise because the majority of the malicious transactions
are spoofed, fake or bad domains, etc.
You can see this high rate in our early field testing statistic in late
2003. I should note that one of the early BBS pioneers in the
telecommunication industry (since the 80s), we have always had a CBV system
in place. There are over 100 CBV 3rd party tools for our system that began
as modem based Caller ID verifiers and many evolving to support Email based
Caller ID verifiers for the internet. So started our solution as a CBV was
natural.
The problem was the overhead, especially for a wide-deployment. But will be
also true for any validation logic that attempts to do an open-ended test
for all incoming connections. You can also see the higher transaction
session times too that we wanted to reduced as well.
Regardless of the solution, if DNS was evolved, you will be faced with a
significant amount of NXDOMAIN overhead and/or NO result overhead.
So we got into the R&D into other solutions (like LMAP solutions) and new
smarter transaction logic (delay validation) to help reduce the DNS overhead
and need to do a CBV and also overall validation if it was not required to
do so. This was all finally realized and completed in late December 2003
and the system has been stable with little change since then. Our
customers are tickled pick (Free update for now <g>) and they have little to
no "spoof" problem. What usually gets by the 2821 checks are very little
and if so, they are typically filtered by the SPAM mail content rules at the
DATA point. We don't provide these rules. Just the hook/integration where
3rd party developers or admins can integrate Spam Assassin, NortonAV or
McAfee AVS, etc.
Sure we still get a few that fall through. For me personally, I might get
1-2 per week, maybe. That's it. Overall, very satisfied with the results
thus far.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office