Re: A new SMTP "3821" [Re: FTC stuff...........]

----- Original Message -----
From: "Matthew Elvey" <[email protected]>
To: "Hector Santos" <[email protected]>
Sent: Sunday, December 05, 2004 6:03 PM
Subject: Re: A new SMTP "3821" [Re: FTC stuff...........]


> On 12/5/2004 1:48 PM, Hector Santos sent forth electrons to convey:
>
> >----- Original Message -----
> >From: "Matthew Elvey" <[email protected]>
> >To: "Hector Santos" <[email protected]>
> >Sent: Sunday, December 05, 2004 12:52 PM
> >Subject: Re: A new SMTP "3821" [Re: FTC stuff...........]
> >
> >The point is in order to accomplish this, the CSV (and others) state
machine
> >must be based on a delay design mechanism.
> >
> >Do I need to explain this?
> >
> >
> Yes. I don't know the term and
> http://www.google.com/search?q=%22delay+design+mechanism%22
> brings up no hits.

Ok, fair enough,  I will explain it (see below) but keep in mind, a little
more elbow grease in your googling. i.e, using words like "SMTP DELAY
VALIDATION", etc, would of produced some hits.

This is certainly not the first time this discussion or related concepts
were discussed at some level.

> The only relation of
> "delay" to CSV is that there's a delay when a domain with a good
> reputation goes bad and that info needs to be discovered and propagated.

No, no relationship to mixed validation ideas and issues.

I will try to give you an example.  I will do so with specific CVS examples,
but keep in mind the same or related issues applies to all the proposals.

Keep in mind we are a product developer and the implementation of any new
idea into the system goes thru a very thorough "Software Walkthrough" review
process with many issues to be considered.

In regards to SMTP, the following top design goals were sought:

- Maximum SMTP Compatibility,
- Maximum Spoof protection/Validation at the transaction level,
- Maximum Efficiency and Scalability.
- Minimal to no interference with 2822 mail interpretation.

The last one is based on our long history on online hosting product
experience (second to none) in dealing with US ECPA legal and related
issues.  In short, we don't concern concerns with the administrative or
end-user level mail interpretation issues.  Any new security ideas that will
stop the 'flow" of mail must be maintained at the transaction level for
product liability reasons.  PS: I don't wish to go into this with anyone.

Of course, it should go without saying that any new SMTP concepts should
deal with compatibility issues as well.  Like any other vendor, we don't
wish to "break" their operations.

However, this is very important in the area I feel is very important in
distinguishing problem we are trying to address.  In short, our design
philosophy from the git-go has been the Spoof Problem is one that is a based
on an "Anonymous Final Destination Transaction" (AFDT).

The reason is straight forward:

The world wide SMTP internet email network is predominately based on the
following fundamental principle:

- Trust is required for Relay or Routed transactions,
- No Trust is required for final destination transactions.

In other words, for relay or routed transactions, the client/server
transaction has already negotiated a "trust" relationship.  In practice,
this is traditional done using one or more of the following:

-  IP Relay Tables
-  ESMTP  AUTH
-  POP3 BEFORE SMTP

However, for a AFDT the "network" has worked because the above trust
relationship is not required.  Yet, this is where the exploitation of SMTP
begins and it is the essence of the Spoof Problem that exist today.

So for lack of a better term, "Anonymous Final Destination Transactions' is
where SMTP lacks strength and hence needs new ideas to help protect against
the abuse of the system.

If you don't agree, you might as well stop here.  But if you want to
understand what is meant by delay or mixed policies, then continue reading.

Now, lets review the SMTP state machine:

o connection state
o HELO/EHLO state
o MAIL FROM state
o RCPT TO state:
o DATA state:

Since we are attempting to solve this problem in non-2822 terms, only in
2821 terms, the data points for a transaction are:

CIP - Client IP address (at the socket accept level)
CDN - Client Domain Name (issued at HELO/EHLO)
RP  - Sender Return Path (MAIL FROM)
FP  - Forwarding Path (RCPT TO)

Using the following functional model to depict old (current) vs. new end
point validation concepts:

    result = EPV_OLD(cip, cpn, rp, fp)
    result = EPV_NEW(cip, cpn, rp, fp)

We can now begin to show how all the data points are related and/or mix
policies analysis is required to be considered.

Given what was stated above about AFDT,  no "new SMTP validation logic" is
required until it is known whether the transaction is a route or a final
destination.

