----- 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>
Sent: Friday, January 16, 2004 9:27 AM
Subject: Re: CBV systems - was Re: SMTP Extensions - proper peply code for
disabled commands
Section 3.3 makes it possible to perform return path validation;
yes, it's possible. that doesn't mean your way of determining whether
the reverse-path is acceptable is a good idea.
Keith, we written directly to each other on this.
I feel it is important to focus on this aspect of the topic publically.
It also doesn't mean it (CBV) is a bad idea either.
Nonetheless, as I indicated a few times, I am not bent on any idea. I am
very conservative too. Our main goal was to provide a black box validation
system into each state of our SMTP engine. That has been accomplished and
we used a CBV along with other sender-machine validation concepts to provide
an SMTP level, non-mail content related, access control system.
Rhetorically, do you have a better way today that is consistent with the
current SMTP protocol? Immediately deployable?
If so, then lets talk about it.
If not, forget about CBV, lets talk about how it can be done. That is
why I am here. I really don't want to waste anyone's time here or my own.
Is this a group of industry developers? If this is not the place, does
anyone have a place or where I can find a group of industry developers, not
policy makers or administrators, to bang our heads together and come up
with a best backward compatible solution/proposal? If this has already
been done or if you have your own view on this, then please, enlighten me.
Forgive me for using your original message to returning the carrot on this
topic. It was pretty obvious your questions were more rhetorical and your
mindset and conclusion was foretold. I understand 100% what are all the
issues involved with CBV. I haven't heard anything that I was not aware
about. However, if it was not clear, my main goal was NOT to prove that
CBV is the ultimate solution, it isn't, but rather to show how it was used
as a proof of concept to illustrate the MAIN issues with the functional
specifications of SMTP protocol.
The CBV is really a multi-point testing system. One excellent discussion
that was brought up elsewhere is how it compares to a DNS Lookup proposals.
The CBV validates the email domain, the domain MX, the domain IPs, the IP
connection and the SMTP session.
The DNS lookup methods validates only the sender machine.
The questions are:
What is more important to provide access control? Sender machine, Return
path or both?
In my research, you need to consider both. Putting aside the possible
strength of each one, the problem for developers will be how any validation
conflicts with the functional specification.
For example, if the ASRG efforts finally put out the official
recommendations (which to me, looks like its DNS lookup based, hence sender
machine), then this along says that it will be conflictive with the current
HELO/EHLO functional specifications. For example, the following RFC 2821
will now be inconsistent with the IRTF drafts:
4.1.4 Order of Commands
...
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
A possible rephrase would be:
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client or possible
using
one or more SENDER MACHINE validation techniques [See XXXX].
A server MAY refuse to accept a message if the verification fails,
however, this
non-acceptance of mail failure SHOULD be based on a SENDER MACHINE
validation technique. The information about any verification failure
SHOULD
recorded for logging and tracing.
Do you see what I mean? The same is true across the board for other
validation concepts in the functional specification, such as the return
path. I don't think the sender-machine validation is sufficient in
controlling anonymous access abuse. The return path validation is the next
possible "current SMTP protocol" technique. We will need the same
rephrasing of return path validation in the specs, because some day Keith,
if its not CBV, there will be another more optimized method.
Otherwise, what will happen is that there will be deployment problems and
there will certainly be many arguments and debates who's software is
"broken."
I hope I have made myself clearer here.
Thanks
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com