Subject: Comments and Concern about MARID-CORE: A Proposal

From: "Hector Santos" <[email-masked]>
Date: Wed, 21 Jul 2004 03:49:29 -0400

I had a CPU burnout problem (silicon variety) so this delayed a proposal
about revisiting the MARID-CORE, not to change the scope but to remove most,
if not all, the "real" concerns about it.

I put together 5-6 drafts that illustrate how MARID can still be used yet
resolve for the most part two concerns:

- IP concerns
- Better "Mouse Traps"

I put a lot of time into this and it is NOT my goal to buck the system here.
The status-quo of MARID is a major problem for many and in my belief not
suitable to become a "world-wide standard."   I think a simple
reorganization will address all the concerns on both sides and still have a
"MARID" offering for the world.

Here is my summary of all the drafts that begin a core abstract framework
called "Data Transaction End Point Validation Framework."   They keyword
here is "abstract."

I would like to see comments on this before I proceed with the draft
complete which basically is putting them into a IETF draft format.

Data Transaction End Point Validation Framework
By Hector Santos
Santronics Software, Inc.
July 16, 2004

Summary:

The EPV-CORE abstract functional model:

    EPV = EPV-METHOD (EPV-DATA)

Where

    EPV is the end point validation result of the EPV-METHOD function
    generator with EPV-DATA environment variables in the process domain.

The End Points in the EPV-CORE framework are:

   - Client connecting to server,
   - Sender of transaction
   - Receiver of the transaction

The EPV-CORE functional model for SMTP:

    EPV = EPV-METHOD (EPV-SMTP-DATA)

Where

    EPV-SMTP-DATA is the set of SMTP process variables:

       CIP    Client IP Address
       CDN    Client Domain Name, HELO/EHLO (RFC2821)
       AUA    Authentication User Access, AUTH (RFC2821)
       TRP    Transaction Return Address, MAIL FROM (RFC2821)
       TFP    Transaction Forward Address, RCPT TO (RFC2821)
       TPL    Transaction Payload, DATA (RFC 2822)
       DNS    Domain Name Server Database
       UDB    Server-side User Database (i.e., LDAP)
       PUA    Persistent User Address (from UDB)

Current EPV-METHOD implementations:

    EPV = EPVM-RBL (CIP, DNS)
    EPV = EPVM-DMP (CIP, TRP, CDN, DNS)
    EPV = EPVM-SPF (CIP, TRP, CDN, DNS)
    EPV = EPVM-CSV (CIP, CDN, DNS)
    EPV = EPVM-SENDERID (CIP, AUA,  TPL, DNS)
    EPV = EPVM-SUBMITTER (CIP, AUA, PRA, DNS)
    EPV = EPVM-MARID (CIP, AUA, TRP, PRA, TPL, DNS)
    EPV = EPVM-LUV (TFP, UDB)
    EPV = EPVM-CBV (TRP, DNS)

The EPVM-SUBMITTER method requires the introduction on a new ENV-DATA
variable called
PRA using a ESMTP MAIL  FROM modifier "SUBMITTER="

The EPVM-SENDERID method requires the usage of TPL when the PRA is not
available.

The EPVM-MARID method combines SPF, SENDERID and SUBMITTER.

In other words the MARID-CORE can be reorganized in such a way to be based
on totally on prior art and public domain technology that exist TODAY.

Yet, the EPV-CORE framework does not take away individual IP claims isolated
to the METHOD in place - not the framework.  The IP claim can not use the
EPV-CORE SMTP basic model as a IP protected enscapulated element to the IP
claim.

This allows for "better mouse traps"  EPV-METHOD implementations to be
invented.

MARID-CORE should be an Framework that provides technology to propers as it
comes along.  Not locked into one or more specific technology that will
limit the future options of better EPV-METHOD solutions.  This is the major
concern I have with the current MARID.  It was something that made sense and
worked to a very high degree, that would be wonderful.  But it isn't
reliably technologically and with all the required cost requirements for
implementation and its  IP related possible issues, it makes MARID extremely
hard to swallow and adopt.

