Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

Dan Schlitt <> Thu, 29 August 2013 16:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 002DA11E8124 for <>; Thu, 29 Aug 2013 09:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.98
X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id holQyfI4T1Pz for <>; Thu, 29 Aug 2013 09:31:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D8DA411E811B for <>; Thu, 29 Aug 2013 09:30:54 -0700 (PDT)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r7TGU9jC026224; Thu, 29 Aug 2013 12:30:12 -0400
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id r7TGU8PX198372; Thu, 29 Aug 2013 12:30:08 -0400 (EDT)
Received: from localhost (schlitt@localhost) by (8.13.6/8.13.6/Submit) with ESMTP id r7TGU8pl198299; Thu, 29 Aug 2013 12:30:08 -0400 (EDT)
X-Authentication-Warning: schlitt owned process doing -bs
Date: Thu, 29 Aug 2013 12:30:07 -0400
From: Dan Schlitt <>
Subject: Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In-Reply-To: <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Mailman-Approved-At: Fri, 30 Aug 2013 08:04:31 -0700
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Aug 2013 16:31:09 -0000

I did not participate in the original working group that developed SPF. 
However I had a number of long phone conversations with one of the folks 
who was active in the group. A good part of those conversations involved 
the use of the TXT record. I objected to overloading that RR. In 
response there was a bit of disparagement of namedroppers folks who 
joined in the discussions. In the end I was told that TXT worked and 
that was that.

I did join in the current working group and when the subject of the TXT 
and SPF records came up I commented that I believed it was inappropriate 
to overload the TXT record and that the SPF record was the correct way 
to go and a transition plan should be worked out. It became clear that 
there was a group that were determined to use the TXT record and get rid 
of the SPF record. So I didn't see much benefit in pushing my view in 
the WG.

As the manager of a modestly large network I found the TXT record as a 
useful tool in management of the network. Such a use was even suggested 
by other system managers. That was a time when the Internet was a 
friendlier place. Today I might do things differently and not make some 
of the TXT records visible on the public Internet. But they would still 
be useful for internal management.

The discussions in the working group made it clear that there were 
design problems with SPF. It would have benefited from a well focused 
problem statement and a related requirements statement. Most of the 
problems are internal to the framework.

It is a sender policy and there is no corresponding receiver policy 
framework. There were those who wished to add in things that essentially 
were a receiver policy.

The design feature that has a wider impact on the Internet is the use of 
the DNS. The working group was dominated by the internals of the 
framework and had little concern with broader questions. Internally the 
TXT record was their choice.

I believe that it is unwise to have a standards track protocol which 
overloads the TXT record. It is this last call which has a broader look 
at the proposed standard that is the place to make this judgment.

As far as the current use of the SPF RR is concerned I have the feeling 
that the members of the working group had a rather optimistic view of 
the actual use of the sender policy. It is not on the standards track. 
Having a standards track version should encourage more use of the 
framework. If the standard said use the SPF record that would increase 
its use. A transition plan which allowed the current installed base to 
continue on would allow a standard with out disruption.

It would be a shame to lose all the other work on the framework so, if 
the current version of the document can't for some reason be changed, it 
should be published as informational. It should be edited so that it 
describes the current use of the framework with suggestions for improved 

I do think that the folks who were tasked with leading the working group 
should be given credit for the job that they did. It was not the easiest 
working group to deal with. There were time when I feared that it would 
drop into the disfunctional state as, for example usefor. They avoided 
that and got the work back on track.



Dan Schlitt