At 12:41 -0400 on 06/28/2005, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote about Re:
Bounce/System Notification Address Verification:
On Tue, 28 Jun 2005 15:55:27 BST, Tony Finch said:
On Tue, 28 Jun 2005 Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
>
> Please note that using the near-universally reviled Verizon method as
> anything other than an example of how *not* to do it:
>
> 19:36:18 C: MAIL FROM:<antispam579542(_at_)west(_dot_)verizon(_dot_)net>
>
> Now explain to me why I shouldn't do a CBV on this?
And if you do, what do you expect to happen? If Verizon calls back in
response to your callback (i.e. they're doing CBV for email to
> antispam579542(_at_)west(_dot_)verizon(_dot_)net) then they are asking for a
disastrous
callback loop. However this will only occur if your system has the same
bug.
The first rule of any protocol is that it has to interoperate with itself.
The fact that this design *is* prone to disastrous loops when it encounters
other CBV systems with similar design flaws shows that the concept is flawed.
While I agree with you, I'd like to point out that the only way there
would be callback loop is if the originator of the CBV's machine
does CBV when its address is verified. IOW, when
antispam579542(_at_)west(_dot_)verizon(_dot_)net is checked it should NOT CBV but just
return a "Its a Good Address" indication. When ISP1 sends a message
to ISP2 (which CBVs ISP1), the CBV that ISP1 responds with to IPS2's
CBV attempt is ISP2's responsibility to handle (ie: To not do a CVB
on) since ISP2 KNOWS that it probably is an CBV triggered by its CBV.
A good CVB design should not need to "special case" CBV attempts (by
having a list of the hosts/address-templates of ISPs that CBV and
thus should not be CBV'ed back) but should just rely on the
originator to handle the CBV its own CBV triggered.