It doesn't have to be this way.  We can have "our cake and eat it too."

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 21 Jul 2004 09:33:13 -0400

To illustration how current framework, here is how the current MARID-CORE
framework can be viewed and based on the EPV-CORE-MARID framework to resolve
many of our concerns.

I emphasise the fact that I am not a "Chair"  I am just trying to help. One
extremely important point: What I do best is "solve problems."   If any of
this is taken seriously and it is a approach to further pursue, I would
prefer for someone more suitable with an IETF working background to take
over this work.  If no one else is available, I will accept the challenge.

EPV-CORE-MARID - A new open standard MARID core generalized framework based
on prior art.

o Summary:

The current MARID-CORE should allow for a better mouse trap EPV methods. and
implementations.  To isolate it for a specific invention only introduces a
wide range of issues.

While a EPV-CORE MARID framework based on SUBMITTER and SENDERID may became
the new pseudo and accepted standard, that shouldn't mean that new possible
ideas can't replace what should basically be a "plus and play" EPV-CORE
framework.  The way MARID-CORE is designed now, it stops such process.  Who
knows?  Maybe tomorrow Dave Crocker's CSV proposals will replaced methods
used by SMTP software?

So EPV-CORE should be the core model for MARID that outlines HOOKS into the
system.  It should not isolate itself to specific methods and it should
consider all End Points, including RCPT TO:

If EPV-CORE-MARID framework is adoptted, there will be minimum impact on the
current scope, timeline, milestones including Micrososft IP efforts.  I
propose the following:

1) A reorganization for a generalized, open standard MARID-CORE framework
100% based on prior art. The new MARID-CORE framework based on EPV-CORE
removes specific methods and technologies allowing for future MARID end
point validation concepts to evolved,

2) Sugggestion split/new MARID working groups:

- MARID-EPV-CORE - solidifying, fine tuning a strong open standard
generialized framework for EPV
- MARID-EPV-SPF/SENDERID - getting a implementation standard for usage.
- MARID-EPV-CSV - exploring a future network infrastructure

o Background:

The MARID-CORE can be modeled as followed using the EPV-CORE framework:

   EPV = EPV-CORE-MARID(EPVD-MARID)

where EPVD-MARID is the process or domain elements:

   CIP    Client IP Address
   CDN    Client Domain Name, HELO/EHLO (RFC2821)
   AUA    Authentication User Access, AUTH (SUBMIT)
   TRP    Transaction Return Address, MAIL FROM (RFC2821)
   TFP    Transaction Forwarding Address, RCPT TO (RFC2821)
   PRA    Purported Responsible Address
   TPL    Transaction Payload, DATA (RFC 2822)
   DNS    Domain Name Server Database

Note: TPL includes the SMTP envelope and Received.

The EPV-CORE-MARID framework provides a functional model:

   EPV = EPVM-MARID(EPVM-SUBMITTER, EPVM-SENDERID)

where

   EPV = EPVM-SUBMITTER (EPVD-SUBMITTER)
   EPV = EPVM-SENDERID  (EPVD-SENDERID)

where EPVD-SUBMITTER is the SUBMITTER protocol domain data:

   CIP    Client IP Address
   CDN    Client Domain Name, HELO/EHLO (RFC2821)
   AUA    Authentication User Access, AUTH (SUBMIT)
   TRP    Transaction Return Address, MAIL FROM (RFC2821)
   PRA    Purported Responsible Address
   DNS    Domain Name Server Database

where EPVD-SENDERID is the SENDERID protocol domain data:

o Implementation:

The pseudo code for thie EPMV-MARID model would be:

   EPV = EPVM-SUBMITTER(EPVD-SUBMITTER) and
         EPVM-SENDERID (EPVD-SENDERID)

The following show the implementation and SMTP integration possibilities
with both POST SMTP (old software) and DYNAMIC SMTP (new software) mode of
operations. The SMTP state points are shown to gain a perspective of how
MARID fits into the SMTP model.

