--------------------------------------------------------------------------
The Council Meeting on 2005-02-29
HTML: http://spf.mehnle.net/Council_Meeting/2005-02-09
--------------------------------------------------------------------------
On Saturday 2005-02-09 at 22:30 UTC, the council held its weekly meeting
on IRC[1]. There was a pre-planned agenda[2]. All five council members
were present.
Chairman's Report. Chuck reported that the AMSG committee's
recommendation[3] and the press release announcing the submission of the
draft-schlitt-spf-classic-00[4] specification draft to the IETF were still
outstanding due to significant changes in his personal life. He asked for
an extension of the timeframe for the AMSG committee's recommendation
until 2005-04-01[3], which was willingly granted by the council. Chuck
also promised to address the press release within the next week.
Executive Director's Report. Meng reported that he had not yet received
a response from HSARPA[5] regarding the (yet unpublished) proposal he had
submitted to them. Also, in collaboration with P. Oscar Boykin[6] he had
submitted a similar proposal (also including the Karma concept[7]) to the
US National Science Foundation (NSF)[8], from where he expected a response
not before 2005-08. Meng had also been doing some research on SPF's level
of adoption: based on all the mail received by Pobox.com, 12% of all the
domains have an SPF (v1 or v2) record, and 26% of all messages have MAIL
FROM identities in domains that have an SPF record (v1 or v2). He planned
to present these figures at the MAAWG[9] meeting in March[10].
Microsoft/Sender-ID and SPF. Meng reported that he had been in contact
with Microsoft and that they had complained about three aspects of the
current official SPFv1 specification draft[4]: the mention of HELO
checking, the limitation of SPFv1 records to the use with RFC 2821
identities, and the concept of zone cut defaults. During 70 minutes of
discussion, the following conclusions were reached:
* HELO checking: Everyone agreed that HELO checking should be kept in
the SPFv1 specification, and nobody made a motion to repeal the
existing resolution[11].
* Zone cut defaults: Following the last month's discussions of the
issue on the spf-discuss mailing list, it was quickly agreed on that
the zone cut default algorithm should not be used by SPFv1[12].
* Limitation of SPFv1 records to the use with RFC 2821 identities:
Meng reported that he had been told by Microsoft that the IETF DEA
directorate was going to review a set of drafts that would constitute
a greater Sender-ID scheme, and that Microsoft did not like the
draft-schlitt-spf-classic-00 draft in this context. Meng wanted to
accommodate Microsoft by either blessing the use of the
draft-lentczner-spf-00[13] draft for that purpose, or by removing any
language from the draft-schlitt-spf-classic-00 draft that explicitly
advised against the use of SPFv1 records with RFC 2822 identities,
because he was not convinced by the current specification's reasoning
in this area, and because he saw a possible cooperation with Microsoft
with regard to Sender-ID (with SPF as a part of that) as a big chance
for furthering the adoption of SPF/Sender-ID. He added that
Microsoft's voice might bear serious weight for the IETF.
However, the other council members unanimously reaffirmed their view
that there was a significant conceptual and practical difference
between RFC 2821 and 2822 identities, and that this was reason enough
not to allow existing SPFv1 records to be used for scopes for which
they were not meant. Also, Chuck, Julian, and Mark did not recognize
any valid point in letting the SPFv1 specification be influenced by
Microsoft at this stage.
In the end, no changes to the specification were decided, and it was
resolved that exclusively draft-schlitt-spf-classic-00, and not
draft-lentczner-spf-00, be continued to be promoted to the IETF[14].
Meng promised to uphold this resolution. However, Chuck suggested
that a path for a cooperative development of a subsequent SPFv2
standard could still be pointed out to Microsoft.
IIM, DomainKeys & Co. -- competing or complementary to SPF? Julian
surveyed the council for opinions about the position of other sender
authentication technologies like Identified Internet Mail (IIM)[15] and
DomainKeys[16] relative to SPF. It was a common, even uniform, view that
those were not directly competing with SPF, but really were complementary.
Julian added that within the field of content-bound (as opposed to
transport-bound) authentication methods, he actually preferred full-blown
message cryptography methods such as PGP and S/MIME. Also, he and Wayne
voiced some reservations against the equivalent use of transport-bound and
content-bound methods (i.e. SPF and IIM/DK) to compensate for the
shortcomings of each, and they promised to elaborate on the spf-discuss
mailing list.
In the end, it was unanimously decided to change the regular meeting
schedule from weekly to bi-weekly[17], after which the remaining agenda
items, "Roadmap for SPF adoption?" and "The future of SPF?", were
adjourned and the meeting was concluded at 00:13 UTC.
Julian Mehnle,
SPF Council Secretary.
References:
1. http://www.schlitt.net/spf/spf-council/2005/02/09_irc_log.html#20050209T2228
2. http://moongroup.com/pipermail/spf-council/2005-February/000163.html
3. http://spf.mehnle.net/Council_Resolution/9
4. http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-00.txt
5. http://www.hsarpa.com
6. http://boykin.acis.ufl.edu
7. http://spf.pobox.com/aspen.html
8. http://www.nsf.gov
9. http://www.maawg.org
10. http://www.maawg.org/news/0503_GeneralMeeting
11. http://spf.mehnle.net/Council_Resolution/11
12. http://spf.mehnle.net/Council_Resolution/21
13. http://www.ietf.org/internet-drafts/draft-lentczner-spf-00.txt
14. http://spf.mehnle.net/Council_Resolution/17
15. http://www.ietf.org/internet-drafts/draft-fenton-identified-mail-01.txt
16. http://antispam.yahoo.com/domainkeys
17. http://spf.mehnle.net/Council_Resolution/4