spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Re: Fw: SRS vs BATV

2006-02-17 17:28:35
"Hector Santos" <spf-discuss(_at_)winserver(_dot_)com> writes:

Wildcat! has been uses CBV built-in for 3 years now very successfully and
makes up atleast ~25% of the total rejections we see.  I'm going to be
finish a CBV Draft I-D that I started last year, but it pretty straight
forward.

 - Use a NULL return path to avoid loopbacks

 - Skip CBV on POSTMASTER return-paths
   (must be accepted per spec)

Sorry, do you mean skips CBV for postmaster *recipient*, or mail-from
return path?  I can understand skipping CBV if the recipient is
postmaster, but not the sender.  After all, isn't the point of CBV to
check if the sender is following the spec by providing a valid return
address?

2) During a CBV, we check two addresses:

    - the original session return path
    - a random address to check for open relay

Can you elaborate on the random address?  This second check must be to
a separate IP address, namely that of the SMTP client, correct?  (As
opposed to the first one which goes to the MX record of the envelope
sender.)  How do you construct the random address?  This seems
slightly dangerous in that the sender might happen to trust you
without being an open relay.

3) By far, the CBV we seen coming into our system use a NULL return path.
However, the verizon.net implementation (or software it uses) uses some
special "return-path" which it uses to stop a loopback coming back to its
server.  I don't recommend this for CBV operations.

What actually appears to happen is that they try both.  Here is a
session in which verizon.net is calling back to an invalid address on
my SMTP server:

vms152pub.verizon.net (9) <== 220 scs.stanford.edu ESMTP 
vms152pub.verizon.net (9) ==> HELO sv16pub.verizon.net 
vms152pub.verizon.net (9) <== 250-scs.stanford.edu 
vms152pub.verizon.net (9) <== 250-STARTTLS 
vms152pub.verizon.net (9) <== 250 PIPELINING 
vms152pub.verizon.net (9) ==> MAIL FROM:<> 
vms152pub.verizon.net (9) <== 250 ok 
vms152pub.verizon.net (9) ==> RCPT 
TO:<xxx-test(_at_)scs(_dot_)stanford(_dot_)edu> 
vms152pub.verizon.net (9) <== 550 user unknown 
vms152pub.verizon.net (9) ==> RSET 
vms152pub.verizon.net (9) <== 250 ok 
vms152pub.verizon.net (9) ==> MAIL 
FROM:<antispam753242(_at_)west(_dot_)verizon(_dot_)net> 
vms152pub.verizon.net (9) <== 250 ok 
vms152pub.verizon.net (9) ==> RCPT 
TO:<xxx-test(_at_)scs(_dot_)stanford(_dot_)edu> 
vms152pub.verizon.net (9) <== 550 user unknown 
vms152pub.verizon.net (9) === EOF 

I think the reason they do this is that some people just think "bounce
messages are bad" and reject all bounces.  Ideally these people just
need to be educated about techniques like BATV to realize that real
bounce messages are good.  But I can understand why Verizon wants to
double check before rejecting the mail.

Interestingly, my server tries a CBV on verizon, and it immediately
rejects the connection with a 421, so maybe they track what CBVs are
in progress and don't let you connect back?


One final point.  I notice you don't make any effort to inform the CBV
site of what is going on.  I would argue that may be bad practice.  If
you are writing up an I-D about CBV, maybe you should suggest issuing
a NOOP operation.  For example, my mail server issues CBVs like this:

apex.listbox.com (R17) ==> 220 apex.listbox.com ESMTP Postfix 
apex.listbox.com (R17) <== EHLO scs.stanford.edu 
apex.listbox.com (R17) ==> 250-apex.listbox.com 
apex.listbox.com (R17) ==> 250-PIPELINING 
apex.listbox.com (R17) ==> 250-SIZE 10240000 
apex.listbox.com (R17) ==> 250-ETRN 
apex.listbox.com (R17) ==> 250 8BITMIME 
apex.listbox.com (R17) <== RSET 
apex.listbox.com (R17) ==> 250 Ok 
apex.listbox.com (R17) <== NOOP 207.8.214.5 is sending mail from 
<listbox+trampoline+735+2903415+e2bbd31c(_at_)v2(_dot_)listbox(_dot_)com>; if 
forged, consider an SPF record (http://spf.pobox.com/) 
apex.listbox.com (R17) ==> 250 Ok 
apex.listbox.com (R17) <== MAIL FROM:<> 
apex.listbox.com (R17) ==> 250 Ok 
apex.listbox.com (R17) <== RCPT 
TO:<listbox+trampoline+735+2903415+e2bbd31c(_at_)v2(_dot_)listbox(_dot_)com> 
apex.listbox.com (R17) ==> 250 Ok 

If ever someone tried to launch a DOS attack on a site like
v2.listbox.com by causing tons of third parties to issue CBVs (which
admittedly then shouldn't, since v2.listbox.com has an SPF record),
then at least the victim can learn what IP address(es) the perpetrator
is using by inspecting the SMTP traffic for NOOPs.

David

-- 
This message was sent from a non-repliable address for a closed mailing list.
If you wish to reply directly to me, you can use the following address, which
expires on 03 Mar 2006:
    
<mazieres-gpzq4838b2pswxtqc82k5gxdfw(_at_)temporary-address(_dot_)scs(_dot_)stanford(_dot_)edu>

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com

<Prev in Thread] Current Thread [Next in Thread>