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:
TPL Transaction Payload, DATA (RFC 2822)
DNS Domain Name Server Database
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).
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com