ietf-mxcomp
[Top] [All Lists]

Re: why we should not be ambiguous about receiver behaviour

2004-04-22 14:15:14

In 
<E48D24225D499E44BE0256A68B615E62093AA2(_at_)mail(_dot_)constantcontact(_dot_)com>
 "Olson, Margaret" <molson(_at_)constantcontact(_dot_)com> writes:

From: Jon Kyme [mailto:jrk(_at_)merseymail(_dot_)com] 
Sent: Thursday, April 22, 2004 3:18 PM

Wayne, I  wrote:
Until such time that there is at least a proof-of-concept code that we
can all play with and collect real data on real email feeds, I will
strongly object to including the RFC2822 identities as something we
should work on.

This is a self-fulfilling, circular, kind of position don't you think? It
is invalidated by the first sight of an implementation which uses these
identities... but you've ruled them out of scope already... So you can't
have a MARID proposal which uses them...

No, this not any more a case of circular reasoning than saying that
you need to move the horse around to the front of the cart is circular
reasoning.

This working group has a very agressive schedule.  What I'm saying is
that I, personally, will have very little confidence in any algorithm
that be applied to billions of emails that hasn't had extensive
real-world testing.

Let's look at the milestones again:

      March 04 Discuss identities [...]
      April 04 [...] last call on which identities [...]
      May   04 [...] semantics [...] syntax discussions [...]
      May   04 Publish one or more syntax proposals [...]
      June  04 Final selection [...]
      July  04 Working group last call

Whe have spent close to TWO MONTHS discussing "identities" and have
gotten almost nowhere.  Since the very beginning, most people have
agreed on what identities they would *like* to see validated.  Almost
nothing on the table now is that very different from what was floating
around since January.

I think the time has long past for people to come forward with
handwaving descriptions of how validation might work.  If the
algorithm hasn't been defined and tested by now, there is no way we
will get through the discussion of semantics in a month.

Right off the bat, I know that RMX, DMP and SPF have all had at least
proof-of-concept code publicly available since last summer.  There has
been testing done on live data with DMP and SPF for months.  The
results of that data has been published here and elsewhere.  Clearly,
it is possible for people to create, distribute and test
proof-of-concept code before an RFC is created.


In 
<E48D24225D499E44BE0256A68B615E62093AA2(_at_)mail(_dot_)constantcontact(_dot_)com>
 "Olson, Margaret" <molson(_at_)constantcontact(_dot_)com> writes:


[Some of the >100,000 ESPC members will try to publish records so
 that receivers have something to test on.]

This is great, and I really appreciate it.

However, the experience with SPF seems to show that it is much easier
to get people to publish records than to test them.  More importantly,
we need email receivers to start checking the results very closely to
look for real world problems.

Getting lots of published records, even when there aren't many testers
is great because it breaks the chicken-and-egg problem.  It is just
that we may need to make sure we push harder for testing.


Our observation so far is that just publishing the records is not
necessarily the straight forward exercise we had assumed it to be. This has
been a surprise.

You don't mention the problems you are running into, but this is
exactly what I'm trying to point out.  SPF made a huge effort to make
publishing records as easy as possible and still there are problems.
There is no subsitute for real-world testing to find out if something
works.


We are working on a report of our results to date (SPF and
Caller-ID).

I can't wait to see it.  Any idea when you think the report might be
available?



-wayne