ietf-smtp
[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-30 14:45:06

Follow up:
----- Original Message -----
From: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>

From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
For CBV, it means that acceptance by such a system's
MX host doesn't mean diddly.

It implies one of four possibilities.

- GOOD: ther you did a RCPT TO validation
- BAD/GOOD: You are performing a delay validation (as you describe)
- BAD: You are an open relay
- BAD: You are a zombie (open relay)

There are another possibility that this thread picked up on specifically in
regards to the CBV concept with low timeout values

   - GOOD/BAD: Slow/Throttle Responsive System (Timeouts)

In regards to the CBV concept, this is probably only the "weakest spot"

Even Exim uses a lower timeout of 30 seconds.

As I mentioned a few times,  if this was significant issue, not 50%, 40%,
not even 1% but a 0.01% occurrence, I would seriously reconsider the CBV,
but not before exploring a possible solution.

I realize I am not Sendmail, just a small company. But enough spread of
customers, enough field testing, and production operations to determine as
an engineer what is practical or not, what is working or not, what is
problematic for customer support, etc.   For any customer, small or large,
getting even 1 false positives and complaints a day would be not only be
overwhelming in customer support cost, but completely unacceptable product
engineering. It would be pulled.

Finally, also consider that part of the solution (not just with CBV) is
everyone chipping in and doing their part too.  If there is one thing for
sure,  not just for us, but for everyone,  it has gotten people to clean up,
fix, correct and improve their system.   And that includes me too!!!  I have
found things I had to fix up, such as this MAIL FROM:SP<address> outbound
mail bug that crept in several revisions ago.   Never got any reports until
now with strict-rfc822 systems which is rare in regards to this space issue,
but nonetheless, a bug is a bug. It was fixed.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com