From: Meng Weng Wong
Sent: June 18, 2004 12:12 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] a grand unified theory of MARID
"So right now there are many different "regions",
or identities, and each one uses a different
gauge size. CSV, DRIP, and DHVP are like railway
companies that run in the HELO region, and each
of them uses a different gauge, or record type.
RMX and DMP run in the return-path; one uses
block queries and one uses factored queries.
Caller-ID ran in the PRA, and used XML. And so
on.
What I am trying to do is make it possible for
SPF to serve as the standardized gauge size in
all the different regions.
Just because you can go there doesn't mean you
have to: if you don't want to do CSV-style HELO
checks, you don't have to; if you don't want to
do MTAMark-style PTR checks, you don't have to.
You can keep running Classic SPF without any
modification. I am just trying to build roads
for people to travel down."
By creating a standard medium while allowing
people to choose a particular method of sender
authentication is an excellent way of building
consensus.
However, it raises another issue.
As a sender, my concern is that some receivers
will elect to require a method of identification
which I don't use. This could in turn lead to
delivery fragmentation.
For the consensus to work, I suggest the MARID
working group will need to say to receivers "you
want to require sender authentication, then you
must choose method X, however you are free to
request other methods, providing these other
method don't prevent acceptance on the basis of a
sender using method X."
Otherwise you could end up with a situation where
the vast majority of senders are using method X,
but some receivers insist on method Y, meaning
senders are compelled to add method Y if the
sender wants delivery to those receivers.
The result? To be safe a sender will have to use
all methods.
You expressed this suggestion in your initial
note when you wrote:
"Let's suppose a well-respected sender decides to
play it safe and do all of the above."
I am not saying this is not doable, if each
method can be simplified, so that it can be
easily understood and implemented at no cost to
the sender.
I can appreciate you were using an example to
explain the various means of sender
authentication.
But in the process of wanting to build a
consensus, which makes sense, do we end up
running the risk of defeating the objective of
having one standard method of sender
authentication that works in all situations,
which is beneficial to both senders and receivers.
Using your train track analogy, you are saying,
"railways can use any type of locomotive they
want, but all trains must run on standard gauge."
This would roughly translate to sender
authentication as, "senders and receivers can use
any method of sender authentication they want,
but all receivers must accept classic SPF."
(I am referencing classic SPF, not being clear on
the status of the incorporation of Sender ID into
SPF, or its import on the standardization issue.)
Can you perhaps elaborate further on this point,
so we can better understand your vision of how
this will all come together?
John Glube
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.701 / Virus Database: 458 - Release Date: 07/06/2004