Therefore,  one SMTP implementation would to delay all validations until FP
is provided at RCPT TO:

    if FP = Route then
        Result = EPV_OLD(cip, cpn, rp,fp)
    else
        Result = EPV_NEW(cip, cpn, rp,fp)

This says that if the forwarding path is for a route, then we only need to
use traditional, backward compatible SMTP authentication/validation trust
negotiation ideas that already exist and are standards in the market place.

It also says that if FP is not a route but for a final destination, then
this is where we need to apply new validation ideas that are not currently a
standard.

What does this all mean?

Well, from a design standpoint, you have two options:

- An open-ended check for each data point as they are provided, or
- A more efficient check based on one or more of all the possible data
points.

Lets use CSV examples:

Example 1 is the IDEAL "Good Transaction.  All data points are valid.

connection ip:  64.234.45.8
HELO mail.elvey.com
MAIL FROM:  [email protected]
RCPT TO: [email protected]

In this case,  you are connecting to our MX server at winserver.com, from
your own valid IP machine, issuing a valid client domain name and a
non-spoofed valid return address.  Its all good.

Example 2 is the bad transaction where you trying not authorized to route
via our server:

connection ip:  64.234.45.8
HELO mail.elvey.com
MAIL FROM:  [email protected]
RCPT TO: [email protected]

A few questions now come to mind:

a) At which point do we apply CSV?
b) Can we use CSV to authenticate the route?

If you had follow this so far,  CSV is only needed at  example #1 for a
AFDT.

In example #2,  you need to follow standard SMTP authentication on our
system in order to route.  You have to have a prior relationship, either as
a MUA user or another trusted router.

So unless you apply a delay validation technique, you are forced to use a
open-ended check prior to the FP is known.   This is a very inefficient mode
of operations which has been proven to be the case in practice that require
DNS overhead just like CSV does.

Lets look at Mixed Policies now.

A new example #1.1 is similar to example #1 as a final destination
transaction but with a different sender, not you.  I could of used your
address, but I wanted to highlight the difference.

connection ip:  64.234.45.8
HELO mail.elvey.com
MAIL FROM:  [email protected]
RCPT TO: [email protected]

It is an anonymous final destination and a transaction where additional
validation is required.  We are using CSV here and lets assume you are a
member of Doug's new CSV/DNA authentication database.

Lets also assume that the efficient delay validation is used so that CSV is
applied after RCPT TO is provided.  The validation is delayed.  No overhead
in this system.

According to CSV specs, since you are authenticated via CSV/DNA based on the
CDN (HELO client domain) and CIP (client IP address), then we should "trust"
this transaction,  however, the CSV does state that additional validation
may apply depending on the implementation.

Since we have very suspicious sysops and since CSV does not address RP
(return path) validation,  a system may which to add additional logic such
as SPF1 or SENDER ID  to validate the return path domain.  Keep in mind that
SPF1/SENDER ID or LMAP in general  validates just the domain part of the
return path. Not the complete address.

In any case, for the sake of the example, a SPF1/SENDER ID check results as
a FAIL.

You know have a mix policy:

The questions are:

What does it mean?
What validation prevails?
What are the validations weights, if any?
Can the mix policy be use to trump one validation over the other?

Lets look at some of these questions:

Does this mean the CVS authenticated ELVEY.COM  has a spammer user on this
system?

Does this mean the CVS authenticated ELVEY.COM  has a  DNA attribute that
says:

    "[X] Reject if the Sender Path is invalid"

Could it mean that CSV says a validated machine trump any other validation?

Lets go a step further with another mix policy situation:

Lets assume the sysop has implement a CBV (Call back Verifier) instead of
SPF.  The CBV is designed to perform a callback to the return path MX domain
to validate the return address.

Lets assume the CBV returns

        "550 Unknown user: [email protected]"

What does this say about the trust of an CVS authenticated ELVEY.COM system?

Should ELVEY.COM get blacklisted? or should a report be sent?

So on, and so on.

The point in all this is that NONE of the proposals have taken a very
thorough "Software Walkthrough" and look at all the possibilities.

Delay validation is a requirement in my book.  Not only do you achieve
higher compatibility,  you can save a very significant 35-60% in validation
overhead.

No one proposal can be used unless it covers all bases.  Thus unless someone
comes up with a merger of all the proposals, the advanced SMTP system today
will need a suite and they will have to deal with the mix policy issues at
some level.

I hope this is sufficient Matthew.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office