In <41796C22(_dot_)A68(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
John Glube wrote:
* Do we have a clear understanding of where it is we want
to go with spf2.0?
No, I don't think we have a clear understanding yet.
I also think that there is a very real danger that if we start working
on SPFv2 before the SPFv1 draft is published as at least an
experimental RFC, that it will be both a distraction and possibly
cause the IESG to reject the SPFv1 draft as "already being obsolete".
* Do we have any input documents?
mengwong-00 (historical), protocol-03 (informational),
letczner-00 (current working document), schlitt-00 (proposed
fixes for known issues in lentczner-00), kucherawa-00 (idea),
leibzon-00 (status TBD, but at least informational).
For more input about HELO we could use the CSV-drafts (?)
For more input about PTR we should read the MTAMARK draft.
If there are SRS resp. SES drafts, we want them as input.
My article with the properties modifier tried to summarize
four proposals by Hector, Meng, Scott, and William.
I think that the Unified-SPF drafts would be a good start for HELO and
PTR, along with the other scopes. See: http://spf.pobox.com/unified/
Now, a lot of work has been done documents like 3-protocol.txt since
then, and I'm pretty sure that the marid-mailfrom and 6-mailfrom
documents are different. So, I don't think we can use them as is, but
they are a good start.
Meng also asked me to submit my ideas on the 2822.From: scope as part
of the above Unified drafts, and it can be found here:
http://www.ietf.org/internet-drafts/draft-schlitt-marid-spf-from-hdr-00.txt
I think there is bunch of clean-up that should be done in an SPFv2
langauge.
For example, the include: mechanism is *very* badly named since it
doesn't cause the referenced SPF record to be included. It would be
better to rename it if-pass: or something.
We should have a call: mechanism that returns the match values of the
called SPF record and only not match if it hits an "all" mechanism.
This would actually be much more of what many think the include:
mechanism does.
The redirect= modifier should become a mechanism, just like the
default= modifier became the all: mechanism.
Both the include:, redirect: and call: mechanisms should be able to
reference other scopes and/or SPF versions. For example, we could
have:
v=spf1 a mx -all
spf2.0/fromhdr call/spfv1 call:outsource.mailer.com -all
spf2.0/pra -ip4:1.2.3.4 redirect/fromhdr
This would make the From: Header scope be the same as the SPFv1
record, plus whatever their outsource mailer does. The PRA scope
would redirect to the SPFv2 From: Header scope.
There needs to be a %{e} macro variable for scoping.
And, there are a bunch of other things that I think should be cleaned
up.
But, again, I think we should wait until we can get the SPFv1 draft
accepted by the IESG first.
-wayne