ietf-asrg
[Top] [All Lists]

Re: [Asrg] 0. General - Inquiry about CallerID Verification

2003-11-30 14:33:21

----- Original Message ----- > > Hmmmmmmmm,

I don't see why you would want to to confuse the issue with RSS, HTTP,
IRC,
etc?


There are security issues present in other protocols which have been
dealt with in different ways. We can use some of those methods in SMTP.

Yeah, ok.  and what does this relate with that final conclusion that you
need "access security."  Are you going to exclusive lock into one method?
Are you going to now change the specs to fit a new model?   I gave you a new
proposal that changes the specs, if that is what you want.

I don't think you do.

You want to get this ball rolling using Mr. Crocker incremental approach?
He gave you an outline.  Lets use it.

Phase 1)  Functional Specifications

GOAL:

        Get the specs rewritten to clarify the new possible strict interface
points to give
        developers better insight and guidelines for new ideas based on the
SMTP or
        ESMTP protocol.

You might want to offer new interface points.   Among the current interface
points:

- connect
- helo/ehlo
- mail from:
- rcpt to:
- data
- quit

these can summarized as:

- client access/sender authentication
- recipient validation
- mail content validation ???

Mail content validation can be considered as an external functionality.
Again, in my engineering experience, no mail transport or gateway should
have no business in the "interpretation of data."   This puts ISP and
Software vendors at legal risk.   The only thing that can possible be done
here from a transport standpoint is a CRC32 data validation.   For example,
a sender can issue CRC32 that offers the server the ability to check data
integrity.

Recipient validation is a server implementation.   However,  final delivery
must be guaranteed or acknowledge in one form or another.  I believe there
is NOTHING wrong with dynamic validation especially when coupled with
trusted client access.    Having no validation delays notification. Which is
ok, but it needs to be acknowledge one way or another.

Client access and sender authentication is where it gets tricky and is the
heart of the problem.

All you can do now is get this acknowledge into the specs and make it
possible for restrictions to occur and/or they MIGHT occur depending on
extended SMTP server implementations.

At this point, you put a RFP,  "Request For Proposals"  for solutions using
a new, cleaner functional specification with new guidelines.

That's you first step.   This should be easy for you.  It is an
administrative task mostly but you do need some level of system design
experience to have you outline it without clouding external unrelated
issues.


Phase 2) Review of RFPs for SMTP Client/Access and Authentication Proposals

GOAL:

        Review, Discuss new RFP that work with the new SMTP/ESMTP functional
specifications.

In this phase, I see you dealing with two types of basic proposals:

a) designs to fit the legacy SMTP protocol,
b) designs to fit the new Extended SMTP protocol outlined in Phase 1.

This is where DEVELOPERS need help because it requires a consensus that is
independent of the SMTP design itself:

                 CLIENT --> SMTP ---> VALIDATE (HOW?)

Using these proposals, we now can revisit phase 1 to see if it needs
"tweaking" to better fit.

If you want to follow Mr. Crocker incremental design concept, it might help
if you produce a table of the SMTP state machine and for each STATE,
indicate the current proposals that touch base with each state.

for example:

             connect
                        proposals: RBL, RDNS, RMX?
             HELO
                        proposals: ???
             MAIL FROM:
                        proposals: C/R, SAP, MAP, etc
             RCPT TO:
                        proposals: C/R, ????
             DATA:
                        proposals: ???
             QUIT:
                        proposals: ???
etc, etc.

This will help ALL of us get a better insight on all this.

---
Hector Santos
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg