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

----- Original Message -----
From: "David Woodhouse" <[email protected]>
To: "Alan DeKok" <[email protected]>
Cc: "MXCOMP" <[email protected]>
Sent: Friday, November 26, 2004 3:11 AM
Subject: Re: A new SMTP "3821" [Re: FTC stuff...........]

> It does sound like I misinterpreted you in the same way, for which I
> apologise. I'm not arguing with your actual position. To fix spoofing of
> addresses is just a band-aid, as you said. But it's all that's on offer
> right now. I'm saying we can do _that_ without fundamental changes.

And I'm saying you can not.

To suggest this, it is to presume that the solution is:

    - end point to endpoint, or
    - post smtp related.

Now, you might be thinking of a software (in fact, I'm sure you are) that
offer a "plug and play" capability, a mfilter or a ACL - but means change.

But it is more technically deeper than this and since you fail to recognize
all this,  it means
you are exhibiting a "emotional response," not I, to what has been pointed
out many times.

You (speaking in general) need to look at the mixed policy issues to
understand this better.  You need to look at each state point in the state
machine to see how it "fits" in the scheme being proposed or vice-versa.
What we have here are kludged solutions that may or may not have a "chicken
and egg" problem.

Believe it or not, good systems do not violate SMTP protocols.  It is only
the abusers that are taking advantage of the system.

The "fundamental" reevaluation of SMTP is not to "alter it" so that it
breaks the infrastructure, but rather to strenghthen what is already there.
For vendors in the market place, including our own, it is not in our best
interest to break customers operations.  Yet, we seek to secured it better.

In addition, as a vendor, I am very interested in supporting the mandates
imposed by our Federal Government laws such as CANSPAM - that means complete
email address validation and Topic Identification concepts.

Lets look at more specifics.  We have essentially one or more of the
following:

1) EHLO/HELO validation
2) MAIL FROM validation
3) RCPT TO validation
4) DATA validation, if any
5) Mixed Validation
6) No Validation at 2821
7) Post SMTP validation
8) Bounce Requirements


SPF concentrates on #2, and it lost on handling #1 and proper handling of
#5.  It ignores #3.

CSV concentrates on #1, gets lost on SMTP AUTH issues,  proper handling of
#5 and also ignores #3.

SENDER ID like SPF, also gets lost on #4.

IIM, YDK concentrates on #4.

Keep in mind that the above presumes "changes" to the SMTP system so that
the dynamic validation can be included at the transaction level.

Some of the schemes "may" also work in post-smtp mode, #7, which from a
practical standpoint offers a greater compatibility with the current
installed base.   However, this has proven to help the distribution of
SORBIG generation based e-viruses with #8 so it goes without saying today's
AVS ready system promotes dynamic RCPT TO validation #3.

I can go on and on with all the other schemes.  What they all have in common
are conflicts that are relaed to the ambitiguous, "which school of thought"
understanding of the SMTP protocol,  how SMTP is implemented in various
modes of operation, and many cases, a complete ignorance for efficiency.

So what I have been proposing since day 1 is let us  revisit the protocol,
not with a desire to fundamental change it  but with a GOAL to better grasp
the state machine and how it is being
exploited at each state state and also as a mixed policy.

The goals are:

- To remove the ambiguity on the functional specification.

- Introduce the functional specification for state machine validation.

- Introduce, if any, new ESMTP protocols to help augment the new SMTP
security requirements.

Note I did not say "technical specification."  There is a major difference
in functional vs technical specs.

We need to remove the "comments" in the specs that suggest "lets not break
the system because of one abuser."  In other words, we need to change the
"old spirit"  of a loosely guarded network of nodes to one that is more
mature for today.

Now, we can ask, why do we want to do this?

Well, you want to do this now only to better understand what are the key
issues and how to improve it, but to also allow for the R&D and future
developers to have a better summary document to design SMTP software.   Of
course, you can also say "Why write a new SMTP server when you have open
source to work with?"       Well,  many times, people need to write
proprietary systems.

But this is would be going off on a tangent.   The key issue is
understanding the problem in order to solve the problem.  Band-aids, while,
they can work,  what is quite evidence, they lack analysis of how it will
actually work within the "current infrasture."

I leave you with one example:

IIM/YDK,  what if a message is properly signed with a proper address by the
outbound system, does this mean the client domain name can still be invalid?
What if it is not valid?

While you may be looking for a partial solution, I on the other hand am
looking for a real solution. And yes, I have a full understanding that may
not be practical, but at the very least, it is in my nature as an engineer
to gain a full understanding of the problem first to better analyze the
theorical as well as the practical solution.

Sincerely,

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