[Top] [All Lists]

Re: "Subject" in the envelope (was: Re: Comments requested on draft-malamud-no-soliciting-04.txt)

2004-01-27 06:49:37

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%   =[]
accept if %DIP%   =[]
accept if %DIP%   =[]  ; 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 site:

accept if %DIP% =[]

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        :
cdn        :
from       : <mailserv(_at_)www1(_dot_)ietf(_dot_)org>
rcpt       : <winserver(_dot_)support(_at_)winserver(_dot_)com>
srvdom     :
srvip      :
sapfilter  : pass
sapdmp     : skipped
saprbl     : testing
saprbl     : testing
saprbl     : testing
sapcbv     : total mx records: 0
try domain : ip:
# connecting to
! 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 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        ; domains to test with DMP

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   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)
NoMXReject           True        ; Reject if remote has no mx record
NoMxTryDomain        True        ; if true, try to connect to domain ip

; 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     ; ** 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.