Sender Policy Framework

On Wednesday 2005-02-09 at 22:30 UTC, the council held its weekly meeting on IRC. There was a pre-planned agenda. All five council members were present.

Chairman's Report. Chuck reported that the AMSG committee's recommendation and the press release announcing the submission of the draft-schlitt-spf-classic-00 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, 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 regarding the (yet unpublished) proposal he had submitted to them. Also, in collaboration with P. Oscar Boykin he had submitted a similar proposal (also including the Karma concept) to the US National Science Foundation (NSF), 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 meeting in March.

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: 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.

• 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.

• 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 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. 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) and DomainKeys 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, 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.