At 13:24 -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 18:04:02 BST, Tony Finch said:
On Tue, 28 Jun 2005 Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
>
> 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.
You haven't demonstrated that Verizon's implementation is flawed
in this way.
OK.. I spell it out in excruciating detail:
Verizon presents me with MAIL
FROM:<antispam579542(_at_)west(_dot_)verizon(_dot_)net>
I do a CBV on MAIL FROM, same as Verizon, and send them a connection
that starts
MAIL FROM:<notaspammer993435(_at_)example(_dot_)com> - they see that mail from,
and do what?
Not CBV back I'd hope but just reply that
antispam579542(_at_)west(_dot_)verizon(_dot_)net is valid and see what happens next
(which SHOULD be a QUIT in this reverse CBV case).
[snip]
Also, absent a new, as-yet-unRFC'ed SMTP extension, the remote end can't just
assume that something is a CBV and ignore it - to do so would allow
a spammer to send you a MAIL FROM/RCPT TO on a first connection,
then once the callback shows up, use *that* information to create
what looks like a "callback to a callback", but proceed to the DATA
step. Whoops.. ;)
If the response to the "Its Valid" reply is anything other then a
QUIT (ie: If the sender tries to go into Data State) then just drop
the connection since the ONLY valid reply to the CBV check is a QUIT.