spf-discuss
[Top] [All Lists]

[spf-discuss] Re: Successes and failures of the SPF project in 2005

2006-01-10 21:26:14
Julian Mehnle wrote:

I'd love to read your comments on all this.

ACK, mostly.  Nothing's unusual with the speed of progress in
the RfC-editor queue as far as I can judge it by watching what
Bill's tools watch.

For the WiKi maybe you could install a procedure similar to the
registration as voter for write access (I've now had my first
case of RV with an immediate counter-RV from me...  it's odd,
but not seriously worse than say Usenet ;-)

Other things on the "todo" side after AUTH48 could be to help
Wayne create a new test suite.  Maybe an online version below
an openspf.org subdomain.  Depending on how it's counted the
"two years experimental" are soon over, and if we'd take that
position we could start to work on stuff needed for a PS.

One vague idea I had was to rip off the 2821 appendix about
source routes, explain the history of mail routing from bang
paths up to SRS today, and claim that this updates 2821.  Or
better offer it for this purpose as informational RfC / I-D.

Without that mainly historical garbage John would have a
decent chance to get the core of 2821bis minus history right,
otherwise there are just too many controversial points now.

Another idea, actually that was Keith's idea:  A draft with
"PRA considerations" for those who are lost what all this
nonsense with spf2.0 vs. v=spf1 is about.  Minor variation:

Let's do a spf2.0/helo draft explaining why it's unnecessary
in the situation as it is, why implementing spf2.0/mfrom would
be also a waste of time, and how to combine v=spf1 with PRA
for those who seriously want it.

The result would contain many technical points of the two
appeals, explaining this for average admins and implementors,
not SPF- / PRA-geeks.  The MAAWG has a table claiming that the
(non-existing) spf2.0/mfrom would be without spf2.0/helo (also
not existing)

We're free to _define_ that spf2.0/mfrom _is_ compatible with
v=spf1 incl. HELO, because it was always MAY (and now SHOULD).

We're in the position to say that spf2.0/mfrom is pointless in
the situation as it is, no matter that I liked the concept of
positional modifiers, or that others might prefer that HELO is
independent of MAIL FROM.  Fact is, it's not, MARID failed to
deliver, and for HELO it's no real problem.

Having that clear as say informational RFC would be good.  Bye


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com