Speaking as an SPF user who is both fascinated by and has NO time to
get involved in the deeper technical issues, I support the appeal
simply because an "Experiment" whose data is threatened with
corruption by another simultaneous "Experiment" will have reduced
validity (if any at all.)
I also find it objectionable that the other experiment felt it was
necessary to co-opt the v=spf1 record for a purpose OTHER than its
intended purpose.
There you go...
On Sat, 4 Feb 2006 22:38:23 -0800 (PST), you wrote:
SPF Council would like request that SPF Community provide better
indication as to if an appeal to IETF IAB should or should not be made in
regards to misuse of v=spf1 records by Sender ID experiment. We request
that members of SPF Community (especially those who have not posted about
it before) clearly show their opinion on this issue and indicate
appropriate action (if any) that should be taken.
All voices in support or against appeal to IAB should be made by Tuesday
13:00UTC as at that time SPF Council plans to hold an emergency meeting
to determine if there exist a consensus in the community on how to proceed.
-----
During discussions at SPF Council several opinions on this subject were
raised which I will attempt to list below:
First in the support of the appeal it has been generally agreed that reuse
of v=spf1 records is technically wrong and leads to confusion and
incompatibilities. The syntax promoted by SID draft would force existing
v=spf1 record publishers who do not want to participate in Sender ID
experiment to have to .opt-out. and add additional records and that is not
an appropriate given their original intent. IESG decision to add
additional warning note about these problems does not resolve this issue
and as such the appropriate action within IETF is to appeal IESG decision
to IAB. It has been stated that recent IAB appeal was resolved quickly
(within one month) and this is an acceptable period.
At the same time 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) while an SPF appeal could take a lot longer given that
appeal to IESG took 4 months to decide. 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. 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 and as such
not much may be gained by the new appeal, nor is it certain if IAB would
consider the conflicts between the experimental RFCs to be serious enough
problem to intervene.
Further indications against an appeal are that if appeal is successful, 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. 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. It was also noted that
some in the email industry view current SPF Community activities
negatively largely due to the IESG appeal and what is seen as combative
attitude and it is in SPF.s best interest to change such view and show
that we can work together with others to help produce better email
authentication standards.
One of the possible actions that was proposed during council meeting was
to write an official SPF response letter (to be posted on main IETF mail
list) indicating SPF Community opinion that IESG decision did not go far
enough to address the issues raised in the appeal but that SPF Community
considers that it is in the best interest of everyone to not have any
further delays with publication of SPF draft as RFC.
---
Note that above was not an official meeting minutes but rather longer
summary of issues that were raised during discussion about IAB appeal by
various council members. Original logs of SPF Council discussion on IRC
can be found at:
http://archives.listbox.com/spf-council(_at_)v2(_dot_)listbox(_dot_)com/200602/0013.html
http://archives.listbox.com/spf-council(_at_)v2(_dot_)listbox(_dot_)com/200602/0015.html
Shorter summary and minutes of entire meeting will be posted to
spf-council mail list later during the week.
----
William Leibzon
Acting in the capacity of SPF Council Secretary
-------
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
Steven J Dorst
xxxxxx, yyyyy, zzzzz, aaaa,
bbbbbb, ccccc, Oh well, let's just say:
Jack of way too many, but not all, trades!
http://www.laner.com
mailto: Take my first name, append an underscore,
append my last name, then append "at"
laner.com
Note: actual job titles removed from signature because
they are often harvested, prepended to our domain and
used to generate spam!
-------
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