Meng,
On Sat, 2004-09-18 at 11:24, Meng Weng Wong wrote:
A patent application is not a patent; I understand that
nowadays applications are filed containing many claims that
the filer doesn't actually expect to be approved, but if
they are approved, bonus! So let's look at which claims we
can realistically expect to survive into patent form, and do
You are suggesting depending upon a particular Patent Office outcome. Patent
processes are not nearly that predictable. Feel free to present some evidence
to the contrary.
In general Internet-scale adoption and use of technology is significantly
constrained by the number of strategic dependencies to that adoption and use.
Fewer is always markedly better. Each critical dependency can have unwanted
outcomes, thereby jeopardizing the effort that depends on it.
I agree that the anti-fraud aspects of SPF/Sender ID are
stronger than CSV, and should not be abandoned just yet.
First of all, let's be clear about focus, function and dependencies:
SPF is mostly about validating a particular message's original sender. It does
this indirectly, by authenticating the RFC2821.MailFrom. It relies on the
authorization of the MTAs along the delivery path to each recipient. It
requires on-going coordination between the originating sender, the
administrator
of the RFC2821.MailFrom's domain name and administrators of each MTA along the
path the each recipient. SPF has no accreditation mechanisms.
Sender-ID is mostly about validating a particular message's author. It does
authentication of the RFC2822.From and authorization of the the MTAs along the
delivery path to each recipient . It requires on-going coordination between
the
author, the administrator of the RFC2822.From's domain name and administrators
of each MTA along the path the each recipient. These are often independent
administrative authorities. Sender-ID as no mechanisms relating to
accreditation.
CSV is about validating the operator of a peer (client) MTA. It does
authentication and authorization of the RFC2821.Helo/Ehlo domain name, used by
that MTA. It requires on-going coordination between the operator of that domain
name and the administrator the domain name used by the MTA in the
RFC2821.Helo/Ehlo; this is typically the same administrative entity. CSV also
does accreditation of that domain name.
So the scope and focus of each of these is notably different. One therefore
ought to be rather careful in comparing them.
CSV alone is not sufficient because it has a weaker
deployment driver than SPF / Sender ID. To wit:
Assessing adoption and use incentives requires a tad more effort. What are the
administrative requirements? Who must perform them? How often? What parts of
the
infrastructure must change? What problems does it solve? How do cost vs.
benefit compare? And so on.
SPF and Sender-ID require that someone responsible for generating or posting
content must know ahead of time what MTAs their message will go through. That
means that virtually every domain name must pre-register path records and must
maintain them when new or different paths will be used. So, for example, the
administrator of the originator's domain must know when the ISP who is running
the MTAs changes IP Addresses for their MTAs. And SPF and Sender-ID break
existing third-party origination and relaying scenarios.
Hence, SPF and Sender-ID work comfortably only for some very simple scenarios.
The fact that those scenarios are popular is seductive enough to make it easy
to
miss the challenges posed for other, entirely legitimate scenarios. Attempting
to apply SPF or Sender-ID to those other scenarios requires changing the nature
of email admin, ops and use.
CSV requires that the operator of a client MTA use some domain name that
supports CSV conventions. Any domain name will do. Hence the number of domain
names to support is some orders of magnitude smaller than for SPF or Sender-ID.
And CSV does not try to correlate message content with message path. So there
is
no requirement for ongoing "cross-talk" between administrative realms. Further,
CSV cannot evaluate an individual message. Rather it permits assessing an
operator's aggregate performance. SPF and Sender-ID cannot do this. CSV does
not involve any changes to Internet-scale scenarios, such as forwarding.
For all that, CSV and SPF/Sender-ID try to solve very different problems.
SPF/Sender-ID try to ask whether a particular message is likely to be safe.
CSV
tries to ask whether a particular MTA operator is likely to be safe.
"Will people reject my mail simply because I have no CSV
record?"
....
"Will people reject my mail simply because I have no SPF
record?"
These exemplars purport to go to the heart of what one can and cannot do with
the different mechanisms. What the exemplars miss is that no one attempting to
use them can reasonably assert a negative, in the absence of support by the
client. Hence, these schemes are primarily useful only for making a positive
assessment. That is the logic difference between confirming a sender that is
on
a whitelist, versus rejecting a sender that is not.
It is essential to assume that no scheme will have very large-scale adoption
anytime soon. Internet experience in changing existing services is quite
consistent on this point.
That ought to make us all pretty modest about our expectations. It also means
we should validate that a scheme is useful when there is small-scale adoption;
that is, when the typical case is that it is not supported.
"Considering that lots of domains have no SPF record,
that day is pretty far off. Though you never know how
aggressive some people might get."
"Then why should I bother?"
"Because when people forge your domain name in the
return-path or the headers, you get the bounces, and
your users get phished. Is that a problem for you?"
This says that the SPF is useful for protecting against forged bounce
addresses.
For this we modify the email architecture and we incur on-going path
registration costs.
So it seems to me that the average domain owner has a more
compelling case to do SPF than CSV.
CSV is not for the 'average' domain owner. It is strictly for MTA operators.
SPF and Sender-ID require on-going coordination between those average domain
owners and MTA operators. CSV requires no such coordination between
independent
administrative entities.
Care to re-consider your assessment about adoption and use incentives?
but you're not going to see uninterested parties
putting negative CSV assertions on all the other hostnames
that could be HELO'ed by MTAs.
I re-read this statement a number of times and I still can't figure out what
you
are saying.
I have been observing a pattern of fallacious debate which
can perhaps be called "winner takes all".
I've been observing a pattern of responding to all new issues with "we can fold
that into [the undocumented] Unified SPF". And, yes, that sounds a lot like a
winner take all model.
What is troubling is that it misses the long and well-established lesson that
schemes that try to be all inclusive usually fall down of their design,
implementation, administration and operations complexity.
d/
--
Brandenburg InternetWorking
dcrocker(_at_)brandenburg(_dot_)com
+1.408.246.8253