william(at)elan.net wrote:
First in the support of the appeal
[...}
That part sounds good.
it has also been noted that recent IAB appeal was due to
a lot simpler and non-technical issue (which was previously
quickly resolved by IESG)
Yes, but the "gap" between 3934 and 3683 is still tricky, and
the question of IETF review-lists vs. WG lists is apparently
also not as simple as I thought. Maybe Sam's proposal of an
3933-experiment can fix the "gap", and maybe the IESG can just
"decree" that 3934 and 3683 are also applicable on IETF expert
review lists. PITA but no plain nonsense, otherwise relevant
RfCs like 3066bis would have to address the issue individually.
It has been stated that further long delays are not desirable
and we should focus on getting existing SPF draft published
as RFC as soon as possible.
Nothing wrong with that, but it wasn't "our" idea that the two
appeals against "senderid" affect v=spf1, and it might be also
not how the IAB handles this. What we actually want is to get
independent "experiments" as far as possible, because that's
what they are in practice.
--- somewhat unrelated ---
Scott said that going for "PS" or "IETF experiment" might have
been a bad idea. As far as I'm concerned it was a _good_ idea,
I alwyays wanted "our" baby under IETF- instead of CYA-control.
And I also wanted an "IETF last call" to find all obscure bugs,
in other words any real issue folks like Keith and Bruce could
find if they try hard.
For obvious reasons the Redmond folks never wanted any "IETF
last call" for their part, PRA is a bit too odd - it can't fly
without first doing something with 2476bis and 2822. As shown
by your appeal.
Wayne also wanted an "IETF last call" and emulated it as good
as possible. Some real problems were identified and solved by
this approach, most prominently the "zone cut" issue.
Besides the former MARID AD wanted both SPF and PRA in three
or four experimental RfCs, it wasn't his decision that we went
back to v=spf1 after he terminated MARID (as it was of course
not our decision that he terminated MARID). An "informational"
RfC was never atttractive, for no side.
--- end of "informational" stuff ---
It was noted that its quite likely that during the time it
took for IESG to decide on previous appeal that some IESG
members like already consulted with some at IAB
Speculation. It's also possible that the IESG just confirmed
their original decision (= approval of senderid-core) waiting
for the IAB to find a better solution if necessary.
It's only natural that we find the ball again in our part of
the field. The IESG appeal was merlely a formal step required
by the procedures, why should they revise their first decision
only because "we" asked them to do this ?
and as such not much may be gained by the new appeal
More speculation, but it's impossible to predict the result.
nor is it certain if IAB would consider the conflicts between
the experimental RFCs to be serious enough problem to
intervene.
Yes, "we" are the folks who say that this is a serious problem.
This "we" might include folks who know why PRA and MAIL FROM
are different even if they don't like SPF. I don't think that
the IAB will bother with technical details, from their POV the
problem of conflicting experiments (SHOULD vs. NOT RECOMMENDED)
in the same "namespace" / "assigned number" v=spf1 is relevant.
it is possible that IAB may decide to not only annul IESG
decision to publish Sender ID draft in its current form but
to delay publication of SPF draft as well.
Not impossible, but I don't see why or how. "Better publish"
is a kind of tradition. We can prove that SPF (as is) is about
one year older than the proclaimed (after MARID) PRA-abuse. In
an appeal that historical aspect should be made crystal-clear.
IAB decision against SID draft may also not be enough to
change how Microsoft and existing Sender ID supporters view
this issue and they may continue to insist on reusing v=spf1
records
So what ? With an IAB decision that won't fly for long, there
were only seven IAB appeals, ever, since 1995. Jefsey's was
the first in the past four years, <http://www.iab.org/appeals/>
some in the email industry view current SPF Community
activities negatively largely due to the IESG appeal and what
is seen as combative attitude
I'd consider those parts of the "email industry" as clueless or
worse a part of the problem. SPF is designed to fix a flaw in
SMTP known as "251" or "5.3.6(a)". PRA is designed to address
a completely different problem, and it won't work with various
"worldwide upgrade" scenarios (all lists, all forwarders, ...).
We just don't want to be a part of this braindead PRA approach,
because we know it's a too giant step, a kind of FUSSP, it just
can't work only because MS wants it to work. If they start to
upgrade their MUAs now they'll be "almost ready" in a decade.
SMTP as it is doesn't have a decade. It has to be fixed now.
SPF offers this now.
And for the first appeal "our" delay was caused by attempts of
Julian and Wayne to discuss this issue with the other side. It
is a lie that "we" didn't try.
Everybody in the "industry" should know this, as they should
know why PRA = MAIL FROM is wrong. Hector reported here that
it works for 80% - anything with more that one permille false
positives is irrelvant for mail admins, they could do better if
they'd use BLARS to reject or drop mails... <shudder />
show that we can work together with others to help produce
better email authentication standards.
The places I see are the DKIM, ASRG, spamcop, RFCI, CLEAR, and
SMTP mailing lists. No vandalizing SPF hordes in sight, quite
the contrary.
Shorter summary and minutes of entire meeting will be posted
to spf-council mail list later during the week.
Thanks for info, I look at the log later, and if I've the time
for it I'll propose some points for the IAB appeal later.
The main point is clear, an appeal should be against the IESG
decision, not directly against PRA, reiterating those parts is
unnecessary, they are on record. We've to explain why we want
four letters in senderid-core removed instead of adding dummy
spf2.0/pra opt-out records everywhere, over 1,000,000 policies.
Bye, Frank
-------
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