The first set is based on current SMTP usage where administrators use MARID
in post-SMTP operations:

1.0 - Current SMTP,  Post SMTP operations

   1.1 - Full MARID support

   HELO
   MAIL FROM:
   RCPT TO:
   DATA
   QUIT
   Post SMTP    EPVM-MARID

   1.2 - SUBMITTER support only

   HELO
   MAIL FROM:
   RCPT TO:
   DATA
   QUIT
   Post SMTP    EPVM-SUBMITTER

   1.3 - SENDERID support only

   HELO
   MAIL FROM:
   RCPT TO:
   DATA
   QUIT
   Post SMTP    EPVM-SENDERID

2.0 - New SMTP,  Dynamic SMTP operations

   2.1 - DATA event, full MARID support

   HELO:
   MAIL FROM:
   RCPT TO:
   DATA         EPVM-MARID
   QUIT
   Post SMTP

   2.2 -  MAIL FROM and DATA events, full MARID support

   HELO:
   MAIL FROM:   EPVM-SUBMITTER
   RCPT TO:
   DATA         EPVM-SENDERID
   QUIT
   Post SMTP

   2.3 - MAIL FROM event, SUBMITTER support only

   HELO:
   MAIL FROM:   EPVM-SUBMITTER
   RCPT TO:
   DATA
   QUIT
   Post SMTP

   2.4 - DATA event, SENDERID support only

   HELO:
   MAIL FROM:
   RCPT TO:
   DATA         EPVM-SENDERID
   QUIT
   Post SMTP

o Implementation Issues and Problems:

Problem #1:  Exclusive Technology - stops "better mouse traps"

MARID-CORE is locked into using two specific methods with questionable
technology and implementations.  This stops MARID from growing with new
and better "mouse traps."

Problem #2:  Dependency on PAYLOAD

Based on the possible implementations, some may not be compliant with
MARID-CORE. This suggests that a system who can not use SUBMITTER must
use SENDERID to complete the EPV.

Problem #3: IP Conflicts?

The reasons for drafting the EPV-CORE framework are:

o Outline a prior art generalized EPV framework that models the basic
  concept of validating end points in a C/S or P2P session.

o Escapulate all prior art SMTP process elements into a generalized
  EPV-CORE SMTP framework.

o Illustrate EPV-CORE modeling of current implementations

o Provide an open standard framework,

o Isolate IP issues outside the basic EPV-CORE framework.

Example:  Microsoft IP issues regarding SUBMITTER and SENDERID

One the main problems with the current MARID framework is its dependency on
specific technologies.

Ironically, one of the IP issues in question is the SENDERID proposal which
seems to gain some sort of "IP" strength based on the introduction of this
new MAIL FROM modifier, SUBMITTER, which is currently non-existing in the
process space.

Microsoft can not claim a right to SUBMITTER for the following reasons:

- ESMTP MAIL FROM Modifier

SUBMITTER is based on prior art and usage of a ESMTP MAIL FROM modifier. So
no IP can be claimed with this mechanism.

All that can be possible be claimed is a copyright on the term "SUBMITTER"
but the data itself is already within the process space.

The PUA (Persistent User Address) is already in the process space which the
MSA can automatically use and the AUA (Authentication User Account) can also
be used to define this element. The MUA can provide it itself, but the MSA
still needs to validate it as well against its own process space.

In other words, it is not new "data" which is one basic requirement for a
software method patentability - a new piece of information.

- Optimization

Microsoft documents SUBMITTER as an "Optimization" technique. This is good
excellent material for patentability - improving an existing process always
gets bonus checks.  However, the key words is "existing
process."  SUBMITTER is based on improving the SENDERID "process" as a way
to optimize the SMTP transaction.

