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?

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 
mechanism.

Note that for sites with large outbound-SMTP server farms, it's *quite* 
plausible
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.. ;)

pgpzq2aLIcrNB.pgp
Description: PGP signature