[Top] [All Lists]

Re: CBV systems - was Re: SMTP Extensions - proper peply code for disabled commands

2004-01-15 19:34:00

----- Original Message ----- 
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>; "IETF-SMTP" 
Sent: Thursday, January 15, 2004 8:26 PM
Subject: Re: CBV systems - was Re: SMTP Extensions - proper peply code for
disabled commands

I could reply to your reply in detail but that would only distract from
the important points in this debate.

Thanks, however.....

the points are these:

if widely adopted CBV will impair the reliability of the mail system by
causing delivery failures for legitimate messages in cases where
delivery would otherwise have been successful (i.e. if the return-path
field was invalid or not usable due to a configuration error or
temporary failure)

[Side note: I think the word legitimate does not play a role here as this
can happen in general.  The process has no information on whether the
transaction is legitimate, if it did, then we this CBV does not apply]

I fail to see where an invalid field would not be a problem in the first
place.  Ok,  so what if a DSN was going to be sent?   A normal SMTP queuing
will occur.


Real Bad System:    Non-CBV system will have a wasteful long term retry

In the CBV, based on the implementation,   I have it so its sysop

    ConnectFailure  Reject |  Accept  [MaximiumAllowed [5]]

Rejection codes are definable as well.

So I don't see this is as a reason to reject the concept.  It is technically
addressable.  Fortunately, like I said, most systems are compliant.  So
those that are problematic are more than likely to be those systems were are
trying to protect against.  And those with false negatives are sent 45x.
The legit system will try again.   I have not seen one report that indicated
this is a problem, and unexpectively so, because spammers are spoofing other

since CBV is easily circumvented by spammers, in the long term CBV does
no good - it only introduces overhead.

Well,  IMO, this ideology applies to any solution, including those that may
be or not capable of being circumvented.  In other words, if a solution
works then it inevitably becomes overhead and redundancy.

So what's the point?

I think the important points in the debate is the exploitation of the
functional specification, not CBV.  As long as the specs remain relaxed on
client/sender validation, we are never going to solve anything and those
that do provide solutions will be accused of having "broken software."

Thanks for your comments Keith.

Hector Santos, Santronics Software, Inc.

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