While it quite conceivable to obtain a patent for the two where one if
lacking, the overall concept linking RFC 2821 MAIL FROM with RFC 2822 for
optimization is already prior art.

   RFC 2821 Section 3.3 - "Mail Transactions"

     Despite the apparent scope of this requirement,
     there are circumstances in which the acceptability of
     the reverse-path may not be determined until one or more
     forward-paths (in RCPT commands) can  be examined.
     In those cases, the server MAY reasonably accept the
     reverse-path (with a 250 reply) and then report problems
     after the forward-paths are received and examined.
     Normally, failures produce 550 or 553 replies.

In other words, RFC 2821 had the vision to deal with this real "chicken and
egg" problem.

If Microsoft can make a claim on SUBMITTER/SENDERID for optimization, then
it would be possible for other people to make a claim for "optimization" the
entire MARID-CORE method as follows:

Problem #4: What about other End Point - RCPT TO?

Can we try to make an IP claim here with this specific and quite possibly
unique Optimization method?

Based on the possible implementations, post SMTP MARID operation will have a
major bounce problem which contributes to the SORBIG bounce mail
distribution problem.

The #1 defense against SORBIG is to stop the transaction for non-delivery
mail before the payload is accepted.

MARID-CORE implies a large dependency on dynamic operations, and hence new
designs.  It would be illogical for software developers to allocate redesign
resources for a new dynamic SMTP implementation of MARID-CORE without
considering other optimization ideas.  For example:

   MAIL FROM:   EPVM-SUBMITTER
   RCPT TO:     ?
   DATA         EPVM-SENDERID

It is illogical to put such a high emphasis on the sender EPV with little to
no focus on the receiver EPV.

While one might view this as an "implementation" issue, in my view from a
MARID-CORE "Framework,"  the possibility should not be excluded and it isn't
in current prior art.

For example:

One MARID optimization implementation is shown with the EPV-CORE model for
the Wildcat! SMTP server (WCSMTP)

    EPV = EPVM-WCSMTP(EPV-RCPT, EPV-FROM)

where

    EPV-RCPT  = EPVM-LUV (TFP, UDB)
    EPV-FROM  = EPMV-WCSAP (CIP, CDN, TRP, TFP, DNS)

An alternative WCSMTP functional model representation using a short-circuit
conditional statement would be:

    EPV = EPVM-LUV(TFP,UDB)
            and EPMV-WCSAP(CIP, CDN, TRP, TFP, DNS)

EPVM-LUV is a Local User/Domain Validation to validate the RCPT TO end
point.  If unsuccessful, the EPVM-WCSAP is bypassed.

EPVM-WCSAP offers a suite of sysop optional EPV methods to validate the
MAIL FROM end point:

    EPV-FROM = EPVM-FILTER (CIP, CDN, TRP, TFP)
    EPV-FROM = EPVM-RBL (CIP, DNS)
    EPV-FROM = EPVM-SPF (CIP, CDN, TRP, DNS)
    EPV-FROM = EPVM-MCEP(CIP, TRP, DNS)
    EPV-FROM = EPVM-CBV (TRP, DNS)

where

    EPVM-FILTER - Internal rule based white/black action list
    EPVM-RBL    - DNS based RBL lookup
    EPVM-SPF    - Sender Policy Framework
    EPVM-MCEP   - Microsoft CallerID Email Policy
    EPVM-CBV    - SMTP based Call back Verifier.

The EPVM-WCSMTP model basically adds a local user EPV to RPCT TO before
attempting to validate the sender:

   MAIL FROM:   250 Sender Validation Pending. Continue.

   RCPT TO:     EPVM-LUV(TFP,UDB) and
                            EPMV-WCSAP(CIP, CDN, TRP, TFP, DNS)
   DATA:

If EPV-CORE-MARID is going to be added, the WCSMTP model would will change
like so:

   MAIL FROM:   250 Sender Validation Pending. Continue.

   RCPT TO:     EPVM-LUV(TFP,UDB) and
                             EPMV-WCSAP(CIP, CDN, AUA, PRA, TRP, TFP, DNS)

   DATA:        EPVM-SENDERID (TPL, DNS)

