I don't know much about BATV, nor if I am not understanding this thread,
but.....
As far as CBV is concern, as long as it follows standard SMTP operations,
you shouldn't have a problem.
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)
Some specific implementation details:
1) We delay the CBV until RCPT TO is known following the recommendation
in RFC 2821 section 3.3:
| 3.3 Mail Transactions
|
| .....
|
| ............. Despite the apparent
| scope of this requirement, there are circumstances in which the
| acceptability of the reverse-path may not be determined until one or
| more forward-paths (in RCPT commands) can be examined. In those
| cases, the server MAY reasonably accept the reverse-path (with a 250
| reply) and then report problems after the forward-paths are received
| and examined. Normally, failures produce 550 or 553 replies.
We do this simply because 40-60% of RCPT TO: are invalid so there is need
for a CBV.
2) During a CBV, we check two addresses:
- the original session return path
- a random address to check for 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.
Overall, our goal with CBV is to validate the return path with no intent to
determine if is a zombie or not. Just make sure its returnable as if a
bounce session was going to take place. Per RFC specification, this is a
MUST requirement to maintain proper mail flow - the BOUNCE address is
expected to be valid. If it is not, then the transaction is rejected.
I'm not sure how this relates to BATV or this thread, but if its not
following standard SMTP concepts and expectations, then no one should be
surprise that they run into implementation problems.
---
Hector
----- Original Message -----
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, February 17, 2006 1:58 PM
Subject: Re: [spf-discuss] Re: Fw: SRS vs BATV
On Fri, 17 Feb 2006, Frank Ellermann wrote:
many MTAs do CBV with a MAIL FROM of other than <>.
Let them try this with one of their own kind, and they'll CBV
each other until some timeout stops this seriously bad idea.
Unfortunately, my clients do want to receive mail from such
MTAs. Sigh.
Tough. OTOH there's no dead loop if at least one side gets it
right. What do they do if they meet one of their own kind -
play ping-pong until all ports are busy ?
This happens many times every day. It loops 20 or 30 times between
their braindead systems until one of the systems notices "too many hops".
Then they send the whole mess, complete with never-ending received
headers,
to postmaster(_at_)oneofmydomains(_dot_)com, because
spammer(_at_)oneofmydomains(_dot_)com
was listed as the alleged sender. I've trained my bayesian filter
to discard all mail to postmaster with lots of Received headers.
If you're interested in some of the guilty parties, I could dig
through the quarantine when I get a chance.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703
591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
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
-------
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