[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-28 22:14:58

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 
 callback loop. However this will only occur if your system has the same

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.

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