At 07:53 -0400 on 06/29/2005, Bruce Lilly wrote about Re:
Bounce/System Notification Address Verification:
On Wed June 29 2005 01:40, Robert A. Rosenberg wrote:
There is only (as I've noted in a prior message) a flaw if when
[a] CBV probes an ISP and that ISP CBVs back in response to the
probe, [the first sysrem] instead of accepting the CBV probe and
responding with
a "Good Address" reply turns around and tries to CBV the other
Server. It is the job of [...] CBV users [...] to recognize
the addresses used with their CBV probes and not respond with a CBV
probe when the address is used by another CBV system. You handle CBV
probles triggered by your own in-flight CBV probes do not require
your CBV code to recognize other user's CBV probe patterns (ie: you
should just CBV respond to them).
Then it is the responsibility of the (nonexistent?) specification
authors to completely specify such behavior, and as this is clearly
an interoperability issue which if ignored can result in damage to
the mail system is needs to be specified with use of BCP 14 MUST or
MUST NOT.
While I agree that when an RFC is written on how CBV should operate,
this is not the intent of my comment. I was responding to the
statement that CBV can introduce CBV loops if a CBV probe triggers a
return CBV probe to validate the claimed address of the prober before
it will return a Valid-Address/Invalid-Address response to the
original probe.
My intent was to show that this ping-pong/loop behavior (if it
occurs) is due to a broken CBV design. The checks that are done in
response to a RCPT-TO (that involve doing a CBV before acknowledging
the command) should first involve a sanity check on the supplied
RCPT-TO to insure it is not the MAIL-FROM used for sending CBV
Probes. Since it is easy to spot YOUR probe addresses but hard to
spot every other CBV user's addresses, the check needs to be done
when someone you are probing tries to probe you back before they
respond to your original probe.