And in EPVM-WCSAP, we would replace EPVM-SPF and EPVM-MCEP with
EPVM-SUBMITTER:

    EPV-FROM = EPVM-FILTER (CIP, CDN, TRP, TFP)
    EPV-FROM = EPVM-RBL (CIP, DNS)
    EPV-FROM = EPVM-SUBMITTER (CIP, CDN, AUA, PRA, DNS)
    EPV-FROM = EPVM-CBV (TRP, DNS)

I can't patent this MARID-CORE implemention method by throwing in a
EPV-LUV() method because RFC 2821 already provides a priort art technical
consideration of delaying the "MAIL FROM" EPV until the "RCPT TO"  EPV is
known.    If RFC 2821 did not say this, then there I would a strong basis
for patentability (with today relaxed "computer methods" quidelines).

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 21 Jul 2004 12:05:49 -0400

I wasn't pretty clear on a very fundamental consideration about EPV-CORE.

EPV-CORE is based on a concept of having a "BlackBox" EPV capability at each
point in the SMTP state machine model:

   connect        EPV = EPVM-CIP(CIP)
   HELO/EHLO      EPV = EPVM-CDN(CIP,CDN)
   MAIL FROM      EPV = EPVM-TRP(CIP,CDN,TRP)
   RCPT TO        EPV = EPVM-TFP(CIP,CDN,TRP,TFP)
   DATA           EPV = EPVM-CDN(CIP,CDN,TRP,TFP,TPL)

In general, the EPV has six basic interpretations:

   epvNone      EP is non-deterministic by EPV-METHOD.
   epvAccept    EP was accepted by EPV-METHOD
   epvReject    EP was rejected by EPV-METHOD.
   epvExpire    EP is expired
   epvAbort     Server *SHOULD* abort the transaction.
   epvError     An error was detected by EPV-METHOD.

As far as SMTP is concern,  it doesn't really matter how that result was
achieved as a blackbox model.

So for EPV-CORE-MARID, it fits very nicely like so:

   connect        n/a
   HELO/EHLO      EPV = EPVM-MARID-SPF(CIP,CDN)
   MAIL FROM      EPV = EPVM-MARID-SPF(CIP,TRP,PRA)
   RCPT TO        n/a
   DATA           EPV = EPVM-MARID-SENDERID(TPL)

The goal of EPV-CORE is to provide a "plug and play" prior art, open
standard model so that the internet mail system is not locked into using a
technology that a) may not be suitable for the job, b) has other society
oriented concerns.

If tomorrow we come with a better solution, like CSV or something else, no
one is locked in with deprecated methods.

For example, using CSV as a possible replacement:

   connect
   HELO/EHLO      EPV = EPV-CORE-CSV(EPVD-CSV)
   MAIL FROM
   RCPT TO
   DATA

Here is how the current CSV framework can be viewed based on a new
EPV-CORE-CSV framework:

                  EPV-CORE-CSV:
            "EPV-CORE Framework for CSV"
                 by Hector Santos

o Summary:

The current CSV proposal can be remodeled using EPV-CORE
framework as followed:

   EPV = EPV-CORE-CSV (EPVD-CSV)

where EPVD-CSV is a set process or domain elements:

   CIP    Client IP Address
   CDN    Client Domain Name, HELO/EHLO (RFC2821)
   SRV    Domain Name Server Database SRV record
   DNA    Authorization/Reputation Service

EPV-CORE-CSV provides an CSV functional model based on the result of two
CSV protocols; CSA and DNA:

   EPV-CSV = EPVM-CSV(EPV-DNA, EPV-CSA)

where

   EPV-CSV is the result of the EPVM-CSV method based on
   the result of EPVM-DNA and EPVM-CSA methods:

   EPV-DNA = EPVM-DNA (CIP,CDN,DNA,DNS)
   EPV-CSA = EPVM-CSA (CIP,CDN,DNS)