On Thu, 23 Sep 2004, Frank Ellermann wrote:
IETF was in very difficult position with all that happened
during last week.
Finding chapter 4 in RfC 2418 isn't very "difficult", and that
wasn't the first problem in this WG.
When WG was created, it was done so because people though SPF and CallerID
folks could come to consensus and quickly. That was no longer the case with
Microsoft not willing to move from its position on either license or on
core specs that went into callerid algorithm.
On a side I note that after last-call failed to kill PRA based on IPR
issues along (my preference at that time), I decided to finally use
my main stones and I was doning in very specific schedule:
1. Bring up the issue of Resent- headers not being compatible with RFC2822
2. Wait for confirmation from email gurus that Resent- headers are indeed
not compatible and that PRA algorithm and core needs to be changed,
(which means death of current specs on technical grounds)
3. Bring up the issue with Sender ID name to finally kill it off
4. After chairs officially kill Sender ID and are ready to say that
algorithm needs to be reexamined and other options can be talked
about, work on replacement with unencombered draft that does not
make PRA checking a requirement
I had an assumption on this from the start that Microsoft only patented
PRA, which turned out not to be true. I was however willing to ignore
their second (very broad) patent applicatiln and anything in the firs
that is also too broad and has prior art. In any case from above
we got to #4 and on Monday, the topic that was discussed in MARID
jabber session were the Resent- headers (topic set by chairs) with basic
agreement that their use as proposed was not compabile with RFC2822. After
that I sent the following email to chairs:
I think it would be right to summarize today's [Monday's] discussion on
jabber session that there was a consensus that the use of Resent-
headers as written in last published version of marid-core does not
correspond to their intended use as specified in RFC2822
There is also an agreement that current email use of Resent headers is
not consistant with PRA algorithm either (i.e. they are not used by mail
lists at all and only by very few forwarders)
There is no agreement on what to do and what kind of replacement is
appropriate and that needs to be discussed.
I suspect that from the start there were some agreements that MARID
will work on bringing CallerID up for standartization and that if it
could not do it in the form that is acceptable to Microsoft, it would
withdraw the support. When IETF was put in such a position and at
the same time we had AOL that also withdraw its support and we
had all the patent issues (and that it appears Microsoft broke
rules and did not fully disclose that it patented entire area of
MARID work) this was all enough to kill MARID.
If I were at IESG, I would probably vote for the same thing as well.
I think it would be approriate to continue in the path was
going on at MARID and with marid-protocol draft being renamed
to spf-protocol and with separate draft covering mail-from as
has been recently published by Mark.
Yes, let's consolidate Mark's work (and the work of MARID) in a v=spf1
compatible syntax, because that's what everybody uses today.
I'll wait for answer from Mark on this.
This goes along the Universal SPF direction.
I'm very reluctant to try more "unifications" at the moment,
the last time was bad enough.
The "last time" we were constained by IETF.
And now, likelLike Meng said, we're now free to proceed with SPF work
and extending SPF to other identities (like HELO, which in MARID
was covered by CSV).
I think we also need to look at some modifications made to
protocol by Mathew Elvey which he released as spf3.
I haven't seen this one yet, do you have a URL ? Google wants
me to use the ASRG wiki, but the ASRG wiki is closed. <sigh>
http://elvey.com/it/sieve/draft-ietf-marid-spf3-00.txt
Wiki was better because it allowed to see differences that he made to
marid-protocol (not that many really...). He's proponent of HELO checking
based on SPF records, but draft modifications were more general then just
for HELO (inspite of him using that for all examples).
at the same time SPF2.0 scoping is more structured with
less chance of errors by those publishing records.
If you think that we need other scopes (not "PRA") in the near
future, then the spf2.0 syntax is fine. What do you have in
mind (in addition to "mfrom") ?
HELO, PTR
On PTR, I've started gathering input about what is needed from ISPs
and smaller mail operators. I note that for PTR scope, ISP view is
more important because they are the ones that will need to deploy it and
I don't think there are too many people on this list who represent company
that can truly be called an ISP (especially not the ones with ip blocks
directly assigned/allocated by RIRs).
If there is enough interest in folks that wanted something that checks
RFC2822 headers, I'll publish my SUBMITTER draft (actually I'll prefer
different name for it now) probably tomorrow - with closing of the WG
I need to make some changes to it now. But as it requires changes
to MTAs (new SMTP extension, new headers added), I have doubts that
it can be deployed without standard status from IETF and my view
of that work was always that it is good only as replacement for
"Sender ID" algorithm to bring it away from Microsoft patent problems.
I'll not particAipate in the SPF effort further if we do not
agree to work on moving to new dedicated SPF RR DNS records
for the future.
IMHO you can't simply invent new RR types, that's something the
IETF is supposed to do.
No. Its something that IANA has to do.
IANA is part of ICANN - its not part of IETF.
and that's why there was a MARID WG. But MARID was closed, so how do you
think to get a new DNS RR ?
RFC2929 governs assignments of DNS parameters by IANA:
http://www.faqs.org/rfcs/rfc2929.html
Publishing experimental RFC would be enough to get new RR type.
Alternatively we could choose to use RR type like 33001 and request
its assignments directly from IANA (assignments smallers then 32k are
done only by RFC auction, assignments larger then 32k can be done
by other specifications).
I would favor trying to push SPF protocol through IETF as EXPERIMENTAL,
at closing of the WG, they basicly said they would do it.
One possibility is working to extend
draft-kucherawy-sender-auth-header-00.txt
and to document use of such header for SPF needs.
Remember, we just lost the working group for this purpose.
You'll no doubt notice that draft was published as individual submission.
Point being that IETF drafts don't need to be done by WG
The draft is still in the "good idea" state, and actually the "PRA"
fans could profit most from it.
PRA is dead. I have some reason to believe it might not be accepted even
for EXPERIMENTAL RFC on technical grounds. I doubt that will matter to
Microsoft, though.
It's not essential for classic SPF (spf2.0/mfrom), but more flexible
than the old Received-SPF.
Flexible is better. Extensibility is also requirement for IETF specifications.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam Research Worksite:
http://www.elan.net/~william/asrg/