[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-28 07:59:55

----- Original Message -----
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>

Please note that using the near-universally reviled Verizon
method as anything other than an example of how *not* to do it:

Noted, but it is what it is.  In my personal assessment,  verizon,
santronics and many others who have implemented CBV just because we thought
it was a great idea, but because YOU (speaking of the IETF community in
general, are foot dragging or many times, not even then to come up with a
solution to even REDUCE the "email problem."   Commercial outfits need to
service customers and address the issue.  We are not going to wait.

And again, from my perspective, it is the PROOF of CONCEPT that is more
important.  The SMTP BASED CBV may not be the more efficient solution, but
it certainly the only method you have today that is backward compatible.

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?

You are quite correct.  I don't particular like this Verizon method to test
the concept of whether a NULL is failing a RCPT check.    It is different
from the rest.

As I mentioned, I believe this was because one of the big ISP (aka big SPAM
source) were behaving as such. I can't recall who it was specifically and
whether that practice has change. I am leaning that it was changed as the
started to see more CBV transactions.

But I agree 100% with you.  Yet,  it is not enough to throw out the baby
with the bath water.

When directed at us, you probably noticed the delay in sender verification
until the RCPT TO is determined.  So this isn't an issue.

At worst, if we did do a MAIL FROM call back,  not delay, there would be a
two level CBV.  Not good, I prefer not to see this, but it is not a
perpetual loop-back.

As a said a quite a few times and outlined in my Mail Hosting
Recommendations;  Any sender verification concept with potential overhead
issues such be delayed until it is deemed absolutely necessary.  In this
case, follow the excellent recommendation John Klensin outlined in RFC 2821.
See RFC 2821 Section 3.3:

| 3.3 Mail Transactions
|    .....
|   .............  Despite the apparent
|   scope of this requirement, there are circumstances in which the
|   acceptability of the reverse-path may not be determined until one or
|   more forward-paths (in RCPT commands) can be examined.  In those
|   cases, the server MAY reasonably accept the reverse-path (with a 250
|   reply) and then report problems after the forward-paths are received
|   and examined.  Normally, failures produce 550 or 553 replies.

Hector Santos, Santronics Software, Inc.

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