ietf-smtp
[Top] [All Lists]

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

2004-01-16 11:01:44


----- Original Message ----- 
From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "IETF-SMTP" <ietf-smtp(_at_)imc(_dot_)org>
Sent: Friday, January 16, 2004 12:37 PM
Subject: Re: CBV systems - was Re: SMTP Extensions - proper peply code for
disabled commands

On Fri, 16 Jan 2004 11:28:44 EST, Hector Santos
<winserver(_dot_)support(_at_)winserver(_dot_)com>  said:

So we stick an 'updates 2821' on it.  Isn't like we haven't done THAT with
a
number of protocols in the past.

As long it has it makes it possible for enforce validation,  Ok, I guess
this ends the discussion and any talk to change 2821 in this area.

(Incidentally, exactly these sort of bogosities are why the spec didn't
allow rejection
based on EHLO in the first place.)

Oy vey, I appreciate the historically perceptive. :-)

But if your "car" is now broken,  you lost the keys, you are out of gas,
money and friends.  You now need to find another way to get where you want
to go!

Maybe, what we need to do is change the order of the state machine to define
your ultimate intention?

RCPT TO:

          refused recipient, don't bother with the rest, optimizes, improved
SMTP engine with eliminating
          of validation overhead.

HELO:

          allows for quick sender/machine validation

MAIL FROM:

         allows for return path validation.

DATA

The point is,  you are debating a time warped or legacy methodology that
simply doesn't apply any more (for the most part) and at the same time seem
to be advocating (or instilling the idea) a need or requirement for change.
When people have problem, there are other ways for contact.   The beauty of
course, is that the people we are trying to protect against, won't bother
you either way.

You can't have it both ways!



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