On Wednesday 2005-05-18 at 21:30 UTC, the council held a meeting on IRC. There was a list of items to be decided, with an addition by Wayne and one by Julian. Chuck, Julian, Mark, and Wayne were present; Meng was absent.
Chairman's report. Chuck had nothing to report.
Executive Director's report. Meng was not present, so the Executive Director's report had to be skipped.
Project website. Mark wanted to know whether Meng had given Julian or Wayne editorial access to the http://spf.pobox.com website, which they denied. They explained that this was not what Meng had intended to do, but that he just wanted to synchronize the website from a staging site. Chuck pressed for building an independent website so as not to require Meng's cooperation for the process. Julian asked the council to bear with him for a few more days while he was organizing the website issues.
Issues in the SPF specification draft. There were a number of design choices that so far could not be resolved through discussion on the project's main mailing list and thus had been referred to the council for judgement:
Whether the PermError result code should be treated like None or SoftFail. Wayne explained that the specification draft had previously recommended to reject the message on a PermError result, but that, because that was dictating receiver policy, he had changed it to recommend a response similar to that for SoftFail. Julian remarked that this was still dictating receiver policy. Mark wondered whether it was intended to abandon the prescription of receiver policy altogether, and Julian went on to stress that this was the way to go. Wayne replied that he could not see getting rid of all suggested receiver policy in the specification but that a separate best common practices (BCP) document might be of value, to which Mark and Julian agreed. Mark said that he might indeed work on the creation of a BCP document. But both of them reiterated that prescribing that PermError be treated similar to SoftFail did not make sense to them. After a short debate and some revisionism about what PermError should really be called, it was decided that the issue wasn't ready for quick judgement by the council and should be moved back to spf-discuss for further discussion.
How source routes and similar archaic features should be treated in the specification. Wayne explained the issue to the other council members. Julian proposed making the specification say that SPF did not support source routes, which Mark supported. However Wayne said that this was not a matter of what SPF supported but of how SPF could be circumvented by attackers by supplying MTAs with legacy sender address formats. In the end it was decided, that this issue, too, would have to be discussed more extensively, so it was moved back to spf-discuss.
Whether recommending against checking non-RFC-2821 identities should be avoided. After the previous council meeting, Scott Kitterman had wondered whether the warning against the checking of non-RFC-2821 identities in the current specification draft might prevent it from achieving RFC status. However Wayne and Julian expressed their confidence that this was not the case. None of the council members present felt any reason to remove or weaken the warning, and since a resolution on the issue had just recently been passed, it was decided to leave it at that.
The definition of Pass and the significance of cross-user forgery. Wayne reported that a new section on the cross-user forgery problem had already been added to the latest edition of the draft. Everyone agreed that the issue had been resolved thereby.
The definition of Pass and authorization vs. authentication. Wayne explained that this issue was about whether a Pass result could be construed as a certification of authenticity of the sender domain, or just as a statement that the sending MTA was authorized to use the sender domain. He added that this was still a subject of active debate on spf-discuss. Julian said that he was not up to date with spf-discuss and that he would prefer to participate in the discussion there. Thus the issue was moved back to the mailing list.
Which RFC status the SPFv1 specification should aim for. William Leibzon had requested that the council vote on whether the SPFv1 specification should aim for Informational, Experimental, or Proposed Standard status. Wayne explained that he had not pursued any specific status with the IETF so far, but that the IETF was incorrectly assuming that draft-schlitt-spf-classic had been submitted within the scope of the former MARID working group. He also said that his father, who had been a long-time observer of IETF proceedings, had encouraged him to aim for Proposed Standard status. So it was unanimously decided that the IETF should be asked to consider the SPFv1 specification for Proposed Standard status.
Whether the application of SPF to non-existent domains should yield a PermError result. Julian's argument was that the application of SPF to invalid input data, such as non-existent domains, should result in PermError instead of None, but he added that according to the discussion on the main mailing list his proposal was likely to be voted down, and that he just wanted the issue settled once and for all. Wayne replied that PermError traditionally only meant errors in existing SPF records, and that None meant that either no SPF record was published by the domain or that no checkable sender domain could be determined. This view was also shared by Chuck. Julian admitted that his proposal would change the current definitions of PermError and None. Mark said that he could follow Julian's logic but that he could accept the current definition, too. When it became clear that all arguments had been exchanged, Julian tabled his motion and Wayne seconded it for the sake of being able to vote on it. Julian and Mark approved the motion, and Wayne and Chuck rejected it. After checking the council voting rules it was determined that a simple majority was needed for a motion to pass and that the motion was therefore rejected.
Finding a better name for "prefix". Julian explained that "prefix" was a bad name for a term in a formal grammar, since terms should be named after their semantical function, not after their syntactical one. He had previously proposed to name the term "sign" instead, however he would not insist on that as long as any semantically descriptive name was chosen. Wayne said he agreed with that, but since no one was able to come up with a good replacement name right away, it was decided that one should be sought on spf-discuss.
Section 9.3.1.2 does not warn about the 63 character limit. Due to the complexity of the last issue and the already quite extended duration of the meeting, it was decided to adjourn the issue until the next meeting.
The meeting was then concluded at 23:55 UTC.
