I think people should recognize that we are in a situation that is not of
Meng's, Hadmut's or Alan's making here. Publicity and working groups do not
mix - as I tried to tell the people trying to create publicity.
At this point we should recognize that
1) We are talking about engineering, not invention here. The inventive leap
was Vixie/Miller if you call it that.
2) Credit does matter, it is not a trivial issue. NCSA's failure to cite the
work done at CERN that went into Mosaic killed the Web work there.
3) The details of the specifications probably do not matter very much at
all, much less than we have common agreement.
4) SPF has achieved a degree of name recognition.
5) There are probably folk in the press who would like to write a story
dismissing the whole field, we had that early in the Web with the security
issue. People build you up to knock you down.
Phill
-----Original Message-----
From: Meng Weng Wong [mailto:mengwong(_at_)dumbo(_dot_)pobox(_dot_)com]
Sent: Sunday, December 21, 2003 11:52 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] What is LMAP
On Sun, Dec 21, 2003 at 03:39:41AM -0800, Greg Connor wrote:
|
http://asrg.kavi.com/apps/group_public/download.php/15/draft-i
rtf-asrg-lmap-discussion-00.txt
|
| My impression of LMAP is that it has a bunch of
explanations of why we need
| it but doesn't contain specific principles of operation.
Also this is
| credited as ASRG or at least looks like it acknowledges ASRG. hmmm
I see the LMAP document as being an Applicability Statement. The SPF
document is a Technical Specification. The difference between the two
is discussed in RFC2026.
http://www.zvon.org/tmRFC/RFC2026/Output/chapter3.html
The rest of this message is my account of the ASRG reconciliation
effort. It is presented for historical purposes only. It doesn't
discuss anything technically relevant to SPF. The Gentle Reader is
advised to skip it.
|
| Q: what is LMAP and how does it compare to current proposals?
|
In October, Yakov Shafranovich emailed the authors of all the known
sender authentication proposals, including DMP, RMX, and SPF.
He asked
us to try to reconcile the proposals into a single unified draft,
because it would be better to present a single document to
the IETF for
RFC consideration than three competing documents which did the same
thing in slightly different ways.
http://article.gmane.org/gmane.ietf.asrg.rmx/236
Alan DeKok came out of nowhere and volunteered to edit the combined
draft, and was duly appointed Editor by the ASRG co-chairs.
After some
discussion and review of the existing proposals, Alan DeKok, Yakov
Shafranovich and Paul Judge (at the time) suggested that SPF
be used as
the basis for the combined proposal. I felt this was sensible because
SPF had originally been designed as a functional superset of DMP and
RMX.
http://article.gmane.org/gmane.ietf.asrg.rmx/260
The press started getting wind of our efforts, and quoted me by name.
http://news.com.com/2100-1038_3-5096820.html
To that point I had refrained from implying that SPF had the official
blessing of ASRG, because I had been told in private communication
explicitly not to say it did.
The Washington Post did a story for which I was interviewed, and I
talked about SPF.
http://www.washingtonpost.com/ac2/wp-dyn?pagename=article&node
=&contentId=A38051-2003Oct29¬Found=true
This upset Hadmut Danisch, the author of the RMX proposal.
http://article.gmane.org/gmane.ietf.asrg.rmx/252
And it upset Gordon Fecyk, the author of the DMP proposal.
http://article.gmane.org/gmane.ietf.asrg.rmx/264
http://article.gmane.org/gmane.ietf.asrg.rmx/269
It seemed to me that the reconciliation effort was not going to prove
fruitful. Personally, I had been working on the RFC draft
with this in
mind, and was surprised to see that level of upset from the others.
http://www.ietf.org/tao.html#6.2
6.2 Letting Go Gracefully
The biggest reason some people do not want their documents
put on the
IETF standards track is that they must give up change control of the
protocol. That is, as soon as you propose that your
protocol become an
IETF standard, you must fully relinquish control of the protocol. If
there is general agreement, parts of the protocol can be completely
changed, whole sections can be ripped out, new things can
be added, and
the name can be changed.
Some authors find it very hard to give up control of their pet
protocol. If you are one of those people, don't even think
about trying
to get your protocol to become an IETF standard. On the
other hand, if
your goal is the best standard possible with the widest
implementation,
then you might find the IETF process to your liking.
When John Levine replaced Paul Judge as ASRG co-chair, the
reconciliation effort took a new direction: instead of combining the
proposals, Alan DeKok would write a general applicability statement
regarding issues common to all the sender authentication
proposals, and
DMP, RMX, and SPF would each move forward. LMAP was chosen as the
generic name for sender authentication.
http://article.gmane.org/gmane.ietf.asrg.rmx/259
| Q: Who is the author (or "editor" as he credits himself)
Alan DeKok from
| Ottowa, canada? What is his motivation?
I believe his motivation is to see spam go down. My motivation is the
same: I want to see a sender authentication protocol widely
adopted, and
I have no particular attachment to any one of them. In
service to that
goal, SPF has consistently evolved in the direction of being
easier for
people to adopt on both the publishing and the receiving ends. I
believe we're already past the tipping point, and SPF is now the front
runner. I had previously said this on the ASRG-RMX list.
http://article.gmane.org/gmane.ietf.asrg.rmx/238
Spam is a big problem for my company, and I estimate that we can save
about $3000 a month in bandwidth and CPU and hosting fees if we could
make it go away. Saving $3000 a month is sufficient motivation for me
to work on SPF. Besides, it is an interesting problem worth solving,
and I am enjoying the contact with like minds which the project has
brought together. I have no particular desire to see myself
credited as
The Dude Who Solved Spam.
| Q: Danisch and Feyck are credited as contributors. Does
that mean this
| will rival SPF?
One might say that DMP and RMX are rivals to SPF. I don't really
understand this, because SPF is a superset of what DMP and
RMX do, and I
only forked SPF from DMP in the first place when Gordon made
it clear to
me that he did not consider the "include" functionality
useful. I have
put Danisch and Fecyk's names in the "author" spot on the
current draft,
so maybe that will make them happier.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily
deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