Hi John, I have a separate message commenting on your other topics (subj).
For now, I wanted to respond to this specific question.
Out of curiosity, how do you handle the following problem:
Assume that mail is sent to someuser(_at_)host1 with a reverse-path
of maybebogus(_at_)odd-domain, and that the relevant DNS records are
host1 IN MX 10 host2
IN MX 20 host3
host2 is configured for CBV checking; host3, for whatever
reason, is not. The message reaches host3 (it is a bit bigger,
more responsive, and better connected -- for purposes of
simplicity, assume there are no firewalls or other middleboxes
involved). Host3 tries to pass it along to host2. When host2
attempts CBV validation, it gets a DNS timeout on the host1
domain -- note a timeout, not an authoritative "no" answer.
Since it is configured to not accept messages unless it can do
the validation, it returns a 4yz code to host3, resulting in
host3 requeuing and retrying the message, perhaps for a long
time. Host3 considers that behavior mildly antisocial, since
this is not its problem.
Your thoughts?
As with any scenario, the CBV has no choice but to issue a 4xy response
with the likely situation that the DNS timeout is only temporary (it better
be) and the sender host honors the 4xy response as a signal to retry.
In this case, the reality is that if the CBV has a DNS timeout problem then
so will host2 when it tries to do normal outbound mail operations. :-) So
the real problem here is getting the admins to fix his DNS client/query
operations on host2. Whatever problems host2 will experience as a send
mail machine, so will the CBV. So as one of my customers painfully learned
and pointed our when beta testing wcSAP, let me quote him: "....make damn
sure you have good DNS! [sic]"
No doubt, WCSAP has definitely become in a way, "SMTP Compliancy Tester."
It has helped many of my customers realize many inherent issues with their
setup one way or another. CBV is the final test of a group 4 test
performed I have lumped together called wcSAP. From the configuration file:
EnableFilterCheck True ; check white/black filter list
EnableDMPCheck True ; perform new DNS based DMP check
EnableRBLCheck True ; perform RBL database check
EnableCBVCheck True ; perform CallBack Verification
So the customer has the power to define what checks he wants to do.
The White/Black Rules/Filter list is where I have reject/accept rules I call
DIP attributes (Domain/IP pairs). For example for the imc mailing list:
accept if %DIP% = mail.imc.org[208.184.76.39]
accept if %DIP% = imc.org[208.184.76.39]
accept if %DIP% = jck.com[209.187.148.211] ; John Klensin (IETF-SMTP)
As you can see, I added a DIP for you to avoid the unnecessary overhead. :-)
and btw, recently I had a DIP for the site www1.imc.org site:
accept if %DIP% = www1.ietf.org[132.151.6.22]
because I was getting mail from mailserv(_at_)www1(_dot_)ietf(_dot_)org which
is not a
verifiable return path. Here is one of the rejection logs for it:
-------------------------------------
state : rcpt
cip : 132.151.6.22
cdn : optimus.ietf.org
from : <mailserv(_at_)www1(_dot_)ietf(_dot_)org>
rcpt : <winserver(_dot_)support(_at_)winserver(_dot_)com>
srvdom : winserver.com
srvip : 208.247.131.9
sapfilter : pass
sapdmp : skipped
saprbl : testing 22.6.151.132.sbl.spamhaus.org
saprbl : testing 22.6.151.132.list.dsbl.org
saprbl : testing 22.6.151.132.bl.spamcop.net
sapcbv : total mx records: 0
try domain : www1.ietf.org ip: 132.151.1.19
# connecting to 132.151.1.19
! connect error 10060
smtp code : 452
reason : Rejected by WCSAP CBV
Is it CBV's fault that this site is using a bad return path? It is just
returning the truth - this site is setup incorrectly.
What if there were no CBV and my system accepted the message and performed a
post smtp recipient validation (such as for our UUCICO gateway people)?
Now the burden is on our system because this site is not reachable to send a
DSN. Wouldn't it be anti-social that this www1.imc.org has not incurred
overhead on my system?
Luckily, the 452 response allowed the mailserv send mail server to retry and
I was able to see a system that was retrying.
This is a very IMPORTANT concept because in general a real SPAMMER will not
retry to send a rejected message. This is an undisputable emperical
behavior of spammers. They might try other new messages, but they will not
try the same message when it was rejected by you. If this was not the
case, not only the CBV proof of concept is now weaker, but the industry spam
problem would exponentially multiply!
The DMP DNS Lookup for local domain spoof checking or whatever domains the
admin specifies:
DMPTestDomain winserver.com ; domains to test with DMP
DMPTestDomain santronics.com
DMPTestDomain pan-am.ca
DMP helps eliminates local domain spoofing 100% with my DMP records in my
DNS server. As I mentioned in other messages, the DNS based lookup proposal
suffer when the domains are unknown and since we know most of the spammers
are unknown, this can be a major overhead on your system.
The RBL lookup does what probably is the #1 anti-spam prevention system
available today using central DNS databases such as bl.spamcop.net. It
rejects atleat 60% of the total attempts.
And finally the CBV is the final test if it passes the first 3. There are
my CBV options for it:
;---------------------------------------------------------------------
Section CBV Options ; Callback Verifier
;---------------------------------------------------------------------
; cbv connect options
NoDomainReject True ; Reject if remote has no domain ip (A)
record
NoMXReject True ; Reject if remote has no mx record
NoMxTryDomain True ; if true, try to connect to domain ip
address
; cbv session options
SocketWaitTime 35 ; SMTP response wait time
UseNoop True ; Send NOOP to help identify WCSAP
UseEhlo False ; Try EHLO, fallback to HELO
UseVRFY False ; Try VRFY, fallback to RCPT TO
SapHost mail.winserver.com ; ** USE YOUR MX DOMAIN! **
SapMailFrom <> ; address used for MAIL FROM
; cbv open relay options
UseRSET True ; Solves 1 RCPT limit for MAIL FROM:
<>
OpenRelayCheck True
RejectOpenRelay True
OpenRelayAddress wcsap-openrelay-test-123sxa23(_at_)alqwejad(_dot_)com
;---------------------------------------------------------------------
Section SMTP Response Codes
;---------------------------------------------------------------------
rescode_filter 554 ; rejected by wcSAP Filter
rescode_dmp 554 ; rejected by DMP Lookup
rescode_rbl 554 ; rejected by RBL lookup
rescode_nodomain 452 ; no domain ip or dns failed
rescode_nomx 552 ; no MX records
rescode_connect 452 ; can not connect
rescode_welcome 452 ; no initial welcome
rescode_helo 552 ; helo/ehlo failed
rescode_from 552 ; MAIL FROM: failed
rescode_rcpt 552 ; RCPT TO: failed
rescode_relay 552 ; Site is an open relay
The result of all this?
For my site, well, zero spams in the last 12000 transaction attempts the
last 3 days. These results can not be ignored by me, yet, I am continuing
to see how to optimize the process. Like you, the idea of a SMTP based
call back leaves a quesy feeling in your stomach. But damn it, it works!
:-)
Will it work in a large scale deployment?
Of course, I always see major issues with everyone calling each other all
over the place. But that does not mean the proof of concept is bad. It
means that we need to figure out a way to make "return path validation" work
for deployment. I see a few solutions and its largely based on building
server relationships and/or validation networks I called VISP (Validation
Internet Service Provider).
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com