[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-28 10:24:42
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 

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 

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?

Absent some additional RFC-mandated rules not in evidence (regarding what
the MAIL FROM has to look like for a CBV, etc), this *WILL* create a loop if
it encounters another copy of itself... thus the need for a loop-breaking 

Note that for sites with large outbound-SMTP server farms, it's *quite* 
that even a "is it another from the same IP" check would fail to stop it before
30 or 40 iterations - and by that time, the *first* one would have timed out,
permitting the loop to continue (note that *failing* to time these out causes a
potential DOS)...

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.. ;)

Attachment: pgpzq2aLIcrNB.pgp
Description: PGP signature

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