From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
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?
Then your implementation would be incorrect. You should not use a NULL
because the 2821 behavior is such that it is a bounceable address.
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.
May I suggest a NULL?
Why can't it be possible to cache the attempts?
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)...
Again, cache your attempts.
When this happens in a bad world, they will get black listed and when it
happens in the good world, you will get white list.
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 -
So why it would even care? Why not just handle it just like any other
connection? It will have too anyway.
If the CBV is blasting a system with too many calls, I can see where a
remote may assume a havest attack. But again, if your system needs to call
back a remote host on a regular basis, then you white list to avoid the
issue.
If you are talking about some identification, then you are talking about
something new which will probably be exploited or not used by the target
malicious senders. CBV is based on legacy compliancy. Nothing new is
required. That is why it works.
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.. ;)
You are going to have to explain that line of thought..
Spammers starts a session:
MAIL FROM: <spammer>
RCPT TO: <local user>
CBV is started before RCPT TO response is issued: At the spammer host:
MAIL FROM: <>
RCPT TO: <spammer>
What happens now? Spammer does a call back to where?
It seems that you stuck on that idea that the CBV is the only method
implemented to validate a sender.
You need to elimininate other considerations first before using it. Such as
RBL, SPF, Local Domain spoofing, etc.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com