Sender Policy Framework

On Saturday 2005-01-15 at 19:15 UTC, the council held its weekly meeting on IRC. There was a pre-planned agenda. Chuck, Julian, Mark, and Wayne were present; Meng was absent.

As usual, the first item was the Chairman's report. Chuck reported that he had been working on a "Sender-ID" position statement, which he had wanted to finish the prior week but had not managed to do so due to being short of time, and that his statement would include a gentle discussion of PRA. He also signaled that he would make an elaborate proposal to the AMSG committee by Monday. Chuck also admitted that he had not managed to continue working on the press release regarding the official IETF submission of the SPF specification draft.

Meng was not present, so the Executive Director's report once again had to be skipped.

As the next item, Julian suggested that simple weekly statistics (including the number of messages and the number of distinct topics) for the private council mailing list be published in order for the community to gain an idea of how much private discussion was taking place within the council. The suggestion was unanimously accepted. Wayne offered to take care of the implementation.

Following that, several aspects of the SPF specification and the standardization process were discussed:

• Wayne reported that within the IETF, the draft-schlitt-spf-classic-00 specification draft had been conveyed to the Directorate for DNS and Email Authentication (DEA), which is working in private by IETF standard policy. The DEA would contact the drafts's authors, Meng and Wayne, for any questions and comments. Wayne also stated that he had informed all relevant IETF working groups about the draft and that the DNS groups had raised objections, mostly regarding the zone cut default mechanism, but the e-mail working groups had not expressed any disfavor. Wayne said that he was working hard on another iteration of the draft.

• Julian wanted to know what needed to be done in order to get the new SPF DNS record type allocated by IANA. Wayne explained that the allocation would happen as part of the process of the SPF Internet Draft (I-D) becoming a Request For Comments (RFC). Julian suggested that after the allocation happened, the individual producers of DNS server software would have to be contacted and asked to implement the new record type.

• Concerning the Authentication-Results: header, Julian declared that he was strongly leaning towards making use of it for the SPF specification as the long-term successor of the custom Received-SPF: header, so as to avoid actively promoting two distinct headers with distinct formats. Wayne and Mark concurred in that this was not a priority, but Wayne acknowledged that a jointly standardized header in consultation of the other sender authentication technologies' designers would be valuable. Thus Julian solicited comments on the problems of the current Authentication-Results: specification with regard to SPF and promised to talk to the header's designers about it.

• Julian noted that he wished for a clearer vision of HELO checking in the SPF specification. He explained that since RFC 2821 already authoritatively required the HELO identity to be a valid FQDN, it were only consequential to at least clearly recommended ("SHOULD") HELO checking instead of merely suggesting it ("MAY"). Mark and Wayne showed basic consent with this assessment, so Julian offered to submit a precise modification proposal for the draft. On a slightly different matter, after it became clear that Julian did not want to contradict RFC 2821 by suggesting – in order to avoid the need for an additional SPF record – that MTAs say "HELO domain" instead of "HELO mx.domain" whenever domain and mx.domain denote the same host, this issue was quickly found to be uncontroversial.

The next issue was how the project should deal with FUD and misinformation about SPF by Yahoo. Wayne suggested that if Yahoo kept spreading such FUD the project should contact them and talk to them about it, and that otherwise they should just be ignored. Mark and Julian agreed that continued misinformation were indeed unacceptable. After some discussion, it was unanimously decided that a counterstatement to frequent FUD regarding SPF be created.

As the last planned item, Julian brought up the outdatedness of the SPF reference implementation (Mail::SPF::Query) and the test suite. It was commonly agreed on that at least either a good reference implementation or a good test suite was required in the mid-term. Wayne preferred the former while Julian preferred the latter, but no one dismissed the value of either. After some further discussion it was unanimously decided that both should be worked on with medium priority. Chuck wanted confirmation that if the reference implementation was supposed to be production-grade software, it should – like all production-grade software managed by the project – be packaged in a most usable manner. No one disagreed with that, but it was clarified that the reference implementation was primarily supposed to serve as sample code to supplement the SPF specification.

Finally, Julian noted that he planned to conduct a community-wide test vote using the Condorcet Internet Voting Service (CIVS), possibly also conducting the same vote using John Pinkerton's apportioned approval voting system in parallel, to evaluate the available options for community-wide votes and council elections.

The meeting was then concluded at 21:05 UTC.