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