Back on July 1, I posted a message with the subject "Obstacles between
us and the finish line". I posted an updated to it two weeks later.
I decided to go back and post another updated.
The first two messages message can be found here:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02476.html
http://www.imc.org/ietf-mxcomp/mail-archive/msg02651.html
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.
For those who don't remember, 7/18 was the first deadline for MS to
fix the license.
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.
Sadly, in response to this post back in July, Ted Hardie (the IETF
Area Director for this WG), told us to stop worry about IP licensing
issues. I believe the mess we are in right now is a direct result of
this. Instead of getting the IP licensing issue resolved *much*
earlier on, we now have a crisis and a no-win situation.
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.
I think it is really too bad that SPF-classic was not *one* of the
proposals. It would have made our live much easier right now.
**** 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.
Better I-Ds have been put forward, but I know of no change on the
implementation experience part.
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.
I think it is kind of funny that CSV has made it on the WG TODO list,
but neither SPF-classic nor Unified-SPF did.
**** 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.
The SenderID I-Ds have been much improved since July, but I think
there are still a lot of rough edges.
2) working code: none
In particular, the PRA and SUBMITTER are both on paper only.
There is now some working code for the PRA, but none for SUBMITTER.
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.
Ok, a little small-scale testing has been done on the PRA now, but the
results have only shown that it doesn't work very well.
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.
Woah. Here we are two months later and *STILL* 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.
Ah, gratuitous incompatibilities have been introduced with the change
of the version number.
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.
Well, Sender-ID wasn't in shape to make the deadline of 7/18, so the
deadline was moved.
**** 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.
I wish I could say we have come a long way, but I don't think we have.
-wayne