spf-discuss
[Top] [All Lists]

RE: Accountable Messaging Standards Group

2004-11-12 10:05:27


[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Dave 
Crocker

On Fri, 12 Nov 2004 15:44:59 +0000 (GMT), csm(_at_)moongroup(_dot_)com wrote:
  PHB has made what seems to me to be an excellent suggestion. He
  suggests that the subject line of this email should be the
  organizational name for what we're trying to form. In spite of the
  fact that he and I have had significant differences I happen to
  agree with this strategy. I invite comments and discussion?


1. gaining public acceptance as a 'standards' group requires 
some track record. the usual model for a group like this is 
that it works as an adjunct to formal standards efforts.

The group does not require a track record, the participants do. 

As you yourself admitted on the panel the treatment you got in MARID was far
from fair and transparent.

When we set up W3C we started off by telling everyone that it would not be a
standards body. Less than a year later we were a standards body, by
necessity, not choice after the HTML spec effort collapsed.


2. this is an spf effort.  characterizing it as something 
larger -- such as "accountability messaging" will merely 
cause it to overlap with other, independent efforts, thereby 
creating confussion.

Setting up an SPF body is going to cause considerably more confusion than a
group with a more ambiguous title. It will be seen as an ongoing battle with
Microsoft.

If you look at SPF in context the scope for improvement in SPF itself is
considerably less than the scope for companion specs that address connected
but separate problems. For example a recurring issue is the problem of what
to do with bounces of mail that fails SPF checks. Silently discarding it is
bad, but so is the bounce mechanism. From a pragmatic point of view it would
be very useful to have a companion spec that provides a principled method of
error reporting that is out of band, does not risk bothering the end user
and above all machine readable in a consistent and usefull fashion. There is
the need for an accreditation component in the spec. There is a need for
something that looks like BATV and so on.

In the wake of MARID I do not think that the MASS group will risk allowing
the IETF any scope for decision making in regard to the spec. If we go to
OASIS we slam the door on open source participation which I would prefer not
to do but is preferable to having the spec rendered undeployable.


                Phill