ietf-mxcomp
[Top] [All Lists]

Obstacles between us and the finish line

2004-06-30 22:39:22



Deadlines for this working group are rapidly approaching.  According
to Andy's recent post, we have about 2 weeks (until 07/18) to finish
things up.

In my (oh so very humble) opinion, I see the following obstacles in
the way:

1) Proposals must have solid I-Ds

2) Proposals must have working code

3) Proposals must have been tested on real world data

4) Proposals must have IP licensing terms that allow for use in both
   commercial and GPLed MTAs.

5) Proposals must not have gratuitous incompatibilities with an
   installed base.


I have said from very early on that I think we may well need more than
one RFC to handle the various identities.  To be quite honest, I don't
care if we have a dozen overlapping proposals, I think the market can
easily decide which are useful.

As such, I see the following proposals that may be considered:
SPF-classic, CSV, Sender-ID and Unified-SPF.

It appears to DMP, FSV, and Caller-ID are no longer being pushed by
anyone.


I'm going to go over all the proposals in a sec, but I think I should
make a few comments on the requirements.

1) solid I-Ds:  Proposals must have been gone over with many eyes,
especially with developer's eyes when they are trying to implement the
proposal.  I think it is far too late to do anything with a proposal
other than use it to implement code and make adjustments based on that
experience.

2) working code, and 3) testing, I think are pretty obvious.

4) IP licensing:  I'm not dogmatic about the GPL or commercial
licenses, but there are significant MTAs and mail filters that fall
under both kinds of licenses, and several others to boot.  I think
that any proposal that has incompatible IP licensing needs to be
dropped.

5) Incompatibilities:  Proposals such as SPF have a significant install
base and doing things like moving the location of the TXT records,
dropping macros, or using a different RR, etc. make no sense to me and
will likely run into a buzz saw with SPF adopters.



Ok, so how do the current proposals stack up?


****   SPF-classic   ****

1) solid I-D:  Yes
It was supposed to have been submitted as an experiemental RFC, but I
don't know the status. 

2) working code:  Yes
Lots of working code in fact.  New announcements of commercial
products using SPF a couple of times a week.

3) Tested:  Yes
It is being used to check millions of emails per day.

4) IP Licensing:  No problems

5) gratuitous incompatibilities:  None.


I think SPF-classic should certainly be *one* of the proposals put
forth by this working group.



****   CSV   ****

1) solid I-D:  pretty good
To the best of my knowledge, no one has tried to implement code based
on it, but it appears to have been well reviewed by a fair number of
people.  I think there is time to get implementation experience if the
backers hurry.

2) working code:  none

3) testing:  none

4) IP Licensing:  No problems

5) gratuitous incompatibilities:  None.


I think that CSV could be one of the proposals, if its backers quickly
start creating working code and doing testing.



****   Sender-ID   ****

1) solid I-D:  No
I have looked again at the draft-ietf-marid-core-01.txt I-D, and
frankly, it is not even close to being in a state worth commenting on.
It is hugely incomplete and incompatible with SPF, which it tries to
be compatbile with.  I can't see it becoming solid in the next couple
of weeks.

Heck, it still has the XML stuff in it and the changes from the -00
version are very minor.  It appears that little work is being done on
this and it is unlikely to be ready.

The SUBMITTER I-D appears to be in better shape, but again, no one has
tried using the I-D to implement the spec, so there could be
significant errors.

2) working code:  none
In particular, the PRA and SUBMITTER are both on paper only.

3) testing:  none
I requested results of the PRA algorithm the first day that the
Caller-ID spec was proposed to this working group.  I made a point of
raising the issue at the interim meeting.  In the many months since
then, nothing has been forth coming.  I am getting seriously worried
about this.

4) IP Licensing:  problems
It appears that the Sender-ID's license is incompatible with the GPL.
This could, in theory, be fixed very quickly, but the issues of IP
disclosure and licensing problems has been known since before the
interim meeting and nothing has been done.

5) gratuitous incompatibilities:  None.
In theory, the only incompatiblity is that it tries to use existing
SPF records for 2822 checks.  Since SPF records were published with
the idea that they would be used for 2821.FROM and 2821.HELO, there
could be problems.

In practice, there are many incompatiblities with the current
Sender-ID spec and the SPF spec.


While Sender-ID appears to be the RFC-apparent for this WG, I have
very serious doubts that it will be in any shape to be advanced before
the deadlines.  I am beginning to think this proposal should be
dropped as the backers of key parts appear to be moving way too
slowly. 



****   Unified-SPF   ****

1) solid I-D:  fuzzy
As Dave Crocker pointed out in a message earlier today, there is no
Unified-SPF I-D.  This needs to be fixed ASAP or this proposal must be
dropped.  Fortunately, the differences between SPF-classic and
Unified-SPF are small enough that I think I-Ds could be written fairly
quickly and yet remain pretty solid.

2) working code:  none

3) testing:  none

4) IP Licensing:  No problems

5) gratuitous incompatibilities:  None.
The Unified-SPF proposal needs to make some changes to the SPF records
in order to support the various scopes that it tries to cover.  This
can be solved several ways.


I think that Unified-SPF has a chance to be a solid proposal, but the
I-Ds need to be written and the changes to the SPF-classic code needs
to be tested.



****   DMP   ****

Ok, I said DMP isn't being pushed by anyone, but I'll list it anyway

1) solid I-D:  Yes

2) working code:  Yes

3) testing:  Yes

4) IP Licensing:  No problems

5) gratuitous incompatibilities:  None.


I think that DMP is in far better shape than most of the other
proposals that appear to be much more likely to advanced by this
working group.  *boggle*


Right now, I would say that SPF-classic and DMP are the only proposals
that are ready for RFC consideration.  For backers of other proposals:
you have two weeks to finish.


-wayne