From sm@elandsys.com Thu Dec 6 15:21:14 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B2D21F8614 for ; Thu, 6 Dec 2012 15:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3wWCWF99BmH for ; Thu, 6 Dec 2012 15:21:13 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6949221F8618 for ; Thu, 6 Dec 2012 15:21:13 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.151.184]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB6NKvDq025238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 6 Dec 2012 15:21:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354836070; bh=h01KCpVQrkY9GTk/uJEb4cAvgdyawsd9CI4t0RDsf5c=; h=Date:To:From:Subject:Cc; b=mpADnxMUcBgXIphM+e7WpHyysplQDjaa2loHj+vQDnVdNEhpKFvfEvFW61UeDxOM0 8yd7g+bzyIOtEBtjSKIEemNI6P0Eb3IL9THrtCY/7xr+9hFM0s6DrVyuLagN6BUaGJ AF0K6KZZ+vHyzDluaZ0kyNeADf/X08dBT2CnVw/8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1354836070; i=@elandsys.com; bh=h01KCpVQrkY9GTk/uJEb4cAvgdyawsd9CI4t0RDsf5c=; h=Date:To:From:Subject:Cc; b=FBVxLYaNXM48id2GMXGtQZuc1IksB5v0QONGM0aUdTi1P6HMCOxDAgyO9uAlmjT+c 8uhpDud+ER49U83UkZ2b79+SSyTC2hWhTPfvgOXOOQJOM/MvDbNVpDYEOtUbAu0C+2 zkwfJ6nC/sOkeTNAzIIupkSE0gCVCpLwZLSVQRAE= Message-Id: <6.2.5.6.2.20121206151352.0ab29f80@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Dec 2012 15:20:21 -0800 To: spfbis@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_966143941==_" Subject: [spfbis] IETF85 SPFBIS minutes - Version 0.2 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 23:21:15 -0000 --=====================_966143941==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hello, Here are extended notes as minutes for IETF85 SPFBIS meeting. I'll be submitting for the proceedings tomorrow if there aren't any objections. Regards, S. Moonesamy SPFBIS WG co-chair --=====================_966143941==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="IETF85-SPFBIS-minutes.txt" SPF Update Working Group (SPFBIS) Minutes Meeting : IETF85, Thursday 8 November, 2012 Location: Room 209, Atlanta, 17:30 to 18:30 Chairs : Andrew Sullivan Minutes : John Levine Version 0.2 Audio: http://www.ietf.org/audio/ietf85/ietf85-209-20121108-1730-pm3.mp3 AGENDA For this meeting, we have only one agenda item: sort out what, if any, from the proposed reorganization we wish to adopt. An important and relevant mailing list thread starts at http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html The current WG draft is at http://tools.ietf.org/id/draft-ietf-spfbis-4408bis-08.txt A diff of the proposed changes is at http://www.blackops.org/~msk/spfbis/reorg.html Andrew Sullivan chaired the IETF85 SPFBIS Working Group meeting in Atlanta, U.S.A. John Levine was the minute-taker and Tim Draegen was the Jabber scribe. There were 17 people in the room. The Chair brought the new and improved version of the Note Well to the attention of the meeting participants, asked them to sign the blue sheets and bashed the agenda. Andrew Sullivan, as SPFBIS WG Chair, explained that the working group was having the meeting to discussed the proposal for reorganization of draft-ietf-spfbis-4408bis-08. He explained that the proposal seemed to have split the working group. A summary of the SPFBIS discussions about the proposal is available at http://www.ietf.org/mail-archive/web/spfbis/current/msg02962.html The Chair summarized the arguments for the reorganization: (a) People who are new to SPF will be able to follow the document. (b) It seems to be in line with some other standards which the IETF has produced and that will be important for passing the document through the IESG. (c) There was some concerns about some reorganizations in the original RFC The counter-arguments are: (a) When you move large chucks of text around there is a risk that the meaning could be changed. The argument was dismissed several times on the mailing list. The Chair urged people to take the argument seriously. He mentioned that the DNSEXT WG ran into a problem when it changed the meaning of something in a way which was significant to the protocol. (b) There are many successful implementations of SPF in the field and therefore there is no reason to change the format of the draft. (c) The working already has a draft on which it has been working on. The three questions to be considered at the meeting were: (a) What is the audience of the document? (b) What is the risk of backward compatibility issues if the document is reorganized; what is the risk that the working group will introduce an accidental change? (c) Will the consumers of the document be better served by the reorganized draft or the current working group draft? The Chair considered this question as the bottom line. Murray Kucherawy commented that he does not believe that the audience for the document is current implementers. He mentioned that as work builds up on DMARC there will be some new implementations. He believes that there was a tight-knit community when SPF was developed and that the community is smaller now. The quality of the document needs to be much higher because the audience is not the same as it used to be. He doesn't know how to measure the risk to backward compatibility. He pointed out that he did not face the problem with DKIM. The Chair suggested that one way to test for backward compatibility is to get somebody who has not implemented SPF before to test against the reorganized draft and see whether it is compatible with existing implementations. Scott Kitterman (attending remotely) would like to make sure that the working group is done with all reorganization questions and does not get derailed again. He mentioned that the SPF is still there and willing to help people out. He pointed out that Murray's draft also did some changes which was not just organizational. Murray Kucherawy agreed with Scott Kitterman and said that they have had a discussion about the matter. Dave Crocker thought that it was worth distinguishing between new implementers and new operators. He doesn't think that the document will be relevant to existing folks. He suggested moving the text around and snapshot it as an I-D so that it is in the record and then go and improve the language. He said that the comments about policy and mechanisms are standard examples of how the document may be confusing to the new consumers. Scott Kitterman commented that the working group agrees on structural changes and can check the details of textual changes later. Tim Draegen commented that the audience for the document are less technical experts and more folks that are coming on board and looking at SPF to deploy. As a trainer he would like to have a cleaner document that he can have his students look up. That is the primary audience in his opinion. He does not think that there is a risk of accidental changes as many people are paying attention to the draft now. The way to avoid that is to rely on reviewing on catching an mistakes. The Chair commented that it would be useful to point if there are any parts in the existing draft that would be problematic. It would then be possible to prioritize hich parts of the reorganized document is really important. Tim Draegen listed when does the HELO identifier come into play as an example. Dave Crocker relayed a comment from Kurt Andersen about a +1 for restructuring based on Tim Draegon's position statement re. educational usage. Scott Kitterman commented on Tim's point about the new people trying to figure out how to publish SPF records is an excellent one. It kind of convinced me that there is more of a new audience than I had anticipated before. John Levine commented that there are multiple audiences; one is the programmers who need to know how to build a SPF machine, take a record, process it and return a trinary result; the second audience is people sending mail and wanting to create correct SPF records; a third audience is people taking that trinary result and configure their mail servers to do something. The problem with the current draft is advice to their three groups are mixed together. He would like to separate the algorithmic part from the heuristics part which is basically about what to do with the result. The Chair asked whether there is still work to be done in respect to the reorganization. John Levine replied that he posted comments over a month ago and he does not remember. Alessandro Vesely agreed with what John Levine said. He pointed that there is a confusion about whether any advice in the document is given to the programmer or the configurator. Each implementation takes a different approach the whitelisting or the exclusion or whatever is needed to have SPF make sense. He would like to separate those parts. Alessandro Vesely commented on splitting the document into two separate documents which is the algorithmic and the publishing parts, and the receiver behavior. He asked whether that decision was expected to come out of the meeting. Scott Kitterman (via Jabber) said that if we can get consensus on one thing today, please can it be that we've done all the reorganizing/splitting we are going to do, so we can focus on getting whatever we are going to do done? The Chair stated that he would like the working group to come to agreement on which way it would like to go. Alessandro Vesely replied that he would like to see the document split in two. He mentioned that the original document pushes concepts without saying why and how. Murray Kucherawy mentioned that the reorganization makes it possible to split the document but he does not advocate either way. Chris (full name was not audible) said that the reorganization keeps the document the way a normal RFC reads and that it would be easier for somebody he brings on board his team to understand and discuss about the document. Kurt Andersen (via Jabber) said that unless it would help get through the approval process, I would advocate reorg without split. John Kelly considered the audience as being new implementers . Risk of backward incompatible changes do exist but he does not see a risk of backward incompatibility. He agreed with Chris about the reorganization. He said that he was 49 split versus 51 not split. He is okay with whatever helps the approval process; if it is a noop, he would go for leave the document intact just for referenceability. Pete Resnick, as Responsible Area Director, commented on the process question: so long as the working group gives him ammunition to fight silliness, he is not worried about getting through Last Call or the IESG Evaluation. He asked whether there is anything specific about the reorganized document which is concerning people. Andrew Sullivan put forward an argument that was made on the mailing list; the reorganization is an opportunity for people who have been trying to make changes to SPFBIS specification to sneak those changes in. He stated that there wasn't any pointer to any place where that has actually happened. He had to discount it as an actual problem as it was a change that he was unable to see. Pete Resnick stated that the comment made by Dave Crocker about doing the reorganization first and doing the changes after that would address the risk of changes being sneaked in. Scott Kitterman (via Jabber) stated that since the document editor is strongly opposed to making such changes, he thinks the risk of it is quite low. In his opinion it was clear that there is a strong lean towards the reorganization in the group and he is okay with that. He thinks that splitting is a bad idea for several reason. He also mentioned that Andrew's discussion of the DNS issue exemplifies one concern about a split. Currently, he has references to specific paragraphs about protocol, policy, and publishing. If it's split into two or more documents, then we lose those deep references and introduce risk of confusion. Scott Kitterman stated that if the consensus is to reorganize, then he is happy to review Murray's diff and make sure it doesn't introduce any inadvertent changes. The Chair, responding to a comment from Alessandro Vesely, mentioned that the idea of a comparison of the reorganized draft is to do a sanity check and any subsequent changes would be changes the working group did intentionally. Pete Resnick commented on the IESG having to review the iSCSI draft which was a 300 page monstrosity. Having the diff really made a different in that case. The working group is not in that situation. He stated that it is more important for the working group to convince itself that all things are good instead of being concerned about a violation in the SPFBIS charter which restricts changes that can be made to the document. John Levine commented that he is okay with not splitting the document. The Chair stated that his impression after hearing the comments about the first question is that the working group has a pretty broad audience for the document. In response to the second question the working group seems to have some procedures to minimize the risk of changes and those sound like they are going to be acceptable. His sense of the room about the third question is that there is a desire to do the reorganization. The Chair asked two questions to take a sense of the room: (i) support for reorganization (ii) not support the reorganization The Chair stated that what he heard from the hums in very support for the reorganization and no opposition. That will be confirmed on the SPFBIS mailing list. Scott Kitterman (via Jabber) mentioned that he is willing to concede the point now (and I wasn't before). The Chair took a hum about: (i) splitting the document (ii) opposed to splitting the document The Chair heard at least two hums in favor of splitting the document. The Chair mentioned that there does not seem to be a strong opinion one way or the other. It was also mentioned that the input from Jabber pointed to people being opposed to splitting the document. The answer is not to split the document. Alessandro Vesely commented that there is no specification for receiver behavior. Murray Kucherawy commented that the idea of a second document was: here is what you do with a "pass", here is what we think you are supposed to do with a "fail". He mentioned that there was now obvious resistance to that and he didn't want to get into all the arguments. The Chair took another hum about splitting the document in light of the new arguments which were made: (i) all those in favor of splitting the document (ii) all of those opposed to splitting the document He stated that he heard approximately even in the room for the two options and that, in Jabber, there were nobody in favor and people opposed. The Chair stated for the minutes that the working group will be doing the reorganization but it is not planning to split the document. This will be taken to the mailing list for confirmation. Murray Kucherawy and Scott Kitterman will collaborate on an updated document taking into account the intermediate steps to do the comparison in case anybody gives the working group a hard time later. The Chair asked whether that seems what the working group agreed to today and nobody said no. Pete Resnick, as Responsible Area Director, asked to put the question to the mailing list and ask people to state their objections if they are in favor of a split. Dave Crocker commented that it was unncessary. The Chair, in reply to a comment from Scott Kitterman, commented that the plan is to send a note to the mailing list that outlines the intermediate steps and who is going to take them. Under Any Other Business, Alessandro Vesely had a question about DMARC not to be discussed in the IETF. The question was not discussed further as it was not SPFBIS business. Andrew Sullivan thanked the working group for the productive meeting. The meeting was adjourned at 6:29 p.m. --=====================_966143941==_-- From spf2@kitterman.com Thu Dec 6 18:32:41 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F66221F857C for ; Thu, 6 Dec 2012 18:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A98lLJkF8v7K for ; Thu, 6 Dec 2012 18:32:40 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 88D1E21F8575 for ; Thu, 6 Dec 2012 18:32:40 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 3EBCF20E4106; Thu, 6 Dec 2012 21:32:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1354847559; bh=YsRIwnqVU8A8L5B+h/vANwQm5/t2KCbV17XIwm62DZ4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=TTqp9Ximrhs9dRtabQz8+cNifXEn/hapdwai04Q4B6X6mdcI4983HVVymPjfMaZTW zm9cmPKNpKs2mQvjPbHUPiOf5Lob07JcsJC55XLYSLi/SBRKoqxnuVxWoKM3m74Wtw QB0ljqb+y8asrBH028SWLqRVB8jeAg4Blq//hxMk= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 118AF20E407B; Thu, 6 Dec 2012 21:32:38 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 06 Dec 2012 21:32:38 -0500 Message-ID: <4434978.pxJ5BSAW5e@scott-latitude-e6320> User-Agent: KMail/4.9.3 (Linux/3.5.0-19-generic; KDE/4.9.3; i686; ; ) In-Reply-To: <6.2.5.6.2.20121206151352.0ab29f80@elandnews.com> References: <6.2.5.6.2.20121206151352.0ab29f80@elandnews.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] IETF85 SPFBIS minutes - Version 0.2 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 02:32:41 -0000 On Thursday, December 06, 2012 03:20:21 PM S Moonesamy wrote: > Hello, > > Here are extended notes as minutes for IETF85 SPFBIS meeting. I'll > be submitting for the proceedings tomorrow if there aren't any objections. > > Regards, > S. Moonesamy > SPFBIS WG co-chair There are a couple of points that I noticed change to first person: > Scott Kitterman commented on Tim's point about the new people trying to > figure out how to publish SPF records is an excellent one. It kind of > convinced me that there is more of a new audience than I had anticipated > before. ... > Scott Kitterman (via Jabber) mentioned that he is willing to concede the > point now (and I wasn't before). I think these should be changed to fit in better with the rest of the document: > Scott Kitterman commented on Tim's point about the new people trying to > figure out how to publish SPF recordsis an excellent one. It kind of > convinced him that there is more of a new audience than he had anticipated > before. ... > Scott Kitterman (via Jabber) mentioned that he is willing to concede the > point now (and wasn't before). The rest looks good. Scott K From sm@elandsys.com Thu Dec 6 22:08:56 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C24621F882D for ; Thu, 6 Dec 2012 22:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KsOkAiyh3vH for ; Thu, 6 Dec 2012 22:08:55 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0E621F8801 for ; Thu, 6 Dec 2012 22:08:54 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.151.184]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB768bNd017603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2012 22:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354860531; bh=xq3yvnixUuYPc4auyQ0BQ+5II6gTQUhj/bxG5da4tM8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vioNdmul7U6F9ud1fVCbb4NN/QTHzkGZFLmIqCuENczgXXjFjpOQzZkNqdWB8wjJn STwKuQrgA7ebkQHehsH8ztbHWw/kJJWpBbVvAxNMQ3W9r4MnQPuJqH0KWrEwW755kt u5XVfdbkrGtKe67Opi+N8Ne5tVhhPZnwSUib8PYA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1354860531; i=@elandsys.com; bh=xq3yvnixUuYPc4auyQ0BQ+5II6gTQUhj/bxG5da4tM8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=KPfQdYgBtfVdnmxooJXrNNFkJ9sT1Y2IothBV8bF2ZoR0Y5g1+0++xZ+TW2Xi1FrJ EmFBCOvt9y5q+bIgzOByaZlYOmhwbhq9lxzPzZWHRUMDulavAXxaA56ltOHU6jdz6z wgPbcrJtiuKcNTVsie9pp5td9wCJpr3753WwORXs= Message-Id: <6.2.5.6.2.20121206214436.0a4a88f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 06 Dec 2012 22:07:11 -0800 To: Scott Kitterman From: S Moonesamy In-Reply-To: <4434978.pxJ5BSAW5e@scott-latitude-e6320> References: <6.2.5.6.2.20121206151352.0ab29f80@elandnews.com> <4434978.pxJ5BSAW5e@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] IETF85 SPFBIS minutes - Version 0.2 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 06:08:56 -0000 Hi Scott, At 18:32 06-12-2012, Scott Kitterman wrote: >There are a couple of points that I noticed change to first person: Thanks, I missed those. >I think these should be changed to fit in better with the rest of >the document: > > > Scott Kitterman commented on Tim's point about the new people trying to > > figure out how to publish SPF recordsis an excellent one. It kind of > > convinced him that there is more of a new audience than he had anticipated > > before. I merged the two paragraph as suggested above. Regards, S. Moonesamy From vesely@tana.it Fri Dec 7 03:55:45 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612AD21F86E9 for ; Fri, 7 Dec 2012 03:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecbNKTt0BSw0 for ; Fri, 7 Dec 2012 03:55:44 -0800 (PST) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9368921F8717 for ; Fri, 7 Dec 2012 03:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1354881341; bh=a824YPl5xjaE4nopFiMMp61WNOUShrvVVH9MQriLiLI=; l=11545; h=Date:From:To:References:In-Reply-To; b=NNrxPl5cSw3aO5oanHENGZ2LR6AYM2kvQ1l2iYijwLEtLfXHqSmmuGYFFwuvoZxmn UFjabqP/gWCifeJjGEFNEdTUQgtCDuyJGH9iYQdHw60miYA8Vv6Ox6zLDvom5RwI2L RmNZVEpidKSs3eZWB4PCCSUQnqWd1AqF1vQxYZV8= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Fri, 07 Dec 2012 12:55:40 +0100 id 00000000005DC035.0000000050C1D93D.00004236 Message-ID: <50C1D93C.1010000@tana.it> Date: Fri, 07 Dec 2012 12:55:40 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_north-16950-1354881341-0001-2" To: spfbis@ietf.org References: <6.2.5.6.2.20121206151352.0ab29f80@elandnews.com> In-Reply-To: <6.2.5.6.2.20121206151352.0ab29f80@elandnews.com> Subject: Re: [spfbis] IETF85 SPFBIS minutes - Version 0.2 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 11:55:45 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_north-16950-1354881341-0001-2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Fri 07/Dec/2012 00:20:21 +0100 S Moonesamy wrote: > > Here are extended notes as minutes for IETF85 SPFBIS meeting. I'll be > submitting for the proceedings tomorrow if there aren't any objections. I'd propose a few changes, if you think any of them can make the document better. --=_north-16950-1354881341-0001-2 Content-Type: text/plain; charset=windows-1252; name="IETF85-SPFBIS-minutes.patch.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="IETF85-SPFBIS-minutes.patch.txt" LS0tIElFVEY4NS1TUEZCSVMtbWludXRlcy50eHQJRnJpIERlYyAwNyAxMDo0MDoxOCAyMDEy DQorKysgSUVURjg1LVNQRkJJUy1taW51dGVzLW5pdHMudHh0CUZyaSBEZWMgMDcgMTI6NTE6 NDkgMjAxMg0KQEAgLTMxLDcgKzMxLDcgQEANCiBhbmQgYmFzaGVkIHRoZSBhZ2VuZGEuDQog DQogQW5kcmV3IFN1bGxpdmFuLCBhcyBTUEZCSVMgV0cgQ2hhaXIsIGV4cGxhaW5lZCB0aGF0 IHRoZSB3b3JraW5nIGdyb3VwIHdhcw0KLWhhdmluZyB0aGUgbWVldGluZyB0byBkaXNjdXNz ZWQgdGhlIHByb3Bvc2FsIGZvciByZW9yZ2FuaXphdGlvbiBvZg0KK2hhdmluZyB0aGUgbWVl dGluZyB0byBkaXNjdXNzIHRoZSBwcm9wb3NhbCBmb3IgcmVvcmdhbml6YXRpb24gb2YNCiBk cmFmdC1pZXRmLXNwZmJpcy00NDA4YmlzLTA4LiAgSGUgZXhwbGFpbmVkIHRoYXQgdGhlIHBy b3Bvc2FsIHNlZW1lZCB0byBoYXZlDQogc3BsaXQgdGhlIHdvcmtpbmcgZ3JvdXAuICBBIHN1 bW1hcnkgb2YgdGhlIFNQRkJJUyBkaXNjdXNzaW9ucyBhYm91dCB0aGUNCiBwcm9wb3NhbCBp cyBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Nw ZmJpcy9jdXJyZW50L21zZzAyOTYyLmh0bWwNCkBAIC00NSw3ICs0NSw3IEBADQogICAgICB0 aHJvdWdoIHRoZSBJRVNHLg0KIA0KICAoYykgVGhlcmUgd2FzIHNvbWUgY29uY2VybnMgYWJv dXQgc29tZSByZW9yZ2FuaXphdGlvbnMgaW4gdGhlIG9yaWdpbmFsDQotICAgICBSRkMNCisg ICAgIFJGQy4NCiANCiBUaGUgY291bnRlci1hcmd1bWVudHMgYXJlOg0KIA0KQEAgLTg4LDE3 ICs4OCwxOCBAQA0KIA0KIFNjb3R0IEtpdHRlcm1hbiAoYXR0ZW5kaW5nIHJlbW90ZWx5KSB3 b3VsZCBsaWtlIHRvIG1ha2Ugc3VyZSB0aGF0IHRoZSB3b3JraW5nDQogZ3JvdXAgaXMgZG9u ZSB3aXRoIGFsbCByZW9yZ2FuaXphdGlvbiBxdWVzdGlvbnMgYW5kIGRvZXMgbm90IGdldCBk ZXJhaWxlZA0KLWFnYWluLiAgSGUgbWVudGlvbmVkIHRoYXQgdGhlIFNQRiBpcyBzdGlsbCB0 aGVyZSBhbmQgd2lsbGluZyB0byBoZWxwIHBlb3BsZQ0KLW91dC4gIEhlIHBvaW50ZWQgb3V0 IHRoYXQgTXVycmF5J3MgZHJhZnQgYWxzbyBkaWQgc29tZSBjaGFuZ2VzIHdoaWNoIHdhcyBu b3QNCi1qdXN0IG9yZ2FuaXphdGlvbmFsLiAgTXVycmF5IEt1Y2hlcmF3eSBhZ3JlZWQgd2l0 aCBTY290dCBLaXR0ZXJtYW4gYW5kIHNhaWQNCi10aGF0IHRoZXkgaGF2ZSBoYWQgYSBkaXNj dXNzaW9uIGFib3V0IHRoZSBtYXR0ZXIuDQorYWdhaW4uICBIZSBtZW50aW9uZWQgdGhhdCB0 aGUgU1BGIGNvbW11bml0eSBpcyBzbWFsbGVyIGJ1dCBpcyBzdGlsbCB0aGVyZSBhbmQNCit3 aWxsaW5nIHRvIGhlbHAgcGVvcGxlIG91dC4gIEhlIHBvaW50ZWQgb3V0IHRoYXQgTXVycmF5 J3MgZHJhZnQgYWxzbyBkaWQgc29tZQ0KK2NoYW5nZXMgd2hpY2ggd2FzIG5vdCBqdXN0IG9y Z2FuaXphdGlvbmFsLiAgTXVycmF5IEt1Y2hlcmF3eSBhZ3JlZWQgd2l0aCBTY290dA0KK0tp dHRlcm1hbiBhbmQgc2FpZCB0aGF0IHRoZXkgaGF2ZSBoYWQgYSBkaXNjdXNzaW9uIGFib3V0 IHRoZSBtYXR0ZXIuDQogDQogRGF2ZSBDcm9ja2VyIHRob3VnaHQgdGhhdCBpdCB3YXMgd29y dGggZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBuZXcgaW1wbGVtZW50ZXJzDQogYW5kIG5ldyBv cGVyYXRvcnMuICBIZSBkb2Vzbid0IHRoaW5rIHRoYXQgdGhlIGRvY3VtZW50IHdpbGwgYmUg cmVsZXZhbnQgdG8NCiBleGlzdGluZyBmb2xrcy4gIEhlIHN1Z2dlc3RlZCBtb3ZpbmcgdGhl IHRleHQgYXJvdW5kIGFuZCBzbmFwc2hvdCBpdCBhcyBhbiBJLUQNCiBzbyB0aGF0IGl0IGlz IGluIHRoZSByZWNvcmQgYW5kIHRoZW4gZ28gYW5kIGltcHJvdmUgdGhlIGxhbmd1YWdlLiAg SGUgc2FpZA0KLXRoYXQgdGhlIGNvbW1lbnRzIGFib3V0IHBvbGljeSBhbmQgbWVjaGFuaXNt cyBhcmUgc3RhbmRhcmQgZXhhbXBsZXMgb2YgaG93DQotdGhlIGRvY3VtZW50IG1heSBiZSBj b25mdXNpbmcgdG8gdGhlIG5ldyBjb25zdW1lcnMuDQordGhhdCB0aGlnbnMgbGlrZSBjb25m bGF0aW5nIHBvbGljeSB3aXRoIG1lY2hhbmlzbXMgYXJlIHN0YW5kYXJkIGV4YW1wbGVzIG9m IGhvdw0KK3RoZSBkb2N1bWVudCBtYXkgYmUgY29uZnVzaW5nIHRvIGF2ZXJhZ2UgbmV3IHJl YWRlcnM6ICBTdHJ1Y3R1cmFsIGNsYXJpdHkgc2VlbXMNCit0byBtYWtlIGFuIGVub3Jtb3Vz IGRpZmZlcmVuY2UgdG8gdGhhdC4NCiANCiBTY290dCBLaXR0ZXJtYW4gY29tbWVudGVkIHRo YXQgdGhlIHdvcmtpbmcgZ3JvdXAgYWdyZWVzIG9uIHN0cnVjdHVyYWwgY2hhbmdlcw0KIGFu ZCBjYW4gY2hlY2sgdGhlIGRldGFpbHMgb2YgdGV4dHVhbCBjaGFuZ2VzIGxhdGVyLg0KQEAg LTEwOSwxNCArMTEwLDE0IEBADQogc3R1ZGVudHMgbG9vayB1cC4gIFRoYXQgaXMgdGhlIHBy aW1hcnkgYXVkaWVuY2UgaW4gaGlzIG9waW5pb24uICBIZSBkb2VzIG5vdA0KIHRoaW5rIHRo YXQgdGhlcmUgaXMgYSByaXNrIG9mIGFjY2lkZW50YWwgY2hhbmdlcyBhcyBtYW55IHBlb3Bs ZSBhcmUgcGF5aW5nDQogYXR0ZW50aW9uIHRvIHRoZSBkcmFmdCBub3cuICBUaGUgd2F5IHRv IGF2b2lkIHRoYXQgaXMgdG8gcmVseSBvbiByZXZpZXdpbmcNCi1vbiBjYXRjaGluZyBhbiBt aXN0YWtlcy4gIFRoZSBDaGFpciBjb21tZW50ZWQgdGhhdCBpdCB3b3VsZCBiZSB1c2VmdWwg dG8gcG9pbnQNCit0byBjYXRjaCBhbnkgbWlzdGFrZXMuICBUaGUgQ2hhaXIgY29tbWVudGVk IHRoYXQgaXQgd291bGQgYmUgdXNlZnVsIHRvIHBvaW50DQogaWYgdGhlcmUgYXJlIGFueSBw YXJ0cyBpbiB0aGUgZXhpc3RpbmcgZHJhZnQgdGhhdCB3b3VsZCBiZSBwcm9ibGVtYXRpYy4N Ci1JdCB3b3VsZCB0aGVuIGJlIHBvc3NpYmxlIHRvIHByaW9yaXRpemUgaGljaCBwYXJ0cyBv ZiB0aGUgcmVvcmdhbml6ZWQgZG9jdW1lbnQNCitJdCB3b3VsZCB0aGVuIGJlIHBvc3NpYmxl IHRvIHByaW9yaXRpemUgd2hpY2ggcGFydHMgb2YgdGhlIHJlb3JnYW5pemVkIGRvY3VtZW50 DQogaXMgcmVhbGx5IGltcG9ydGFudC4gIFRpbSBEcmFlZ2VuIGxpc3RlZCB3aGVuIGRvZXMg dGhlIEhFTE8gaWRlbnRpZmllciBjb21lDQogaW50byBwbGF5IGFzIGFuIGV4YW1wbGUuDQog DQogRGF2ZSBDcm9ja2VyIHJlbGF5ZWQgYSBjb21tZW50IGZyb20gS3VydCBBbmRlcnNlbiBh Ym91dCBhICsxIGZvciByZXN0cnVjdHVyaW5nDQotYmFzZWQgb24gVGltIERyYWVnb24ncyBw b3NpdGlvbiBzdGF0ZW1lbnQgcmUuIGVkdWNhdGlvbmFsIHVzYWdlLg0KK2Jhc2VkIG9uIFRp bSBEcmFlZ29uJ3MgcG9zaXRpb24gc3RhdGVtZW50IHJlbGF0ZWQgdG8gZWR1Y2F0aW9uYWwg dXNhZ2UuDQogDQogU2NvdHQgS2l0dGVybWFuIGNvbW1lbnRlZCBvbiBUaW0ncyBwb2ludCBh Ym91dCB0aGUgbmV3IHBlb3BsZSB0cnlpbmcgdG8gZmlndXJlDQogb3V0IGhvdyB0byBwdWJs aXNoIFNQRiByZWNvcmRzIGlzIGFuIGV4Y2VsbGVudCBvbmUuICBJdCBraW5kIG9mIGNvbnZp bmNlZCBtZSB0aGF0DQpAQCAtMTI3LDcgKzEyOCw3IEBADQogcmV0dXJuIGEgdHJpbmFyeSBy ZXN1bHQ7IHRoZSBzZWNvbmQgYXVkaWVuY2UgaXMgcGVvcGxlIHNlbmRpbmcgbWFpbCBhbmQg d2FudGluZw0KIHRvIGNyZWF0ZSBjb3JyZWN0IFNQRiByZWNvcmRzOyBhIHRoaXJkIGF1ZGll bmNlIGlzIHBlb3BsZSB0YWtpbmcgdGhhdCB0cmluYXJ5DQogcmVzdWx0IGFuZCBjb25maWd1 cmUgdGhlaXIgbWFpbCBzZXJ2ZXJzIHRvIGRvIHNvbWV0aGluZy4gIFRoZSBwcm9ibGVtIHdp dGggdGhlDQotY3VycmVudCBkcmFmdCBpcyBhZHZpY2UgdG8gdGhlaXIgdGhyZWUgZ3JvdXBz IGFyZSBtaXhlZCB0b2dldGhlci4gIEhlIHdvdWxkDQorY3VycmVudCBkcmFmdCBpcyBhZHZp Y2UgdG8gdGhvc2UgdGhyZWUgZ3JvdXBzIGFyZSBtaXhlZCB0b2dldGhlci4gIEhlIHdvdWxk DQogbGlrZSB0byBzZXBhcmF0ZSB0aGUgYWxnb3JpdGhtaWMgcGFydCBmcm9tIHRoZSBoZXVy aXN0aWNzIHBhcnQgd2hpY2ggaXMNCiBiYXNpY2FsbHkgYWJvdXQgd2hhdCB0byBkbyB3aXRo IHRoZSByZXN1bHQuICBUaGUgQ2hhaXIgYXNrZWQgd2hldGhlciB0aGVyZSBpcw0KIHN0aWxs IHdvcmsgdG8gYmUgZG9uZSBpbiByZXNwZWN0IHRvIHRoZSByZW9yZ2FuaXphdGlvbi4gIEpv aG4gTGV2aW5lIHJlcGxpZWQNCkBAIC0xNDcsOCArMTQ4LDkgQEANCiBnb2luZyB0byBkbywg c28gd2UgY2FuIGZvY3VzIG9uIGdldHRpbmcgd2hhdGV2ZXIgd2UgYXJlIGdvaW5nIHRvIGRv IGRvbmU/ICBUaGUNCiBDaGFpciBzdGF0ZWQgdGhhdCBoZSB3b3VsZCBsaWtlIHRoZSB3b3Jr aW5nIGdyb3VwIHRvIGNvbWUgdG8gYWdyZWVtZW50IG9uIHdoaWNoDQogd2F5IGl0IHdvdWxk IGxpa2UgdG8gZ28uICBBbGVzc2FuZHJvIFZlc2VseSByZXBsaWVkIHRoYXQgaGUgd291bGQg bGlrZSB0byBzZWUNCi10aGUgZG9jdW1lbnQgc3BsaXQgaW4gdHdvLiAgSGUgbWVudGlvbmVk IHRoYXQgdGhlIG9yaWdpbmFsIGRvY3VtZW50IHB1c2hlcw0KLWNvbmNlcHRzIHdpdGhvdXQg c2F5aW5nIHdoeSBhbmQgaG93Lg0KK3RoZSBkb2N1bWVudCBzcGxpdCBpbiB0d28sIGV2ZW4g aWYgdGhhdCBpcyBtb3JlIGRpZmZpY3VsdCBhcyBpdCByZXF1aXJlcyB0bw0KK2ludGVycHJl dCBjb25jZXB0cyB0aGF0IHRoZSBvcmlnaW5hbCBkb2N1bWVudCBwdXNoZXMgd2l0aG91dCBz YXlpbmcgd2h5IGFuZA0KK2hvdy4NCiANCiBNdXJyYXkgS3VjaGVyYXd5IG1lbnRpb25lZCB0 aGF0IHRoZSByZW9yZ2FuaXphdGlvbiBtYWtlcyBpdCBwb3NzaWJsZSB0byBzcGxpdA0KIHRo ZSBkb2N1bWVudCBidXQgaGUgZG9lcyBub3QgYWR2b2NhdGUgZWl0aGVyIHdheS4NCkBAIC0x NTcsOCArMTU5LDggQEANCiBkb2N1bWVudCB0aGUgd2F5IGEgbm9ybWFsIFJGQyByZWFkcyBh bmQgdGhhdCBpdCB3b3VsZCBiZSBlYXNpZXIgZm9yDQogc29tZWJvZHkgaGUgYnJpbmdzIG9u IGJvYXJkIGhpcyB0ZWFtIHRvIHVuZGVyc3RhbmQgYW5kIGRpc2N1c3MgYWJvdXQgdGhlDQog ZG9jdW1lbnQuICBLdXJ0IEFuZGVyc2VuICh2aWEgSmFiYmVyKSBzYWlkIHRoYXQgdW5sZXNz IGl0IHdvdWxkIGhlbHAgZ2V0DQotdGhyb3VnaCB0aGUgYXBwcm92YWwgcHJvY2VzcywgSSB3 b3VsZCBhZHZvY2F0ZSByZW9yZyB3aXRob3V0IHNwbGl0LiBKb2huIEtlbGx5DQotY29uc2lk ZXJlZCB0aGUgYXVkaWVuY2UgYXMgYmVpbmcgbmV3IGltcGxlbWVudGVycyAuICBSaXNrIG9m IGJhY2t3YXJkDQordGhyb3VnaCB0aGUgYXBwcm92YWwgcHJvY2VzcywgSSB3b3VsZCBhZHZv Y2F0ZSByZW9yZyB3aXRob3V0IHNwbGl0LiAgSm9obg0KK0tlbGx5IGNvbnNpZGVyZWQgdGhl IGF1ZGllbmNlIGFzIGJlaW5nIG5ldyBpbXBsZW1lbnRlcnMuICBSaXNrIG9mIGJhY2t3YXJk DQogaW5jb21wYXRpYmxlIGNoYW5nZXMgZG8gZXhpc3QgYnV0IGhlIGRvZXMgbm90IHNlZSBh IHJpc2sgb2YgYmFja3dhcmQNCiBpbmNvbXBhdGliaWxpdHkuICBIZSBhZ3JlZWQgd2l0aCBD aHJpcyBhYm91dCB0aGUgcmVvcmdhbml6YXRpb24uICBIZSBzYWlkIHRoYXQNCiBoZSB3YXMg NDkgc3BsaXQgdmVyc3VzIDUxIG5vdCBzcGxpdC4gIEhlIGlzIG9rYXkgd2l0aCB3aGF0ZXZl ciBoZWxwcyB0aGUNCkBAIC0xOTQsMTEgKzE5NiwxNCBAQA0KIGFueSBzdWJzZXF1ZW50IGNo YW5nZXMgd291bGQgYmUgY2hhbmdlcyB0aGUgd29ya2luZyBncm91cCBkaWQgaW50ZW50aW9u YWxseS4NCiANCiBQZXRlIFJlc25pY2sgY29tbWVudGVkIG9uIHRoZSBJRVNHIGhhdmluZyB0 byByZXZpZXcgdGhlIGlTQ1NJIGRyYWZ0IHdoaWNoIHdhcw0KLWEgMzAwIHBhZ2UgbW9uc3Ry b3NpdHkuICBIYXZpbmcgdGhlIGRpZmYgcmVhbGx5IG1hZGUgYSBkaWZmZXJlbnQgaW4gdGhh dCBjYXNlLg0KK2EgMzAwIHBhZ2UgbW9uc3Ryb3NpdHkuICBIYXZpbmcgdGhlIGRpZmYsIHRh a2VuIGFmdGVyIHJlc2h1ZmZsaW5nIHBhcmFncmFwaHMgb2YNCit0aGUgb3JpZ2luYWwgUkZD IHNvIHRoYXQgdGhleSBtYXRjaGVkLCByZWFsbHkgbWFkZSBhIGRpZmZlcmVuY2UgaW4gdGhh dCBjYXNlLg0KIFRoZSB3b3JraW5nIGdyb3VwIGlzIG5vdCBpbiB0aGF0IHNpdHVhdGlvbi4g IEhlIHN0YXRlZCB0aGF0IGl0IGlzIG1vcmUNCiBpbXBvcnRhbnQgZm9yIHRoZSB3b3JraW5n IGdyb3VwIHRvIGNvbnZpbmNlIGl0c2VsZiB0aGF0IGFsbCB0aGluZ3MgYXJlIGdvb2QNCiBp bnN0ZWFkIG9mIGJlaW5nIGNvbmNlcm5lZCBhYm91dCBhIHZpb2xhdGlvbiBpbiB0aGUgU1BG QklTIGNoYXJ0ZXIgd2hpY2gNCi1yZXN0cmljdHMgY2hhbmdlcyB0aGF0IGNhbiBiZSBtYWRl IHRvIHRoZSBkb2N1bWVudC4NCityZXN0cmljdHMgY2hhbmdlcyB0aGF0IGNhbiBiZSBtYWRl IHRvIHRoZSBkb2N1bWVudC4gIFRoZSBDaGFpciBhZ3JlZWQgdGhhdA0KK3RoZXJlIGlzIGEg dmFsdWUgaW4gZG9jdW1lbnRpbmcgdGhlIGNoYW5nZXMsIGFzIHRoZSBXRyBpcyBjaGFydGVy ZWQgdG8gbm90DQorYWx0ZXIgdGhlIHNwZWNpZmljYXRpb24gYW5kIG1pZ2h0IGJlIGFza2Vk IHRvIHByb3ZlIHRoYXQgaXQgYWN0dWFsbHkgZGlkbid0Lg0KIA0KIEpvaG4gTGV2aW5lIGNv bW1lbnRlZCB0aGF0IGhlIGlzIG9rYXkgd2l0aCBub3Qgc3BsaXR0aW5nIHRoZSBkb2N1bWVu dC4NCiANCkBAIC0yMzMsOSArMjM4LDkgQEANCiBwZW9wbGUgYmVpbmcgb3Bwb3NlZCB0byBz cGxpdHRpbmcgdGhlIGRvY3VtZW50LiAgVGhlIGFuc3dlciBpcyBub3QgdG8NCiBzcGxpdCB0 aGUgZG9jdW1lbnQuDQogDQotQWxlc3NhbmRybyBWZXNlbHkgY29tbWVudGVkIHRoYXQgdGhl cmUgaXMgbm8gc3BlY2lmaWNhdGlvbiBmb3IgcmVjZWl2ZXINCi1iZWhhdmlvci4gIE11cnJh eSBLdWNoZXJhd3kgY29tbWVudGVkIHRoYXQgdGhlIGlkZWEgb2YgYSBzZWNvbmQgZG9jdW1l bnQNCi13YXM6IGhlcmUgaXMgd2hhdCB5b3UgZG8gd2l0aCBhICJwYXNzIiwgaGVyZSBpcyB3 aGF0IHdlIHRoaW5rIHlvdSBhcmUNCitBbGVzc2FuZHJvIFZlc2VseSBjb21tZW50ZWQgdGhh dCBhbiBBUyBmb3IgcmVjZWl2ZXIgYmVoYXZpb3Igc2hvdWxkIGJlDQorZXhwZXJpbWVudGFs LCBjdXJyZW50bHkuICBNdXJyYXkgS3VjaGVyYXd5IGNvbW1lbnRlZCB0aGF0IHRoZSBpZGVh IG9mIGEgc2Vjb25kDQorZG9jdW1lbnQgd2FzOiBoZXJlIGlzIHdoYXQgeW91IGRvIHdpdGgg YSAicGFzcyIsIGhlcmUgaXMgd2hhdCB3ZSB0aGluayB5b3UgYXJlDQogc3VwcG9zZWQgdG8g ZG8gd2l0aCBhICJmYWlsIi4gIEhlIG1lbnRpb25lZCB0aGF0IHRoZXJlIHdhcyBub3cgb2J2 aW91cw0KIHJlc2lzdGFuY2UgdG8gdGhhdCBhbmQgaGUgZGlkbid0IHdhbnQgdG8gZ2V0IGlu dG8gYWxsIHRoZSBhcmd1bWVudHMuDQogDQpAQCAtMjU5LDcgKzI2NCw3IEBADQogDQogUGV0 ZSBSZXNuaWNrLCBhcyBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yLCBhc2tlZCB0byBwdXQg dGhlIHF1ZXN0aW9uIHRvIHRoZQ0KIG1haWxpbmcgbGlzdCBhbmQgYXNrIHBlb3BsZSB0byBz dGF0ZSB0aGVpciBvYmplY3Rpb25zIGlmIHRoZXkgYXJlIGluIGZhdm9yIG9mDQotYSBzcGxp dC4gIERhdmUgQ3JvY2tlciBjb21tZW50ZWQgdGhhdCBpdCB3YXMgdW5uY2Vzc2FyeS4NCith IHNwbGl0LiAgRGF2ZSBDcm9ja2VyIGNvbW1lbnRlZCB0aGF0IGl0IGlzIHVubmVjZXNzYXJ5 Lg0KIA0KIFRoZSBDaGFpciwgaW4gcmVwbHkgdG8gYSBjb21tZW50IGZyb20gU2NvdHQgS2l0 dGVybWFuLCBjb21tZW50ZWQgdGhhdCB0aGUNCiBwbGFuIGlzIHRvIHNlbmQgYSBub3RlIHRv IHRoZSBtYWlsaW5nIGxpc3QgdGhhdCBvdXRsaW5lcyB0aGUgaW50ZXJtZWRpYXRlDQo= --=_north-16950-1354881341-0001-2-- From sm@elandsys.com Fri Dec 7 07:33:31 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38B121F8AEC for ; Fri, 7 Dec 2012 07:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4Wj4n7WfMMM for ; Fri, 7 Dec 2012 07:33:29 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E44921F8A7C for ; Fri, 7 Dec 2012 07:33:29 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.129.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB7FXC89015423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2012 07:33:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354894406; bh=jdtZ38v4C59qR1pAnEmBcOaKIHi8ySWcoJ/3Tni3jYM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=VR+8dO7ntfYZF8h8VaqGMoLNOBccYudGaBWwARiCzWsBFn63pn4H2jZR1pZY+GQa3 Ej0ZCkGxxJsFzZxCTOClnURUWqKL9L1ASjz9aLD2L7za3GJadmiz0eA21mrluhJ+yy JW5puuX242xc9b1om9fnQI4S9NymiUKIPIyAMOss= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1354894406; i=@elandsys.com; bh=jdtZ38v4C59qR1pAnEmBcOaKIHi8ySWcoJ/3Tni3jYM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ioUn3PDe8F/CMfywbv1mv3AZqld0fmjdSqDKyBAzckHpQbHdFy8UoS7JznaXyQUSP cd9rywqw88Ilhp/NIA6ad6BLZMYAm9V6RM7Hh9oyDIy1toGo8TkeDNWU95Ad5uV43O bekqET6dAI+k7lhaPNwxqkccv4OIwsWupanXkmgU= Message-Id: <6.2.5.6.2.20121207071751.0ad08498@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Dec 2012 07:22:48 -0800 To: Alessandro Vesely From: S Moonesamy In-Reply-To: <50C1D93C.1010000@tana.it> References: <6.2.5.6.2.20121206151352.0ab29f80@elandnews.com> <50C1D93C.1010000@tana.it> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_1024479891==_" Cc: spfbis@ietf.org Subject: [spfbis] IETF85 SPFBIS minutes - Version 0.3 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:33:31 -0000 --=====================_1024479891==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Alessandro, At 03:55 07-12-2012, Alessandro Vesely wrote: >I'd propose a few changes, if you think any of them can make the >document better. Thanks, I applied all your changes with one or two minor edits. I am attaching version 0.3. I'll upload this version by the end of the day (UTC). Regards, S. Moonesamy --=====================_1024479891==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="IETF85-SPFBIS-minutes.txt" SPF Update Working Group (SPFBIS) Minutes Meeting : IETF85, Thursday 8 November, 2012 Location: Room 209, Atlanta, 17:30 to 18:30 Chairs : Andrew Sullivan Minutes : John Levine Version 0.3 Audio: http://www.ietf.org/audio/ietf85/ietf85-209-20121108-1730-pm3.mp3 AGENDA For this meeting, we have only one agenda item: sort out what, if any, from the proposed reorganization we wish to adopt. An important and relevant mailing list thread starts at http://www.ietf.org/mail-archive/web/spfbis/current/msg02872.html The current WG draft is at http://tools.ietf.org/id/draft-ietf-spfbis-4408bis-08.txt A diff of the proposed changes is at http://www.blackops.org/~msk/spfbis/reorg.html Andrew Sullivan chaired the IETF85 SPFBIS Working Group meeting in Atlanta, U.S.A. John Levine was the minute-taker and Tim Draegen was the Jabber scribe. There were 17 people in the room. The Chair brought the new and improved version of the Note Well to the attention of the meeting participants, asked them to sign the blue sheets and bashed the agenda. Andrew Sullivan, as SPFBIS WG Chair, explained that the working group was having the meeting to discuss the proposal for reorganization of draft-ietf-spfbis-4408bis-08. He explained that the proposal seemed to have split the working group. A summary of the SPFBIS discussions about the proposal is available at http://www.ietf.org/mail-archive/web/spfbis/current/msg02962.html The Chair summarized the arguments for the reorganization: (a) People who are new to SPF will be able to follow the document. (b) It seems to be in line with some other standards which the IETF has produced and that will be important for passing the document through the IESG. (c) There was some concerns about some reorganizations in the original RFC. The counter-arguments are: (a) When you move large chucks of text around there is a risk that the meaning could be changed. The argument was dismissed several times on the mailing list. The Chair urged people to take the argument seriously. He mentioned that the DNSEXT WG ran into a problem when it changed the meaning of something in a way which was significant to the protocol. (b) There are many successful implementations of SPF in the field and therefore there is no reason to change the format of the draft. (c) The working already has a draft on which it has been working on. The three questions to be considered at the meeting were: (a) What is the audience of the document? (b) What is the risk of backward compatibility issues if the document is reorganized; what is the risk that the working group will introduce an accidental change? (c) Will the consumers of the document be better served by the reorganized draft or the current working group draft? The Chair considered this question as the bottom line. Murray Kucherawy commented that he does not believe that the audience for the document is current implementers. He mentioned that as work builds up on DMARC there will be some new implementations. He believes that there was a tight-knit community when SPF was developed and that the community is smaller now. The quality of the document needs to be much higher because the audience is not the same as it used to be. He doesn't know how to measure the risk to backward compatibility. He pointed out that he did not face the problem with DKIM. The Chair suggested that one way to test for backward compatibility is to get somebody who has not implemented SPF before to test against the reorganized draft and see whether it is compatible with existing implementations. Scott Kitterman (attending remotely) would like to make sure that the working group is done with all reorganization questions and does not get derailed again. He mentioned that the SPF community is smaller but is still there and willing to help people out. He pointed out that Murray's draft also included some changes which was not just organizational. Murray Kucherawy agreed with Scott Kitterman and said that they have had a discussion about the matter. Dave Crocker thought that it was worth distinguishing between new implementers and new operators. He doesn't think that the document will be relevant to existing folks. He suggested moving the text around and snapshot it as an I-D so that it is in the record and then go and improve the language. He said that things like conflating policy with mechanisms are standard examples of how the document may be confusing to average new readers: Structural clarity seems to make an enormous difference to that. Scott Kitterman commented that the working group agrees on structural changes and can check the details of textual changes later. Tim Draegen commented that the audience for the document are less technical experts and more folks that are coming on board and looking at SPF to deploy. As a trainer he would like to have a cleaner document that he can have his students look up. That is the primary audience in his opinion. He does not think that there is a risk of accidental changes as many people are paying attention to the draft now. The way to avoid that is to rely on reviewing to catch any mistakes. The Chair commented that it would be useful to point if there are any parts in the existing draft that would be problematic. It would then be possible to prioritize which parts of the reorganized document is really important. Tim Draegen listed when does the HELO identifier come into play as an example. Dave Crocker relayed a comment from Kurt Andersen about a +1 for restructuring based on Tim Draegon's position statement related to educational usage. Scott Kitterman commented on Tim's point about the new people trying to figure out how to publish SPF records is an excellent one. It kind of convinced him that there is more of a new audience than he had anticipated before. John Levine commented that there are multiple audiences; one is the programmers who need to know how to build a SPF machine, take a record, process it and return a trinary result; the second audience is people sending mail and wanting to create correct SPF records; a third audience is people taking that trinary result and configure their mail servers to do something. The problem with the current draft is advice to those three groups are mixed together. He would like to separate the algorithmic part from the heuristics part which is basically about what to do with the result. The Chair asked whether there is still work to be done in respect to the reorganization. John Levine replied that he posted comments over a month ago and he does not remember. Alessandro Vesely agreed with what John Levine said. He pointed that there is a confusion about whether any advice in the document is given to the programmer or the configurator. Each implementation takes a different approach the whitelisting or the exclusion or whatever is needed to have SPF make sense. He would like to separate those parts. Alessandro Vesely commented on splitting the document into two separate documents which is the algorithmic and the publishing parts, and the receiver behavior. He asked whether that decision was expected to come out of the meeting. Scott Kitterman (via Jabber) said that if we can get consensus on one thing today, please can it be that we've done all the reorganizing/splitting we are going to do, so we can focus on getting whatever we are going to do done? The Chair stated that he would like the working group to come to agreement on which way it would like to go. Alessandro Vesely replied that he would like to see the document split in two, even if that is more difficult as it requires to interpret concepts that the original document pushes without saying why and how. Murray Kucherawy mentioned that the reorganization makes it possible to split the document but he does not advocate either way. Chris (full name was not audible) said that the reorganization keeps the document the way a normal RFC reads and that it would be easier for somebody he brings on board his team to understand and discuss about the document. Kurt Andersen (via Jabber) said that unless it would help get through the approval process, he would advocate a reorginaztion without a split. John Kelly considered the audience as being new implementers. Risk of backward incompatible changes do exist but he does not see a risk of backward incompatibility. He agreed with Chris about the reorganization. He said that he was 49 split versus 51 not split. He is okay with whatever helps the approval process; if it is a noop, he would go for leave the document intact just for referenceability. Pete Resnick, as Responsible Area Director, commented on the process question: so long as the working group gives him ammunition to fight silliness, he is not worried about getting through Last Call or the IESG Evaluation. He asked whether there is anything specific about the reorganized document which is concerning people. Andrew Sullivan put forward an argument that was made on the mailing list; the reorganization is an opportunity for people who have been trying to make changes to SPFBIS specification to sneak those changes in. He stated that there wasn't any pointer to any place where that has actually happened. He had to discount it as an actual problem as it was a change that he was unable to see. Pete Resnick stated that the comment made by Dave Crocker about doing the reorganization first and doing the changes after that would address the risk of changes being sneaked in. Scott Kitterman (via Jabber) stated that since the document editor is strongly opposed to making such changes, he thinks the risk of it is quite low. In his opinion it was clear that there is a strong lean towards the reorganization in the group and he is okay with that. He thinks that splitting is a bad idea for several reason. He also mentioned that Andrew's discussion of the DNS issue exemplifies one concern about a split. Currently, he has references to specific paragraphs about protocol, policy, and publishing. If it's split into two or more documents, then we lose those deep references and introduce risk of confusion. Scott Kitterman stated that if the consensus is to reorganize, then he is happy to review Murray's diff and make sure it doesn't introduce any inadvertent changes. The Chair, responding to a comment from Alessandro Vesely, mentioned that the idea of a comparison of the reorganized draft is to do a sanity check and any subsequent changes would be changes the working group did intentionally. Pete Resnick commented on the IESG having to review the iSCSI draft which was a 300 page monstrosity. Having the diff, taken after reshuffling paragraphs of the original RFC so that they matched, really made a difference in that case. important for the working group to convince itself that all things are good instead of being concerned about a violation in the SPFBIS charter which restricts changes that can be made to the document. The Chair agreed that there is a value in documenting the changes as the WG is chartered to not alter the specification and it might be asked to prove that it actually didn't. John Levine was okay with not splitting the document. The Chair stated that his impression after hearing the comments about the first question is that the working group has a pretty broad audience for the document. In response to the second question the working group seems to have some procedures to minimize the risk of changes and those sound like they are going to be acceptable. His sense of the room about the third question is that there is a desire to do the reorganization. The Chair asked two questions to take a sense of the room: (i) support for reorganization (ii) not support the reorganization The Chair stated that what he heard from the hums in very support for the reorganization and no opposition. That will be confirmed on the SPFBIS mailing list. The Chair took a hum about: (i) splitting the document (ii) opposed to splitting the document The Chair heard at least two hums in favor of splitting the document. The Chair mentioned that there does not seem to be a strong opinion one way or the other. It was also mentioned that the input from Jabber pointed to people being opposed to splitting the document. The answer is not to split the document. Alessandro Vesely commented that an Applicability Statement for receiver behavior should be experimental, currently. Murray Kucherawy commented that the idea of a second document was: here is what you do with a "pass", here is what we think you are supposed to do with a "fail". He mentioned that there was now obvious resistance to that and he didn't want to get into all the arguments. The Chair took another hum about splitting the document in light of the new arguments which were made: (i) all those in favor of splitting the document (ii) all of those opposed to splitting the document He stated that he heard approximately even in the room for the two options and that, in Jabber, there were nobody in favor and people opposed. The Chair stated for the minutes that the working group will be doing the reorganization but it is not planning to split the document. This will be taken to the mailing list for confirmation. Murray Kucherawy and Scott Kitterman will collaborate on an updated document taking into account the intermediate steps to do the comparison in case anybody gives the working group a hard time later. The Chair asked whether that seems what the working group agreed to today and nobody said no. Pete Resnick, as Responsible Area Director, asked to put the question to the mailing list and ask people to state their objections if they are in favor of a split. Dave Crocker commented that it is unncessary. The Chair, in reply to a comment from Scott Kitterman, commented that the plan is to send a note to the mailing list that outlines the intermediate steps and who is going to take them. Under Any Other Business, Alessandro Vesely had a question about DMARC not to be discussed in the IETF. The question was not discussed further as it was not SPFBIS business. Andrew Sullivan thanked the working group for the productive meeting. The meeting was adjourned at 6:29 p.m. --=====================_1024479891==_-- From sm@elandsys.com Fri Dec 7 12:06:54 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C696C21F8561 for ; Fri, 7 Dec 2012 12:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwGeLpeq2LLf for ; Fri, 7 Dec 2012 12:06:54 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12521F8563 for ; Fri, 7 Dec 2012 12:06:48 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.129.85]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qB7K6Us5005376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 7 Dec 2012 12:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1354910802; bh=6FCs1aLF91L3Dv9hq4oJ3Gc+ThUY2836E6/LxCoZoKM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=bLT0CCTtcFma9d0usjgVFtl4BtSS0EXKo85CyghNkLZ8CZrTm3yLFaBuwRJX1+5if 58VfCNlsEY1alCjr9na1xCqPFzqZu+gljwdRsNHEKkjn+GcTRbhtW81bwy21fBocSW hfyMp5R6VjtEuhR57Q9dubbb+c9PEtF82pTcmZQY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1354910802; i=@elandsys.com; bh=6FCs1aLF91L3Dv9hq4oJ3Gc+ThUY2836E6/LxCoZoKM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=hUNRIH1AT3jS/77WYI0EUNS2DX/ClciH8a8QTkg4+GHIUxBf39q+bVXA6IW0X/hiE NboUHnIbAXLC9W5MQQGtVJcJD/CsHEYd1P9SSamz7Z/4h7cc1Ie6ygCHZKtwSBZOPw MthLzwB9Yf/gi8PoiGVKBPnng1lTdMdhpEKfop30= Message-Id: <6.2.5.6.2.20121207115824.0b728c88@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 07 Dec 2012 12:05:44 -0800 To: Scott Kitterman , "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: <20121123204745.GB56042@crankycanuck.ca> References: <20121123204745.GB56042@crankycanuck.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: spfbis@ietf.org Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 20:06:54 -0000 Hi Scott, Murray, At 12:47 23-11-2012, Andrew Sullivan wrote: > 2. Scott, in collaboration with Murray Kucherawy (who proposed > the original reorganization), undertakes the reorganization and > creates the next WG document. This reorganization should have > _no_ text changes in it apart from moving text around. A note > should be added to that version of the draft to indicate that it > only reorganizes the text of 08. This will form the WG draft 09. > This version must be uploaded as 09 in order to provide the > necessary chain in the tracking tools, so that we can demonstrate > that the reorganization did not change the substance of 08. It's been two weeks since the above was posted. There wasn't any feedback. Would it be possible to get a -09 version submitted so that the working group can continue its work? Thanks, S. Moonesamy From spf2@kitterman.com Fri Dec 7 13:44:21 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114CE21F8BB3 for ; Fri, 7 Dec 2012 13:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBuAbTk+OVVR for ; Fri, 7 Dec 2012 13:44:20 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 94C9F21F8BB1 for ; Fri, 7 Dec 2012 13:44:20 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 2541B20E4106; Fri, 7 Dec 2012 16:44:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1354916660; bh=xlkxPLFmCmu8Se+OGnujBe9nWeUsVMmSYEZ77UH771E=; h=From:To:Subject:Date:In-Reply-To:References:From; b=YXpNaoU27ylmpOK7B6gWkGS6aRIZXSf7gsmjNXB6VQRL7GrHdrHWrqsEn/REc5X2E tDoT+WDEy4DrA3TLULApOV9r4a14t83cwC6eTHQ7bLVS0Vte33Cqo6CAbRRhQcRjhU SmuUDpgrrdMndWK/RuQu5NG6yP3iP4RrqJ/8JALY= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0E95520E40CE; Fri, 7 Dec 2012 16:44:20 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 07 Dec 2012 16:44:19 -0500 Message-ID: <4350053.YsP51LBrxt@scott-latitude-e6320> User-Agent: KMail/4.9.3 (Linux/3.5.0-19-generic; KDE/4.9.3; i686; ; ) In-Reply-To: <6.2.5.6.2.20121207115824.0b728c88@resistor.net> References: <20121123204745.GB56042@crankycanuck.ca> <6.2.5.6.2.20121207115824.0b728c88@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 21:44:21 -0000 On Friday, December 07, 2012 12:05:44 PM S Moonesamy wrote: > Hi Scott, Murray, > > At 12:47 23-11-2012, Andrew Sullivan wrote: > > 2. Scott, in collaboration with Murray Kucherawy (who proposed > > the original reorganization), undertakes the reorganization and > > creates the next WG document. This reorganization should have > > _no_ text changes in it apart from moving text around. A note > > should be added to that version of the draft to indicate that it > > only reorganizes the text of 08. This will form the WG draft 09. > > This version must be uploaded as 09 in order to provide the > > necessary chain in the tracking tools, so that we can demonstrate > > that the reorganization did not change the substance of 08. > > It's been two weeks since the above was posted. There wasn't any feedback. > > Would it be possible to get a -09 version submitted so that the > working group can continue its work? First I need to publish the RFC 4408 diff to -08. I should be able to do that today or tomorrow. Scott K P.S. I am subscribed to the list and read it quite regularly. No need to CC me directly on list mail. From superuser@gmail.com Fri Dec 7 18:06:58 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADA521F85C8 for ; Fri, 7 Dec 2012 18:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIjXGKzokXlt for ; Fri, 7 Dec 2012 18:06:57 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29B6821F854F for ; Fri, 7 Dec 2012 18:06:56 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so856444lah.31 for ; Fri, 07 Dec 2012 18:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+Rty3R4IdcV2yDOQe3whgKkxrdGmOq9+5aHcpLkPNoI=; b=RzZM4CbreLYVsj7iCSleBLR3JsBA6jLtQK3DUs7iPqkqtVaUvSFrk9fUqF8V7aTVcV 17YIMPtZZpzzCNZU4yRIoj0/wyrLZihQElT9UwRGNaxxYMqDgTagHST2DOXGN/I+LXlb mrL12KMVJ7XMOEbkiTnWGfUbJ3UPZFjCT0KuuN6NoUS+aPhA2I5L5WUJQvQl2Q/fFMqv Z3iinjN04+ef+0go5ZyiMU032WJ9njZ5mwI9ycvM4Ll/4dvzLFoDO7RpXoReR7dZ53dU xiyieDDuNIg/1Ha7S3b3up2UKF52wlyETR/BF6ijhUanhj/KTAmQ+i6FnOxNr1CXPH1W UvdQ== MIME-Version: 1.0 Received: by 10.152.111.68 with SMTP id ig4mr7262913lab.50.1354932414930; Fri, 07 Dec 2012 18:06:54 -0800 (PST) Received: by 10.112.61.67 with HTTP; Fri, 7 Dec 2012 18:06:54 -0800 (PST) In-Reply-To: <6.2.5.6.2.20121207115824.0b728c88@resistor.net> References: <20121123204745.GB56042@crankycanuck.ca> <6.2.5.6.2.20121207115824.0b728c88@resistor.net> Date: Fri, 7 Dec 2012 18:06:54 -0800 Message-ID: From: "Murray S. Kucherawy" To: "spfbis@ietf.org" Content-Type: multipart/alternative; boundary=f46d04083b51495dd704d04dc990 Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2012 02:06:58 -0000 --f46d04083b51495dd704d04dc990 Content-Type: text/plain; charset=ISO-8859-1 Hi SM, Scott has the proverbial pen. I stand ready to assist if he needs it. -MSK On Fri, Dec 7, 2012 at 12:05 PM, S Moonesamy wrote: > Hi Scott, Murray, > > At 12:47 23-11-2012, Andrew Sullivan wrote: > >> 2. Scott, in collaboration with Murray Kucherawy (who proposed >> the original reorganization), undertakes the reorganization and >> creates the next WG document. This reorganization should have >> _no_ text changes in it apart from moving text around. A note >> should be added to that version of the draft to indicate that it >> only reorganizes the text of 08. This will form the WG draft 09. >> This version must be uploaded as 09 in order to provide the >> necessary chain in the tracking tools, so that we can demonstrate >> that the reorganization did not change the substance of 08. >> > > It's been two weeks since the above was posted. There wasn't any feedback. > > Would it be possible to get a -09 version submitted so that the working > group can continue its work? > > Thanks, > S. Moonesamy > --f46d04083b51495dd704d04dc990 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi SM,

Scott has the proverbial pen.=A0 I stand ready to assist if h= e needs it.

-MSK


On Fri, Dec 7, 2012 at 12:05 PM, S Moonesamy <sm+ietf@ela= ndsys.com> wrote:
Hi Scott, Murray,

At 12:47 23-11-2012, Andrew Sullivan wrote:
=A0 =A0 2. =A0Scott, in collaboration with Murray Kucherawy (who proposed =A0 =A0 the original reorganization), undertakes the reorganization and
=A0 =A0 creates the next WG document. =A0This reorganization should have =A0 =A0 _no_ text changes in it apart from moving text around. =A0A note =A0 =A0 should be added to that version of the draft to indicate that it =A0 =A0 only reorganizes the text of 08. =A0This will form the WG draft 09.=
=A0 =A0 This version must be uploaded as 09 in order to provide the
=A0 =A0 necessary chain in the tracking tools, so that we can demonstrate =A0 =A0 that the reorganization did not change the substance of 08.

It's been two weeks since the above was posted. =A0There wasn't any= feedback.

Would it be possible to get a -09 version submitted so that the working gro= up can continue its work?

Thanks,
S. Moonesamy

--f46d04083b51495dd704d04dc990-- From sm@elandsys.com Thu Dec 13 08:51:03 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685F721F8716 for ; Thu, 13 Dec 2012 08:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkFsfsFV0wuj for ; Thu, 13 Dec 2012 08:51:02 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BE321F8647 for ; Thu, 13 Dec 2012 08:51:01 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.145.189]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qBDGoknP019270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Dec 2012 08:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1355417459; bh=uKluofiSkaSQjx0OPua61YSoOAlFFmHCIboTFXensAM=; h=Date:To:From:Subject:In-Reply-To:References; b=EOjzvdLCImNV6bOh6ztItU2XD2Kyy9f9sZjkkZJl8emfgdiIr5JtuZ05GKoDjz3I+ /PH2A+M8JlfvfRvWw5smBx5sGX/D4OiFxRSliT43N/0tBPwvdce5ljvHY96x1fAE4l pu3ul2PmWoUYJDGCqJcLlIDSq8dfrMGJfXZlgPZA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1355417459; i=@elandsys.com; bh=uKluofiSkaSQjx0OPua61YSoOAlFFmHCIboTFXensAM=; h=Date:To:From:Subject:In-Reply-To:References; b=QC6X2FU0y7fulM34UR62cozM3JFvL+qHvi3GeUWa4/j2T2awvBtGCmS2L5vhWk8nf 3l17vcOlMz2yGyXGfpEyrheFM6GsLFxbtxJtasJJmikhkp0v1nNyQOivO3ufqqp+b0 KqnvrRED+q2DIrCbL5iCYN+6R7myTbhybiN1JU+w= Message-Id: <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Dec 2012 08:50:26 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <4350053.YsP51LBrxt@scott-latitude-e6320> References: <20121123204745.GB56042@crankycanuck.ca> <6.2.5.6.2.20121207115824.0b728c88@resistor.net> <4350053.YsP51LBrxt@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:51:03 -0000 Hi Scott, At 13:44 07-12-2012, Scott Kitterman wrote: >First I need to publish the RFC 4408 diff to -08. I should be able >to do that >today or tomorrow. Could you please provide an update about the status of the diff? Thanks, S. Moonesamy From spf2@kitterman.com Thu Dec 13 12:10:47 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D81721F8B83 for ; Thu, 13 Dec 2012 12:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouFFrJHgZsAS for ; Thu, 13 Dec 2012 12:10:46 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id D0B3921F8B6C for ; Thu, 13 Dec 2012 12:10:45 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 6D8BC20E40CF; Thu, 13 Dec 2012 15:10:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1355429444; bh=apGP/NAqLgPp0YrjAvf0x01BOKT+sxJodFX0JADDcMw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=PG+H4Y368pvNxQ2Q0FdmDML4d5Tm7R1QZasV2GTn3u5b6wdRubssdje+D20GIS6NL 7W8QgvJJ0mXla3CO9jsRb/2sfCfcVnaac0DLGnQAiA6oVmAHb/CqD4VQFTZ0jURfZB 4wiYFREsVP7tFU5IizpwcHTWLiWvhJL+aIc/Id1A= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 4AB3F20E406B; Thu, 13 Dec 2012 15:10:43 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Thu, 13 Dec 2012 15:10:40 -0500 Message-ID: <13162108.dfXztYiDo9@scott-latitude-e6320> User-Agent: KMail/4.9.3 (Linux/3.5.0-19-generic; KDE/4.9.3; i686; ; ) In-Reply-To: <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> References: <20121123204745.GB56042@crankycanuck.ca> <4350053.YsP51LBrxt@scott-latitude-e6320> <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:10:47 -0000 On Thursday, December 13, 2012 08:50:26 AM S Moonesamy wrote: > Hi Scott, > > At 13:44 07-12-2012, Scott Kitterman wrote: > >First I need to publish the RFC 4408 diff to -08. I should be able > >to do that > >today or tomorrow. > > Could you please provide an update about the status of the diff? The status is the same. Today or tomorrow. Really this time. Sorry for the delays. Scott K From dhc@dcrocker.net Thu Dec 13 13:33:27 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F8321F8645 for ; Thu, 13 Dec 2012 13:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftxl7tlDhQoB for ; Thu, 13 Dec 2012 13:33:25 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4F421F863B for ; Thu, 13 Dec 2012 13:33:25 -0800 (PST) Received: from [64.170.98.197] ([64.170.98.197]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qBDLXJMp025588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Dec 2012 13:33:22 -0800 Message-ID: <50CA499A.80903@dcrocker.net> Date: Thu, 13 Dec 2012 13:33:14 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Scott Kitterman References: <20121123204745.GB56042@crankycanuck.ca> <4350053.YsP51LBrxt@scott-latitude-e6320> <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> <13162108.dfXztYiDo9@scott-latitude-e6320> In-Reply-To: <13162108.dfXztYiDo9@scott-latitude-e6320> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Dec 2012 13:33:24 -0800 (PST) Cc: spfbis@ietf.org Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 21:33:27 -0000 On 12/13/2012 12:10 PM, Scott Kitterman wrote: > The status is the same. Today or tomorrow. Many years ago, I was sitting in a bar in around Washington DC, on a Saturday. Behind the bartender was a sign that said "Free beer tomorrow". I expressed confusion, since bars in the area were closed on Sunday. His response was simply "tomorrow never comes"... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba.mailing.lists@gmail.com Thu Dec 13 15:15:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D5621F8BD0 for ; Thu, 13 Dec 2012 15:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.046 X-Spam-Level: X-Spam-Status: No, score=-103.046 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M99syZMeWmYu for ; Thu, 13 Dec 2012 15:15:19 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED74321F8B7D for ; Thu, 13 Dec 2012 15:15:18 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so2239557lah.31 for ; Thu, 13 Dec 2012 15:15:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g7QyC+SItRAAlSPDykacN+H9Kn4Itk4r6p8hKXSRlNs=; b=e3bl2yzhUFgD4H49hzt00OXtMOU8Xnlv4fdaxngiMEbZJtVTGOK3hmJC4scNCTdqYM N3yQy/cBFcSBuc7apD9mf65it6pEXk2jazSttWoyu6xPQi0qGq+YAvLB3LoBaMMbYj/v c2eopQFRGxERgxTj4UsOzrpiH+oLALTw2lgFlcoiNYVrees2FIr65tcnGl79UWOHV1K5 Px63luyeY3anUku9X1J0D33MsDFQMachzfE8nqpZrSZezvv2w9mRpHvw4fyG6cefKC3c 3y3TYUZPWjbZlBiF0TNe5jc7VfVYxePBJZUrfcqYX7/UU3HThqqQsBnHauBjjjzLVd0G t9eg== MIME-Version: 1.0 Received: by 10.152.111.166 with SMTP id ij6mr791936lab.47.1355440517918; Thu, 13 Dec 2012 15:15:17 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Thu, 13 Dec 2012 15:15:17 -0800 (PST) In-Reply-To: <50CA499A.80903@dcrocker.net> References: <20121123204745.GB56042@crankycanuck.ca> <4350053.YsP51LBrxt@scott-latitude-e6320> <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> <13162108.dfXztYiDo9@scott-latitude-e6320> <50CA499A.80903@dcrocker.net> Date: Thu, 13 Dec 2012 18:15:17 -0500 X-Google-Sender-Auth: 54_kDA1JxsowrmpzruzXBWXWDS8 Message-ID: From: Barry Leiba To: Dave Crocker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:15:19 -0000 > Many years ago, I was sitting in a bar in around Washington DC, on a > Saturday. Behind the bartender was a sign that said "Free beer tomorrow"= . And we can trace it back to Lewis Carroll, from "Through the Looking Glass and what Alice Found There" [Barry grabs his copy of "The Annotated Alice"]: "I'm sure I'll take *you* with pleasure!" the Queen said. "Twopence a week, and jam every other day." Alice couldn't help laughing, as she said "I don't want you to hire *me* =96 and I don't care for jam." "It's very good jam," said the Queen. "Well, I don't want any *to-day*, at any rate." "You couldn't have it if you *did* want it," the Queen said. "The rule is, jam to-morrow and jam yesterday =96 but never jam to-day." "It *must* come sometimes to 'jam to-day'," Alice objected. "No, it ca'n't," said the Queen. "It's jam every *other* day: to-day isn't any *other* day, you know." -- Barry From dhc@dcrocker.net Thu Dec 13 15:38:36 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0746F21F88F6 for ; Thu, 13 Dec 2012 15:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLlOVD+cOj2D for ; Thu, 13 Dec 2012 15:38:25 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5750F21F87EA for ; Thu, 13 Dec 2012 15:38:25 -0800 (PST) Received: from [192.168.5.223] (ip-64-134-237-80.public.wayport.net [64.134.237.80]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id qBDNcGSj013251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 13 Dec 2012 15:38:18 -0800 Message-ID: <50CA66E2.50108@dcrocker.net> Date: Thu, 13 Dec 2012 15:38:10 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Barry Leiba References: <20121123204745.GB56042@crankycanuck.ca> <4350053.YsP51LBrxt@scott-latitude-e6320> <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> <13162108.dfXztYiDo9@scott-latitude-e6320> <50CA499A.80903@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 13 Dec 2012 15:38:20 -0800 (PST) Cc: "spfbis@ietf.org" , Scott Kitterman Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 23:38:36 -0000 On 12/13/2012 3:15 PM, Barry Leiba wrote: >> Many years ago, I was sitting in a bar in around Washington DC, on a >> Saturday. Behind the bartender was a sign that said "Free beer tomorrow". > .. > "You couldn't have it if you *did* want it," the Queen said. "The > rule is, jam to-morrow and jam yesterday – but never jam to-day." > "It *must* come sometimes to 'jam to-day'," Alice objected. > "No, it ca'n't," said the Queen. "It's jam every *other* day: > to-day isn't any *other* day, you know." I suppose it depends upon whether you'd rather not get beer or not get jam. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From spf2@kitterman.com Fri Dec 14 12:06:07 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2811C21F89F9 for ; Fri, 14 Dec 2012 12:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWl3n+eNhSTt for ; Fri, 14 Dec 2012 12:06:06 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2642221F8A6B for ; Fri, 14 Dec 2012 12:06:06 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5DF6020E40CF; Fri, 14 Dec 2012 15:06:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1355515563; bh=GeXU/H2D12yudwZ0pA5It4ibt24FeuOD1aS+cJL1p08=; h=From:To:Subject:Date:From; b=kCWtN25R7ovCZ6rNDgouIWvHTovcXpoOssxymNGXpaVbf2fYAmt1EEYllvviSSOBn 80zoPRWMYSbCb9PFcrwaf4Jcvn+esh5WjowgFhn8x273fRf0YvEkraUTMbV/WWLjBs u7ice1vpaI8gh2b40Tg3kfZgkVvwfj9jTpHA1kOw= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 0B03F20E407B; Fri, 14 Dec 2012 15:06:02 -0500 (EST) From: Scott Kitterman To: "spfbis@ietf.org" Date: Fri, 14 Dec 2012 15:06:02 -0500 Message-ID: <1758411.Z4lZWUANF0@scott-latitude-e6320> User-Agent: KMail/4.9.3 (Linux/3.5.0-21-generic; KDE/4.9.3; i686; ; ) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart5176285.t3OJvF5UHl" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: [spfbis] RFC 4408 to draft-ietf-spfbis-4408bis-08 difference X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 20:06:07 -0000 This is a multi-part message in MIME format. --nextPart5176285.t3OJvF5UHl Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" The current diff from RFC 4408 is attached in rfcdiff format. So the answer "today or tomorrow" was correct either way depending on your perspective. Scott K --nextPart5176285.t3OJvF5UHl Content-Disposition: attachment; filename="draft-kitterman-4408bis-00-from-rfc4408.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="UTF-8"; name="draft-kitterman-4408bis-00-from-rfc4408.diff.html" Diff: rfc4408.txt - draft-kitterman-4408bis-00.txt
 rfc4408.txt   draft-kitterman-4408bis-00.txt 
Network Working Group M. Wong Network Working Group D. Kitterman
Request for Comments: 4408 W. Schlitt Internet-Draft W. Schlitt
Category: Experimental April 2006 Obsoletes: 4408 (if approved) October 24, 2011
Intended status: Standards Track
Sender Policy Framework (SPF) for Expires: April 26, 2012
Authorizing Use of Domains in E-Mail, Version 1
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
IESG Note
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
are published simultaneously as Experimental RFCs, although there is
no general technical consensus and efforts to reconcile the two
approaches have failed. As such, these documents have not received
full IETF review and are published "AS-IS" to document the different
approaches as they were considered in the MARID working group.
The IESG takes no position about which approach is to be preferred
and cautions the reader that there are serious open issues for each
approach and concerns about using them in tandem. The IESG believes
that documenting the different approaches does less harm than not
documenting them.
Note that the Sender ID experiment may use DNS records that may have
been created for the current SPF experiment or earlier versions in
this set of experiments. Depending on the content of the record,
this may mean that Sender-ID heuristics would be applied incorrectly
to a message. Depending on the actions associated by the recipient
with those heuristics, the message may not be delivered or may be
discarded on receipt.
Participants relying on Sender ID experiment DNS records are warned
that they may lose valid messages in this set of circumstances.
aParticipants publishing SPF experiment DNS records should consider
the advice given in section 3.4 of RFC 4406 and may wish to publish
both v=spf1 and spf2.0 records to avoid the conflict.
Participants in the Sender-ID experiment need to be aware that the
way Resent-* header fields are used will result in failure to receive
legitimate email when interacting with standards-compliant systems
(specifically automatic forwarders which comply with the standards by
not adding Resent-* headers, and systems which comply with RFC 822
but have not yet implemented RFC 2822 Resent-* semantics). It would
be inappropriate to advance Sender-ID on the standards track without
resolving this interoperability problem.
The community is invited to observe the success or failure of the two Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail,
approaches during the two years following publication, in order that Version 1
a community consensus can be reached in the future. draft-kitterman-4408bis-00.txt
Abstract Abstract
E-mail on the Internet can be forged in a number of ways. In E-mail on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending particular, existing protocols place no restriction on what a sending
host can use as the reverse-path of a message or the domain given on host can use as the reverse-path of a message or the domain given on
the SMTP HELO/EHLO commands. This document describes version 1 of the SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby a domain may the Sender Policy Framework (SPF) protocol, whereby a domain may
explicitly authorize the hosts that are allowed to use its domain explicitly authorize the hosts that are allowed to use its domain
name, and a receiving host may check such authorization. name, and a receiving host may check such authorization.
Table of Contents Status of this Memo
1. Introduction ....................................................4 This Internet-Draft is submitted in full conformance with the
1.1. Protocol Status ............................................4 provisions of BCP 78 and BCP 79.
1.2. Terminology ................................................5
2. Operation .......................................................5
2.1. The HELO Identity ..........................................5
2.2. The MAIL FROM Identity .....................................5
2.3. Publishing Authorization ...................................6
2.4. Checking Authorization .....................................6
2.5. Interpreting the Result ....................................7
2.5.1. None ................................................8
2.5.2. Neutral .............................................8
2.5.3. Pass ................................................8
2.5.4. Fail ................................................8
2.5.5. SoftFail ............................................9
2.5.6. TempError ...........................................9
2.5.7. PermError ...........................................9
3. SPF Records .....................................................9
3.1. Publishing ................................................10
3.1.1. DNS Resource Record Types ..........................10
3.1.2. Multiple DNS Records ...............................11
3.1.3. Multiple Strings in a Single DNS record ............11
3.1.4. Record Size ........................................11
3.1.5. Wildcard Records ...................................11
4. The check_host() Function ......................................12 Internet-Drafts are working documents of the Internet Engineering
4.1. Arguments .................................................12 Task Force (IETF). Note that other groups may also distribute
4.2. Results ...................................................13 working documents as Internet-Drafts. The list of current Internet-
4.3. Initial Processing ........................................13 Drafts is at http://datatracker.ietf.org/drafts/current/.
4.4. Record Lookup .............................................13
4.5. Selecting Records .........................................13
4.6. Record Evaluation .........................................14
4.6.1. Term Evaluation ....................................14
4.6.2. Mechanisms .........................................15
4.6.3. Modifiers ..........................................15
4.7. Default Result ............................................16
4.8. Domain Specification ......................................16
5. Mechanism Definitions ..........................................16
5.1. "all" .....................................................17
5.2. "include" .................................................18
5.3. "a" .......................................................19
5.4. "mx" ......................................................20
5.5. "ptr" .....................................................20
5.6. "ip4" and "ip6" ...........................................21
5.7. "exists" ..................................................22
6. Modifier Definitions ...........................................22
6.1. redirect: Redirected Query ................................23
6.2. exp: Explanation ..........................................23
7. The Received-SPF Header Field ..................................25
8. Macros .........................................................27
8.1. Macro Definitions .........................................27
8.2. Expansion Examples ........................................30
9. Implications ...................................................31
9.1. Sending Domains ...........................................31
9.2. Mailing Lists .............................................32
9.3. Forwarding Services and Aliases ...........................32
9.4. Mail Services .............................................34
9.5. MTA Relays ................................................34
10. Security Considerations .......................................35
10.1. Processing Limits ........................................35
10.2. SPF-Authorized E-Mail May Contain Other False
Identities ...............................................37
10.3. Spoofed DNS and IP Data ..................................37
10.4. Cross-User Forgery .......................................37
10.5. Untrusted Information Sources ............................38
10.6. Privacy Exposure .........................................38
11. Contributors and Acknowledgements .............................38
12. IANA Considerations ...........................................39
12.1. The SPF DNS Record Type ..................................39
12.2. The Received-SPF Mail Header Field .......................39
13. References ....................................................39
13.1. Normative References .....................................39
13.2. Informative References ...................................40
Appendix A. Collected ABNF .......................................42 Internet-Drafts are draft documents valid for a maximum of six months
Appendix B. Extended Examples ....................................44 and may be updated, replaced, or obsoleted by other documents at any
B.1. Simple Examples ..........................................44 time. It is inappropriate to use Internet-Drafts as reference
B.2. Multiple Domain Example ..................................45 material or to cite them other than as "work in progress."
B.3. DNSBL Style Example ......................................46
B.4. Multiple Requirements Example ............................46 This Internet-Draft will expire on April 26, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Protocol Status . . . . . . . . . . . . . . . . . . . . . 5
1.2. Experimental History . . . . . . . . . . . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. The HELO Identity . . . . . . . . . . . . . . . . . . . . 7
2.2. The MAIL FROM Identity . . . . . . . . . . . . . . . . . . 7
2.3. Publishing Authorization . . . . . . . . . . . . . . . . . 7
2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 8
2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 9
2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.5. SoftFail . . . . . . . . . . . . . . . . . . . . . . . 10
2.5.6. TempError . . . . . . . . . . . . . . . . . . . . . . 11
2.5.7. PermError . . . . . . . . . . . . . . . . . . . . . . 11
3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Publishing . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. DNS Resource Record Types . . . . . . . . . . . . . . 12
3.1.2. Multiple DNS Records . . . . . . . . . . . . . . . . . 13
3.1.3. Multiple Strings in a Single DNS record . . . . . . . 13
3.1.4. Record Size . . . . . . . . . . . . . . . . . . . . . 13
3.1.5. Wildcard Records . . . . . . . . . . . . . . . . . . . 14
4. The check_host() Function . . . . . . . . . . . . . . . . . . 15
4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 15
4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 16
4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 16
4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 16
4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 17
4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 17
4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 18
4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 18
4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 18
5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 20
5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5. "ptr" . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 24
5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 26
6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 26
6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 27
7. The Received-SPF Header Field . . . . . . . . . . . . . . . . 29
8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Macro Definitions . . . . . . . . . . . . . . . . . . . . 31
8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 34
9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 35
9.2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . 35
9.3. Forwarding Services and Aliases . . . . . . . . . . . . . 35
9.4. Mail Services . . . . . . . . . . . . . . . . . . . . . . 37
9.5. MTA Relays . . . . . . . . . . . . . . . . . . . . . . . . 38
10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 39
10.2. SPF-Authorized E-Mail May Contain Other False
Identities . . . . . . . . . . . . . . . . . . . . . . . . 40
10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 41
10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 41
10.5. Untrusted Information Sources . . . . . . . . . . . . . . 41
10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 42
11. Contributors and Acknowledgements . . . . . . . . . . . . . . 43
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 44
12.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . . 46
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 48
Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 50
B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 50
B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 51
B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 52
B.4. Multiple Requirements Example . . . . . . . . . . . . . . 52
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 53
Appendix D. TODO . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
The current E-Mail infrastructure has the property that any host The current E-Mail infrastructure has the property that any host
injecting mail into the mail system can identify itself as any domain injecting mail into the mail system can identify itself as any domain
name it wants. Hosts can do this at a variety of levels: in name it wants. Hosts can do this at a variety of levels: in
particular, the session, the envelope, and the mail headers. particular, the session, the envelope, and the mail headers.
Although this feature is desirable in some circumstances, it is a Although this feature is desirable in some circumstances, it is a
major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
Furthermore, many domain name holders are understandably concerned Furthermore, many domain name holders are understandably concerned
skipping to change at page 4, line 47 skipping to change at page 5, line 40
if a claimed identity fails verification, local policy can take if a claimed identity fails verification, local policy can take
stronger action against such E-Mail, such as rejecting it. stronger action against such E-Mail, such as rejecting it.
1.1. Protocol Status 1.1. Protocol Status
SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many
discussed and debated in development forums. discussed and debated in development forums. The protocol was
originally documented in [RFC4408], which this memo replaces.
The goal of this document is to clearly document the protocol defined The goal of this document is to clearly document the protocol defined
by earlier draft specifications of SPF as used in existing by earlier draft specifications of SPF as used in existing
implementations. This conception of SPF is sometimes called "SPF implementations. This conception of SPF is sometimes called "SPF
Classic". It is understood that particular implementations and Classic". It is understood that particular implementations and
deployments may differ from, and build upon, this work. It is hoped deployments may differ from, and build upon, this work. It is hoped
that we have nonetheless captured the common understanding of SPF that we have nonetheless captured the common understanding of SPF
version 1. version 1.
1.2. Terminology 1.2. Experimental History
This document updates and replaces RFC 4408 that was part of a group
of simultaneously published Experimental RFCs (RFC 4405, RFC 4406,
RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the
community observe the success or failure of the two approaches
documented in these RFCs during the two years following publication,
in order that a community consensus can be reached in the future.
In the interval since that statement, DKIM (see [RFC4871] was
developed and achieved wide deployment. Both Sender ID (as the
protocol defined in RFC 4405, RFC 4406, and RFC 4407 was named) and
DKIM target "message content", as described in [RFC5598], while SPF
targets the "transit-handling envelope". The success or failure of
the Sender ID portion of this IESG experiment should be evaluated
relative to DKIM.
SPF is widely deployed by large and small email providers alike.
There are multiple, interoperable implementations.
For SPF (as documented in RFC 4408) a careful effort was made to
collect and document lessons learned and errata during the two year
period. The errata list has been stable (no new submissions) and
only minor protocol lessons learned were identified.
1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document is concerned with the portion of a mail message This document is concerned with the portion of a mail message
commonly called "envelope sender", "return path", "reverse path", commonly called "envelope sender", "return path", "reverse path",
"bounce address", "2821 FROM", or "MAIL FROM". Since these terms are "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are
either not well defined or often used casually, this document defines either not well defined or often used casually, this document defines
the "MAIL FROM" identity in Section 2.2. Note that other terms that the "MAIL FROM" identity in Section 2.2. Note that other terms that
skipping to change at page 9, line 41 skipping to change at page 11, line 24
choose to accept or temporarily reject the message. If the message choose to accept or temporarily reject the message. If the message
is rejected during the SMTP transaction for this reason, the software is rejected during the SMTP transaction for this reason, the software
SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
code. code.
2.5.7. PermError 2.5.7. PermError
A "PermError" result means that the domain's published records could A "PermError" result means that the domain's published records could
not be correctly interpreted. This signals an error condition that not be correctly interpreted. This signals an error condition that
requires manual intervention to be resolved, as opposed to the requires manual intervention to be resolved, as opposed to the
TempError result. Be aware that if the domain owner uses macros TempError result. If the message is rejected during the SMTP
(Section 8), it is possible that this result is due to the checked transaction for this reason, the software SHOULD use an SMTP reply
identities having an unexpected format. code of 550 and, if supported, the 5.5.2 DSN code. Be aware that if
the domain owner uses macros (Section 8), it is possible that this
result is due to the checked identities having an unexpected format.
3. SPF Records 3. SPF Records
An SPF record is a DNS Resource Record (RR) that declares which hosts An SPF record is a DNS Resource Record (RR) that declares which hosts
are, and are not, authorized to use a domain name for the "HELO" and are, and are not, authorized to use a domain name for the "HELO" and
"MAIL FROM" identities. Loosely, the record partitions all hosts "MAIL FROM" identities. Loosely, the record partitions all hosts
into permitted and not-permitted sets (though some hosts might fall into permitted and not-permitted sets (though some hosts might fall
into neither category). into neither category).
The SPF record is a single string of text. An example record is the The SPF record is a single string of text. An example record is the
skipping to change at page 14, line 5 skipping to change at page 16, line 26
4.5. Selecting Records 4.5. Selecting Records
Records begin with a version section: Records begin with a version section:
record = version terms *SP record = version terms *SP
version = "v=spf1" version = "v=spf1"
Starting with the set of records that were returned by the lookup, Starting with the set of records that were returned by the lookup,
record selection proceeds in two steps: record selection proceeds in two steps:
1. Records that do not begin with a version section of exactly 1. Records that do not begin with a version section of exactly
"v=spf1" are discarded. Note that the version section is "v=spf1" are discarded. Note that the version section is
terminated either by an SP character or the end of the record. A terminated either by an SP character or the end of the record. A
record with a version section of "v=spf10" does not match and must record with a version section of "v=spf10" does not match and
be discarded. must be discarded.
2. If any records of type SPF are in the set, then all records of 2. If any records of type SPF are in the set, then all records of
type TXT are discarded. type TXT are discarded.
After the above steps, there should be exactly one record remaining After the above steps, there should be exactly one record remaining
and evaluation can proceed. If there are two or more records and evaluation can proceed. If there are two or more records
remaining, then check_host() exits immediately with the result of remaining, then check_host() exits immediately with the result of
"PermError". "PermError".
If no matching records are returned, an SPF client MUST assume that If no matching records are returned, an SPF client MUST assume that
the domain makes no SPF declarations. SPF processing MUST stop and the domain makes no SPF declarations. SPF processing MUST stop and
return "None". return "None".
skipping to change at page 14, line 49 skipping to change at page 17, line 22
Augmented Backus-Naur Form (ABNF). Augmented Backus-Naur Form (ABNF).
terms = *( 1*SP ( directive / modifier ) ) terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~" qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include mechanism = ( all / include
/ A / MX / PTR / IP4 / IP6 / exists ) / A / MX / PTR / IP4 / IP6 / exists )
modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string
; where name is not any known modifier
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
Most mechanisms allow a ":" or "/" character after the name. Most mechanisms allow a ":" or "/" character after the name.
Modifiers always contain an equals ('=') character immediately after Modifiers always contain an equals ('=') character immediately after
the name, and before any ":" or "/" characters that may be part of the name, and before any ":" or "/" characters that may be part of
the macro-string. the macro-string.
Terms that do not contain any of "=", ":", or "/" are mechanisms, as Terms that do not contain any of "=", ":", or "/" are mechanisms, as
skipping to change at page 16, line 23 skipping to change at page 18, line 43
an "all" mechanism to explicitly terminate processing. an "all" mechanism to explicitly terminate processing.
For example: For example:
v=spf1 +mx -all v=spf1 +mx -all
or or
v=spf1 +mx redirect=_spf.example.com v=spf1 +mx redirect=_spf.example.com
4.8. Domain Specification 4.8. Domain Specification
Several of these mechanisms and modifiers have a <domain-spec> Several of these mechanisms and modifiers have a domain-spec section.
section. The <domain-spec> string is macro expanded (see Section 8). The domain-spec string is macro expanded (see Section 8). The
The resulting string is the common presentation form of a fully- resulting string is the common presentation form of a fully-qualified
qualified DNS name: a series of labels separated by periods. This DNS name: a series of labels separated by periods. This domain is
domain is called the <target-name> in the rest of this document. called the <target-name> in the rest of this document.
Note: The result of the macro expansion is not subject to any further Note: The result of the macro expansion is not subject to any further
escaping. Hence, this facility cannot produce all characters that escaping. Hence, this facility cannot produce all characters that
are legal in a DNS label (e.g., the control characters). However, are legal in a DNS label (e.g., the control characters). However,
this facility is powerful enough to express legal host names and this facility is powerful enough to express legal host names and
common utility labels (such as "_spf") that are used in DNS. common utility labels (such as "_spf") that are used in DNS.
For several mechanisms, the <domain-spec> is optional. If it is not For several mechanisms, the <domain-spec> is optional. If it is not
provided, the <domain> is used as the <target-name>. provided, the <domain> is used as the <target-name>.
skipping to change at page 17, line 16 skipping to change at page 20, line 30
mx mx
ptr ptr
ip4 ip4
ip6 ip6
exists exists
The following conventions apply to all mechanisms that perform a The following conventions apply to all mechanisms that perform a
comparison between <ip> and an IP address at any point: comparison between <ip> and an IP address at any point:
If no CIDR-length is given in the directive, then <ip> and the IP If no CIDR-length is given in the directive, then <ip> and the IP
address are compared for equality. (Here, CIDR is Classless Inter- address are compared for equality. (Here, CIDR is Classless Inter-
Domain Routing.) Domain Routing.)
If a CIDR-length is specified, then only the specified number of If a CIDR-length is specified, then only the specified number of
high-order bits of <ip> and the IP address are compared for equality. high-order bits of <ip> and the IP address are compared for equality.
When any mechanism fetches host addresses to compare with <ip>, when When any mechanism fetches host addresses to compare with <ip>, when
<ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6 <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
address, AAAA records are fetched. Even if the SMTP connection is address, AAAA records are fetched. Even if the SMTP connection is
via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
2.5.5) MUST still be considered an IPv4 address. 2.5.5) MUST still be considered an IPv4 address.
skipping to change at page 18, line 7 skipping to change at page 21, line 16
For example: For example:
v=spf1 a mx -all v=spf1 a mx -all
Mechanisms after "all" will never be tested. Any "redirect" modifier Mechanisms after "all" will never be tested. Any "redirect" modifier
(Section 6.1) has no effect when there is an "all" mechanism. (Section 6.1) has no effect when there is an "all" mechanism.
5.2. "include" 5.2. "include"
include = "include" ":" domain-spec include = "include" ":" domain-spec
The "include" mechanism triggers a recursive evaluation of The "include" mechanism triggers a recursive evaluation of
check_host(). The domain-spec is expanded as per Section 8. Then check_host(). The domain-spec is expanded as per Section 8. Then
check_host() is evaluated with the resulting string as the <domain>. check_host() is evaluated with the resulting string as the <domain>.
The <ip> and <sender> arguments remain the same as in the current The <ip> and <sender> arguments remain the same as in the current
evaluation of check_host(). evaluation of check_host().
In hindsight, the name "include" was poorly chosen. Only the In hindsight, the name "include" was poorly chosen. Only the
evaluated result of the referenced SPF record is used, rather than evaluated result of the referenced SPF record is used, rather than
acting as if the referenced SPF record was literally included in the acting as if the referenced SPF record was literally included in the
skipping to change at page 20, line 42 skipping to change at page 23, line 34
First, the <ip>'s name is looked up using this procedure: perform a First, the <ip>'s name is looked up using this procedure: perform a
DNS reverse-mapping for <ip>, looking up the corresponding PTR record DNS reverse-mapping for <ip>, looking up the corresponding PTR record
in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
if it is an IPv6 address. For each record returned, validate the if it is an IPv6 address. For each record returned, validate the
domain name by looking up its IP address. To prevent DoS attacks, domain name by looking up its IP address. To prevent DoS attacks,
more than 10 PTR names MUST NOT be looked up during the evaluation of more than 10 PTR names MUST NOT be looked up during the evaluation of
a "ptr" mechanism (see Section 10). If <ip> is among the returned IP a "ptr" mechanism (see Section 10). If <ip> is among the returned IP
addresses, then that domain name is validated. In pseudocode: addresses, then that domain name is validated. In pseudocode:
sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 sending-domain_names := ptr_lookup(sending-host_IP);
sending-domain_names are found, use at most 10. for each name in if more than 10 sending-domain_names are found, use at most 10.
(sending-domain_names) { for each name in (sending-domain_names) {
IP_addresses := a_lookup(name); IP_addresses := a_lookup(name);
if the sending-domain_IP is one of the IP_addresses { if the sending-domain_IP is one of the IP_addresses {
validated-sending-domain_names += name; validated-sending-domain_names += name;
} } }
}
Check all validated domain names to see if they end in the Check all validated domain names to see if they end in the
<target-name> domain. If any do, this mechanism matches. If no <target-name> domain. If any do, this mechanism matches. If no
validated domain name can be found, or if none of the validated validated domain name can be found, or if none of the validated
domain names end in the <target-name>, this mechanism fails to match. domain names end in the <target-name>, this mechanism fails to match.
If a DNS error occurs while doing the PTR RR lookup, then this If a DNS error occurs while doing the PTR RR lookup, then this
mechanism fails to match. If a DNS error occurs while doing an A RR mechanism fails to match. If a DNS error occurs while doing an A RR
lookup, then that domain name is skipped and the search continues. lookup, then that domain name is skipped and the search continues.
Pseudocode: Pseudocode:
skipping to change at page 23, line 15 skipping to change at page 26, line 31
6.1. redirect: Redirected Query 6.1. redirect: Redirected Query
If all mechanisms fail to match, and a "redirect" modifier is If all mechanisms fail to match, and a "redirect" modifier is
present, then processing proceeds as follows: present, then processing proceeds as follows:
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
The domain-spec portion of the redirect section is expanded as per The domain-spec portion of the redirect section is expanded as per
the macro rules in Section 8. Then check_host() is evaluated with the macro rules in Section 8. Then check_host() is evaluated with
the resulting string as the <domain>. The <ip> and <sender> the resulting string as the <domain>. The <ip> and <sender>
arguments remain the same as current evaluation of check_host(). arguments remain the same as in the current evaluation of
check_host().
The result of this new evaluation of check_host() is then considered The result of this new evaluation of check_host() is then considered
the result of the current evaluation with the exception that if no the result of the current evaluation with the exception that if no
SPF record is found, or if the target-name is malformed, the result SPF record is found, or if the target-name is malformed, the result
is a "PermError" rather than "None". is a "PermError" rather than "None".
Note that the newly-queried domain may itself specify redirect Note that the newly-queried domain may itself specify redirect
processing. processing.
This facility is intended for use by organizations that wish to apply This facility is intended for use by organizations that wish to apply
skipping to change at page 24, line 7 skipping to change at page 27, line 25
6.2. exp: Explanation 6.2. exp: Explanation
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
If check_host() results in a "Fail" due to a mechanism match (such as If check_host() results in a "Fail" due to a mechanism match (such as
"-all"), and the "exp" modifier is present, then the explanation "-all"), and the "exp" modifier is present, then the explanation
string returned is computed as described below. If no "exp" modifier string returned is computed as described below. If no "exp" modifier
is present, then either a default explanation string or an empty is present, then either a default explanation string or an empty
explanation string may be returned. explanation string may be returned.
The <domain-spec> is macro expanded (see Section 8) and becomes the The domain-spec is macro expanded (see Section 8) and becomes the
<target-name>. The DNS TXT record for the <target-name> is fetched. <target-name>. The DNS TXT record for the <target-name> is fetched.
If <domain-spec> is empty, or there are any DNS processing errors If there are any DNS processing errors (any RCODE other than 0), or
(any RCODE other than 0), or if no records are returned, or if more if no records are returned, or if more than one record is returned,
than one record is returned, or if there are syntax errors in the or if there are syntax errors in the explanation string, then proceed
explanation string, then proceed as if no exp modifier was given. as if no exp modifier was given.
The fetched TXT record's strings are concatenated with no spaces, and The fetched TXT record's strings are concatenated with no spaces, and
then treated as an <explain-string>, which is macro-expanded. This then treated as an explain-string, which is macro-expanded. This
final result is the explanation string. Implementations MAY limit final result is the explanation string. Implementations MAY limit
the length of the resulting explanation string to allow for other the length of the resulting explanation string to allow for other
protocol constraints and/or reasonable processing limits. Since the protocol constraints and/or reasonable processing limits. Since the
explanation string is intended for an SMTP response and [RFC2821] explanation string is intended for an SMTP response and [RFC2821]
Section 2.4 says that responses are in [US-ASCII], the explanation Section 2.4 says that responses are in [US-ASCII], the explanation
string is also limited to US-ASCII. string is also limited to US-ASCII.
Software evaluating check_host() can use this string to communicate Software evaluating check_host() can use this string to communicate
information from the publishing domain in the form of a short message information from the publishing domain in the form of a short message
or URL. Software SHOULD make it clear that the explanation string or URL. Software SHOULD make it clear that the explanation string
comes from a third party. For example, it can prepend the macro comes from a third party. For example, it can prepend the macro
string "%{o} explains: " to the explanation, such as shown in Section string "%{o} explains: " to the explanation, such as shown in
2.5.4. Section 2.5.4.
Suppose example.com has this record: Suppose example.com has this record:
v=spf1 mx -all exp=explain._spf.%{d} v=spf1 mx -all exp=explain._spf.%{d}
Here are some examples of possible explanation TXT records at Here are some examples of possible explanation TXT records at
explain._spf.example.com: explain._spf.example.com:
"Mail from example.com should only be sent by its own servers." "Mail from example.com should only be sent by its own servers."
-- a simple, constant message -- a simple, constant message
"%{i} is not one of %{d}'s designated mail servers." "%{i} is not one of %{d}'s designated mail servers."
-- a message with a little more information, including the IP -- a message with a little more information, including the IP
address that failed the check address that failed the check
"See http://%{d}/why.html?s=%{S}&i=%{I}" "See http://%{d}/why.html?s=%{S}&i=%{I}"
-- a complicated example that constructs a URL with the -- a complicated example that constructs a URL with the
arguments to check_host() so that a web page can be arguments to check_host() so that a web page can be
generated with detailed, custom instructions generated with detailed, custom instructions
Note: During recursion into an "include" mechanism, an exp= modifier Note: During recursion into an "include" mechanism, an exp= modifier
from the <target-name> MUST NOT be used. In contrast, when executing from the <target-name> MUST NOT be used. In contrast, when executing
a "redirect" modifier, an exp= modifier from the original domain MUST a "redirect" modifier, an exp= modifier from the original domain MUST
NOT be used. NOT be used.
7. The Received-SPF Header Field 7. The Received-SPF Header Field
It is RECOMMENDED that SMTP receivers record the result of SPF It is RECOMMENDED that SMTP receivers record the result of SPF
processing in the message header. If an SMTP receiver chooses to do processing in the message header. If an SMTP receiver chooses to do
skipping to change at page 25, line 48 skipping to change at page 29, line 46
/ "helo" ; for the "HELO" identity / "helo" ; for the "HELO" identity
/ name ; other identities / name ; other identities
dot-atom = <unquoted word as per [RFC2822]> dot-atom = <unquoted word as per [RFC2822]>
quoted-string = <quoted string as per [RFC2822]> quoted-string = <quoted string as per [RFC2822]>
comment = <comment string as per [RFC2822]> comment = <comment string as per [RFC2822]>
CFWS = <comment or folding white space as per [RFC2822]> CFWS = <comment or folding white space as per [RFC2822]>
FWS = <folding white space as per [RFC2822]> FWS = <folding white space as per [RFC2822]>
CRLF = <standard end-of-line token as per [RFC2822]> CRLF = <standard end-of-line token as per [RFC2822]>
The header field SHOULD include a "(...)" style <comment> after the The header field SHOULD include a "(...)" style comment after the
result, conveying supporting information for the result, such as result, conveying supporting information for the result, such as
<ip>, <sender>, and <domain>. <ip>, <sender>, and <domain>.
The following key-value pairs are designed for later machine parsing. The following key-value pairs are designed for later machine parsing.
SPF clients SHOULD give enough information so that the SPF results SPF clients SHOULD give enough information so that the SPF results
can be verified. That is, at least "client-ip", "helo", and, if the can be verified. That is, at least "client-ip", "helo", and, if the
"MAIL FROM" identity was checked, "envelope-from". "MAIL FROM" identity was checked, "envelope-from".
client-ip the IP address of the SMTP client client-ip the IP address of the SMTP client
skipping to change at page 26, line 39 skipping to change at page 30, line 35
SPF clients MUST make sure that the Received-SPF header field does SPF clients MUST make sure that the Received-SPF header field does
not contain invalid characters, is not excessively long, and does not not contain invalid characters, is not excessively long, and does not
contain malicious data that has been provided by the sender. contain malicious data that has been provided by the sender.
Examples of various header styles that could be generated are the Examples of various header styles that could be generated are the
following: following:
Received-SPF: Pass (mybox.example.org: domain of Received-SPF: Pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender) myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1; receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from=<myname@example.com>; helo=foo.example.com; envelope-from="myname@example.com"; helo=foo.example.com;
Received-SPF: Fail (mybox.example.org: domain of Received-SPF: Fail (mybox.example.org: domain of
myname@example.com does not designate myname@example.com does not designate
192.0.2.1 as permitted sender) 192.0.2.1 as permitted sender)
identity=mailfrom; client-ip=192.0.2.1; identity=mailfrom; client-ip=192.0.2.1;
envelope-from=<myname@example.com>; envelope-from="myname@example.com";
8. Macros 8. Macros
8.1. Macro Definitions 8.1. Macro Definitions
Many mechanisms and modifiers perform macro expansion on part of the Many mechanisms and modifiers perform macro expansion on the term.
term.
domain-spec = macro-string domain-end domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) / toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions ; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2) ; (see [RFC3696], Section 2)
alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP ) explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal ) macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-" / "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E macro-literal = %x21-24 / %x26-7E
; visible characters except "%" ; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" "c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ] transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
A literal "%" is expressed by "%%". A literal "%" is expressed by "%%".
"%_" expands to a single " " space. "%_" expands to a single " " space.
"%-" expands to a URL-encoded space, viz., "%20". "%-" expands to a URL-encoded space, viz., "%20".
The following macro letters are expanded in term arguments: The following macro letters are expanded in term arguments:
skipping to change at page 29, line 11 skipping to change at page 32, line 49
interpreter would pretend the DIGIT was 3. Implementations MUST interpreter would pretend the DIGIT was 3. Implementations MUST
support at least a value of 128, as that is the maximum number of support at least a value of 128, as that is the maximum number of
labels in a domain name. labels in a domain name.
The "s" macro expands to the <sender> argument. It is an E-Mail The "s" macro expands to the <sender> argument. It is an E-Mail
address with a localpart, an "@" character, and a domain. The "l" address with a localpart, an "@" character, and a domain. The "l"
macro expands to just the localpart. The "o" macro expands to just macro expands to just the localpart. The "o" macro expands to just
the domain part. Note that these values remain the same during the domain part. Note that these values remain the same during
recursive and chained evaluations due to "include" and/or "redirect". recursive and chained evaluations due to "include" and/or "redirect".
Note also that if the original <sender> had no localpart, the Note also that if the original <sender> had no localpart, the
localpart was set to "postmaster" in initial processing (see Section localpart was set to "postmaster" in initial processing (see
4.3). Section 4.3).
For IPv4 addresses, both the "i" and "c" macros expand to the For IPv4 addresses, both the "i" and "c" macros expand to the
standard dotted-quad format. standard dotted-quad format.
For IPv6 addresses, the "i" macro expands to a dot-format address; it For IPv6 addresses, the "i" macro expands to a dot-format address; it
is intended for use in %{ir}. The "c" macro may expand to any of the is intended for use in %{ir}. The "c" macro may expand to any of the
hexadecimal colon-format addresses specified in [RFC3513], Section hexadecimal colon-format addresses specified in [RFC3513], Section
2.2. It is intended for humans to read. 2.2. It is intended for humans to read.
The "p" macro expands to the validated domain name of <ip>. The The "p" macro expands to the validated domain name of <ip>. The
procedure for finding the validated domain name is defined in Section procedure for finding the validated domain name is defined in
5.5. If the <domain> is present in the list of validated domains, it Section 5.5. If the <domain> is present in the list of validated
SHOULD be used. Otherwise, if a subdomain of the <domain> is domains, it SHOULD be used. Otherwise, if a subdomain of the
present, it SHOULD be used. Otherwise, any name from the list may be <domain> is present, it SHOULD be used. Otherwise, any name from the
used. If there are no validated domain names or if a DNS error list may be used. If there are no validated domain names or if a DNS
occurs, the string "unknown" is used. error occurs, the string "unknown" is used.
The "r" macro expands to the name of the receiving MTA. This SHOULD The "r" macro expands to the name of the receiving MTA. This SHOULD
be a fully qualified domain name, but if one does not exist (as when be a fully qualified domain name, but if one does not exist (as when
the checking is done by a MUA) or if policy restrictions dictate the checking is done by a MUA) or if policy restrictions dictate
otherwise, the word "unknown" SHOULD be substituted. The domain name otherwise, the word "unknown" SHOULD be substituted. The domain name
may be different from the name found in the MX record that the client may be different from the name found in the MX record that the client
MTA used to locate the receiving MTA. MTA used to locate the receiving MTA.
The "t" macro expands to the decimal representation of the The "t" macro expands to the decimal representation of the
approximate number of seconds since the Epoch (Midnight, January 1, approximate number of seconds since the Epoch (Midnight, January 1,
skipping to change at page 29, line 50 skipping to change at page 33, line 39
time() function in most standards-compliant libraries. time() function in most standards-compliant libraries.
When the result of macro expansion is used in a domain name query, if When the result of macro expansion is used in a domain name query, if
the expanded domain name exceeds 253 characters (the maximum length the expanded domain name exceeds 253 characters (the maximum length
of a domain name), the left side is truncated to fit, by removing of a domain name), the left side is truncated to fit, by removing
successive domain labels until the total length does not exceed 253 successive domain labels until the total length does not exceed 253
characters. characters.
Uppercased macros expand exactly as their lowercased equivalents, and Uppercased macros expand exactly as their lowercased equivalents, and
are then URL escaped. URL escaping must be performed for characters are then URL escaped. URL escaping must be performed for characters
not in the "uric" set, which is defined in [RFC3986]. not in the "unreserved" set, which is defined in [RFC3986].
Note: Care must be taken so that macro expansion for legitimate Note: Care must be taken so that macro expansion for legitimate
E-Mail does not exceed the 63-character limit on DNS labels. The E-Mail does not exceed the 63-character limit on DNS labels. The
localpart of E-Mail addresses, in particular, can have more than 63 localpart of E-Mail addresses, in particular, can have more than 63
characters between dots. characters between dots.
Note: Domains should avoid using the "s", "l", "o", or "h" macros in Note: Domains should avoid using the "s", "l", "o", or "h" macros in
conjunction with any mechanism directive. Although these macros are conjunction with any mechanism directive. Although these macros are
powerful and allow per-user records to be published, they severely powerful and allow per-user records to be published, they severely
limit the ability of implementations to cache results of check_host() limit the ability of implementations to cache results of check_host()
skipping to change at page 32, line 37 skipping to change at page 36, line 15
FROM" of a message when re-injecting it for delivery to the external FROM" of a message when re-injecting it for delivery to the external
mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" mailbox. [RFC1123] and [RFC2821] describe this action as an "alias"
rather than a "mail list". This means that the external mailbox's rather than a "mail list". This means that the external mailbox's
MTA sees all such mail in a connection from a host of the forwarding MTA sees all such mail in a connection from a host of the forwarding
service, and so the "MAIL FROM" identity will not, in general, pass service, and so the "MAIL FROM" identity will not, in general, pass
authorization. authorization.
There are three places that techniques can be used to ameliorate this There are three places that techniques can be used to ameliorate this
problem. problem.
1. The beginning, when E-Mail is first sent. 1. The beginning, when E-Mail is first sent.
1. "Neutral" results could be given for IP addresses that may be
forwarders, instead of "Fail" results. For example:
"v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" 1. "Neutral" results could be given for IP addresses that may be
forwarders, instead of "Fail" results. For example:
This would cause a lookup on an anti-spam DNS blacklist "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
(DNSBL) and cause a result of "Fail" only for E-Mail coming
from listed sources. All other E-Mail, including E-Mail sent
through forwarders, would receive a "Neutral" result. By
checking the DNSBL after the known good sources, problems with
incorrect listing on the DNSBL are greatly reduced.
2. The "MAIL FROM" identity could have additional information in This would cause a lookup on an anti-spam DNS blacklist
the localpart that cryptographically identifies the mail as (DNSBL) and cause a result of "Fail" only for E-Mail coming
coming from an authorized source. In this case, such an SPF from listed sources. All other E-Mail, including E-Mail sent
record could be used: through forwarders, would receive a "Neutral" result. By
checking the DNSBL after the known good sources, problems
with incorrect listing on the DNSBL are greatly reduced.
"v=spf1 mx exists:%{l}._spf_verify.%{d} -all" 2. The "MAIL FROM" identity could have additional information in
the localpart that cryptographically identifies the mail as
coming from an authorized source. In this case, such an SPF
record could be used:
Then, a specialized DNS server can be set up to serve the "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
_spf_verify subdomain that validates the localpart. Although
this requires an extra DNS lookup, this happens only when the
E-Mail would otherwise be rejected as not coming from a known
good source.
Note that due to the 63-character limit for domain labels, Then, a specialized DNS server can be set up to serve the
this approach only works reliably if the localpart signature _spf_verify subdomain that validates the localpart. Although
scheme is guaranteed either to only produce localparts with a this requires an extra DNS lookup, this happens only when the
maximum of 63 characters or to gracefully handle truncated E-Mail would otherwise be rejected as not coming from a known
localparts. good source.
Note that due to the 63-character limit for domain labels,
this approach only works reliably if the localpart signature
scheme is guaranteed either to only produce localparts with a
maximum of 63 characters or to gracefully handle truncated
localparts.
3. Similarly, a specialized DNS server could be set up that will 3. Similarly, a specialized DNS server could be set up that will
rate-limit the E-Mail coming from unexpected IP addresses. rate-limit the E-Mail coming from unexpected IP addresses.
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
4. SPF allows the creation of per-user policies for special 4. SPF allows the creation of per-user policies for special
cases. For example, the following SPF record and appropriate cases. For example, the following SPF record and appropriate
wildcard DNS records can be used: wildcard DNS records can be used:
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
2. The middle, when E-Mail is forwarded. 2. The middle, when E-Mail is forwarded.
1. Forwarding services can solve the problem by rewriting the 1. Forwarding services can solve the problem by rewriting the
"MAIL FROM" to be in their own domain. This means that mail "MAIL FROM" to be in their own domain. This means that mail
bounced from the external mailbox will have to be re-bounced bounced from the external mailbox will have to be re-bounced
by the forwarding service. Various schemes to do this exist by the forwarding service. Various schemes to do this exist
though they vary widely in complexity and resource though they vary widely in complexity and resource
requirements on the part of the forwarding service. requirements on the part of the forwarding service.
2. Several popular MTAs can be forced from "alias" semantics to 2. Several popular MTAs can be forced from "alias" semantics to
"mailing list" semantics by configuring an additional alias "mailing list" semantics by configuring an additional alias
with "owner-" prepended to the original alias name (e.g., an with "owner-" prepended to the original alias name (e.g., an
alias of "friends: george@example.com, fred@example.org" would alias of "friends: george@example.com, fred@example.org"
need another alias of the form "owner-friends: localowner"). would need another alias of the form "owner-friends:
localowner").
3. The end, when E-Mail is received. 3. The end, when E-Mail is received.
1. If the owner of the external mailbox wishes to trust the 1. If the owner of the external mailbox wishes to trust the
forwarding service, he can direct the external mailbox's MTA forwarding service, he can direct the external mailbox's MTA
to skip SPF tests when the client host belongs to the to skip SPF tests when the client host belongs to the
forwarding service. forwarding service.
2. Tests against other identities, such as the "HELO" identity, 2. Tests against other identities, such as the "HELO" identity,
may be used to override a failed test against the "MAIL FROM" may be used to override a failed test against the "MAIL FROM"
identity. identity.
3. For larger domains, it may not be possible to have a complete 3. For larger domains, it may not be possible to have a complete
or accurate list of forwarding services used by the owners of or accurate list of forwarding services used by the owners of
the domain's mailboxes. In such cases, whitelists of the domain's mailboxes. In such cases, whitelists of
generally-recognized forwarding services could be employed. generally-recognized forwarding services could be employed.
9.4. Mail Services 9.4. Mail Services
Service providers that offer mail services to third-party domains, Service providers that offer mail services to third-party domains,
such as sending of bulk mail, may want to adjust their setup in light such as sending of bulk mail, may want to adjust their setup in light
of the authorization check described in this document. If the "MAIL of the authorization check described in this document. If the "MAIL
FROM" identity used for such E-Mail uses the domain of the service FROM" identity used for such E-Mail uses the domain of the service
provider, then the provider needs only to ensure that its sending provider, then the provider needs only to ensure that its sending
host is authorized by its own SPF record, if any. host is authorized by its own SPF record, if any.
skipping to change at page 37, line 14 skipping to change at page 41, line 4
10.2. SPF-Authorized E-Mail May Contain Other False Identities 10.2. SPF-Authorized E-Mail May Contain Other False Identities
The "MAIL FROM" and "HELO" identity authorizations must not be The "MAIL FROM" and "HELO" identity authorizations must not be
construed to provide more assurance than they do. It is entirely construed to provide more assurance than they do. It is entirely
possible for a malicious sender to inject a message using his own possible for a malicious sender to inject a message using his own
domain in the identities used by SPF, to have that domain's SPF domain in the identities used by SPF, to have that domain's SPF
record authorize the sending host, and yet the message can easily record authorize the sending host, and yet the message can easily
list other identities in its header. Unless the user or the MUA list other identities in its header. Unless the user or the MUA
takes care to note that the authorized identity does not match the takes care to note that the authorized identity does not match the
other more commonly-presented identities (such as the From: header other more commonly-presented identities (such as the From: header
field), the user may be lulled into a false sense of security. field), the user may be lulled into a false sense of security.
10.3. Spoofed DNS and IP Data 10.3. Spoofed DNS and IP Data
There are two aspects of this protocol that malicious parties could There are two aspects of this protocol that malicious parties could
exploit to undermine the validity of the check_host() function: exploit to undermine the validity of the check_host() function:
o The evaluation of check_host() relies heavily on DNS. A malicious o The evaluation of check_host() relies heavily on DNS. A malicious
attacker could attack the DNS infrastructure and cause attacker could attack the DNS infrastructure and cause
check_host() to see spoofed DNS data, and then return incorrect check_host() to see spoofed DNS data, and then return incorrect
skipping to change at page 39, line 37 skipping to change at page 44, line 20
DNS Parameters Registry for the SPF RR type with code 99. DNS Parameters Registry for the SPF RR type with code 99.
12.2. The Received-SPF Mail Header Field 12.2. The Received-SPF Mail Header Field
Per [RFC3864], the "Received-SPF:" header field is added to the IANA Per [RFC3864], the "Received-SPF:" header field is added to the IANA
Permanent Message Header Field Registry. The following is the Permanent Message Header Field Registry. The following is the
registration template: registration template:
Header field name: Received-SPF Header field name: Received-SPF
Applicable protocol: mail ([RFC2822]) Applicable protocol: mail ([RFC2822])
Status: Experimental Status: Standards Track
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): RFC 4408 Specification document(s): RFC XXXX
Related information:
Requesting SPF Council review of any proposed changes and
additions to this field are recommended. For information about
the SPF Council see http://www.openspf.org/Council
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
2001. April 2001.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January for Delivery Status Notifications", RFC 3464,
2003. January 2003.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, January 2005.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[US-ASCII] American National Standards Institute (formerly United [US-ASCII]
American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange, X3.4", 1968. Information Interchange, X3.4", 1968.
ANSI X3.4-1968 has been replaced by newer versions with slight ANSI X3.4-1968 has been replaced by newer versions with
modifications, but the 1968 version remains definitive for slight modifications, but the 1968 version remains
the Internet. definitive for the Internet.
13.2 Informative References 13.2. Informative References
[DMP] Fecyk, G., "Designated Mailers Protocol".
Work In Progress
[Green] Green, D., "Domain-Authorized SMTP Mail", 2002.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983,
1996. August 1996.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, November 1998. "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2554] Myers, J., "SMTP Service Extension for Authentication", [RFC2554] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999. RFC 2554, March 1999.
[RFC3696] Klensin, J., "Application Techniques for Checking and [RFC3696] Klensin, J., "Application Techniques for Checking and
Transformation of Names", RFC 3696, February 2004. Transformation of Names", RFC 3696, February 2004.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
RFC 4409, April 2006. RFC 4409, April 2006.
[RMX] Danish, H., "The RMX DNS RR Type for light weight sender [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
authentication", Work In Progress J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009.
[Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender
authentication".
[Green] Green, D., "Domain-Authorized SMTP Mail", 2002. Work In Progress
[Vixie] Vixie, P., "Repudiating MAIL FROM", 2002.
Appendix A. Collected ABNF Appendix A. Collected ABNF
This section is normative and any discrepancies with the ABNF This section is normative and any discrepancies with the ABNF
fragments in the preceding text are to be resolved in favor of this fragments in the preceding text are to be resolved in favor of this
grammar. grammar.
See [RFC4234] for ABNF notation. Please note that as per this ABNF See [RFC4234] for ABNF notation. Please note that as per this ABNF
definition, literal text strings (those in quotes) are case- definition, literal text strings (those in quotes) are case-
insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
skipping to change at page 42, line 38 skipping to change at page 48, line 38
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
PTR = "ptr" [ ":" domain-spec ] PTR = "ptr" [ ":" domain-spec ]
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string
; where name is not any known modifier
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0 ; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 3513], section 2.2> ip6-network = <as per [RFC 3513], section 2.2>
; e.g., 2001:DB8::CD30 ; e.g., 2001:DB8::CD30
domain-spec = macro-string domain-end domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) / toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions ; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2) ; (see [RFC3696], Section 2)
alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP ) explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal ) macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-" / "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E macro-literal = %x21-24 / %x26-7E
; visible characters except "%" ; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
skipping to change at page 44, line 49 skipping to change at page 51, line 4
$ORIGIN 0.0.10.in-addr.arpa. $ORIGIN 0.0.10.in-addr.arpa.
4 PTR bob.example.com. 4 PTR bob.example.com.
B.1. Simple Examples B.1. Simple Examples
These examples show various possible published records for These examples show various possible published records for
example.com and which values if <ip> would cause check_host() to example.com and which values if <ip> would cause check_host() to
return "Pass". Note that <domain> is "example.com". return "Pass". Note that <domain> is "example.com".
v=spf1 +all v=spf1 +all
-- any <ip> passes -- any <ip> passes
v=spf1 a -all v=spf1 a -all
-- hosts 192.0.2.10 and 192.0.2.11 pass -- hosts 192.0.2.10 and 192.0.2.11 pass
v=spf1 a:example.org -all v=spf1 a:example.org -all
-- no sending hosts pass since example.org has no A records -- no sending hosts pass since example.org has no A records
v=spf1 mx -all v=spf1 mx -all
-- sending hosts 192.0.2.129 and 192.0.2.130 pass -- sending hosts 192.0.2.129 and 192.0.2.130 pass
v=spf1 mx:example.org -all v=spf1 mx:example.org -all
-- sending host 192.0.2.140 passes -- sending host 192.0.2.140 passes
v=spf1 mx mx:example.org -all v=spf1 mx mx:example.org -all
-- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
v=spf1 mx/30 mx:example.org/30 -all v=spf1 mx/30 mx:example.org/30 -all
-- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
v=spf1 ptr -all v=spf1 ptr -all
-- sending host 192.0.2.65 passes (reverse DNS is valid and is in -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
example.com) example.com)
-- sending host 192.0.2.140 fails (reverse DNS is valid, but not -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
in example.com) in example.com)
-- sending host 10.0.0.4 fails (reverse IP is not valid) -- sending host 10.0.0.4 fails (reverse IP is not valid)
v=spf1 ip4:192.0.2.128/28 -all v=spf1 ip4:192.0.2.128/28 -all
-- sending host 192.0.2.65 fails -- sending host 192.0.2.65 fails
-- sending host 192.0.2.129 passes -- sending host 192.0.2.129 passes
B.2. Multiple Domain Example B.2. Multiple Domain Example
These examples show the effect of related records: These examples show the effect of related records:
example.org: "v=spf1 include:example.com include:example.net -all" example.org: "v=spf1 include:example.com include:example.net -all"
This record would be used if mail from example.org actually came This record would be used if mail from example.org actually came
through servers at example.com and example.net. Example.org's through servers at example.com and example.net. Example.org's
designated servers are the union of example.com's and example.net's designated servers are the union of example.com's and example.net's
skipping to change at page 46, line 10 skipping to change at page 52, line 12
These records allow a set of domains that all use the same mail These records allow a set of domains that all use the same mail
system to make use of that mail system's record. In this way, only system to make use of that mail system's record. In this way, only
the mail system's record needs to be updated when the mail setup the mail system's record needs to be updated when the mail setup
changes. These domains' records never have to change. changes. These domains' records never have to change.
B.3. DNSBL Style Example B.3. DNSBL Style Example
Imagine that, in addition to the domain records listed above, there Imagine that, in addition to the domain records listed above, there
are these: are these:
$ORIGIN _spf.example.com. mary.mobile-users A $ORIGIN _spf.example.com.
127.0.0.2 fred.mobile-users A 127.0.0.2 mary.mobile-users A 127.0.0.2
fred.mobile-users A 127.0.0.2
15.15.168.192.joel.remote-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2
16.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
The following records describe users at example.com who mail from The following records describe users at example.com who mail from
arbitrary servers, or who mail from personal servers. arbitrary servers, or who mail from personal servers.
example.com: example.com:
v=spf1 mx v=spf1 mx
include:mobile-users._spf.%{d} include:mobile-users._spf.%{d}
skipping to change at page 47, line 5 skipping to change at page 53, line 5
"-include:ip4._spf.%{d} " "-include:ip4._spf.%{d} "
"-include:ptr._spf.%{d} " "-include:ptr._spf.%{d} "
"+all" ) "+all" )
ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
ptr._spf.example.com. SPF "v=spf1 -ptr +all" ptr._spf.example.com. SPF "v=spf1 -ptr +all"
This example shows how the "-include" mechanism can be useful, how an This example shows how the "-include" mechanism can be useful, how an
SPF record that ends in "+all" can be very restrictive, and the use SPF record that ends in "+all" can be very restrictive, and the use
of De Morgan's Law. of De Morgan's Law.
Authors' Addresses Appendix C. Change History
Meng Weng Wong Changes since RFC 4408 (to be removed prior to publication)
Singapore
EMail: mengwong+spf@pobox.com Moved to standards track
Wayne Schlitt Authors updated
4615 Meredeth #9
Lincoln Nebraska, NE 68506
United States of America
EMail: wayne@schlitt.net IESG Note regarding experimental use replaced with discussion of
URI: http://www.schlitt.net/spf/ results
Full Copyright Statement Process errata:
Copyright (C) The Internet Society (2006). Add %v macro to ABNF grammar
This document is subject to the rights, licenses and restrictions Replace "uric" by "unreserved"
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an Recommend an SMTP reply code for optional PermError rejections
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Correct syntax in Received-SPF examples
The IETF takes no position regarding the validity or scope of any Fix unknown-modifier clause is too greedy in ABNF
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Correct use of empty domain-spec on exp modifier
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Fix minor typo errata
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement Appendix D. TODO
Funding for the RFC Editor function is provided by the IETF Finish errata (PermError on invalid domains after macro expansion)
Administrative Support Activity (IASA).
Review DNS RCODE/TempError criteria
Review SPF test suite ambiguous results for additional errata
Authors' Addresses
D. Scott Kitterman
3611 Scheel Dr
Ellicott City, MD 21042
United States of America
Email: scott@kitterman.com
Wayne Schlitt
4615 Meredeth #9
Lincoln Nebraska, NE 68506
United States of America
Email: wayne@schlitt.net
URI: http://www.schlitt.net/spf/
 End of changes. 96 change blocks. 
333 lines changed or deleted 345 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart5176285.t3OJvF5UHl-- From sm@elandsys.com Fri Dec 14 12:29:35 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620BE21F8B07 for ; Fri, 14 Dec 2012 12:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN02QaZZ0E+j for ; Fri, 14 Dec 2012 12:29:34 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9055621F8B04 for ; Fri, 14 Dec 2012 12:29:34 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.159.202]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qBEKTLwd006878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 14 Dec 2012 12:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1355516971; bh=L7uDfZSXCPK5p7cTKulOXfvUXCaWL0lxzTpMZtMiYGA=; h=Date:To:From:Subject:In-Reply-To:References; b=A5puFBjphqvpT2TzQf2M9cDfsiudf3vfDTkoeNFc7MnSm6caVk6JZXoYfVzOw/sqH x7TLtY7888wVT1RZ0GbSap4SUmmQDAjrYYbNtQGkyCU5Y94QtEo7w1P9XVg3H4k5FO XNLd5tG4jziGMewPOQ5nc8EFr3WEvkPJYrMBwJiU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1355516971; i=@elandsys.com; bh=L7uDfZSXCPK5p7cTKulOXfvUXCaWL0lxzTpMZtMiYGA=; h=Date:To:From:Subject:In-Reply-To:References; b=iKtcqG6Masqprwc6LGKY/xw5JVSe5Q2z21PsVWo0oXWr+vIIvCHwLRyZBmh2GW/Lh sGgoolPpLluHWYg3ahou6qm5RrmgjQo5M6zzZhuJH60rFI6GiSajX7Y2qWlT/u4DgN uvar8R/1knoek0pD5eYjvcT6xiqVMmdkgLOQ2jp8= Message-Id: <6.2.5.6.2.20121214122344.0b306450@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 14 Dec 2012 12:28:26 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <1758411.Z4lZWUANF0@scott-latitude-e6320> References: <1758411.Z4lZWUANF0@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] RFC 4408 to draft-ietf-spfbis-4408bis-08 difference X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 20:29:35 -0000 Hi Scott, At 12:06 14-12-2012, Scott Kitterman wrote: >The current diff from RFC 4408 is attached in rfcdiff format. So the answer From the message at http://www.ietf.org/mail-archive/web/spfbis/current/msg03053.html "1. Perform a diff between the most recent WG document (08) and RFC 4408. This allows us to document precisely any differences between the current state of work and the starting point of the WG." The diff that was posted was between RFC 4408 and draft-kitterman-4408bis-00. Could you please fix? Thanks, S. Moonesamy From spf2@kitterman.com Fri Dec 14 13:11:19 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A33721F8AD5 for ; Fri, 14 Dec 2012 13:11:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZTMFBzl1Tob for ; Fri, 14 Dec 2012 13:11:15 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA2221F8AC6 for ; Fri, 14 Dec 2012 13:11:15 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 482E3D04080; Fri, 14 Dec 2012 15:11:14 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1355519474; bh=ytvTkqR5J2ZranUJNwC4ramnSCg+lUqZXfZhp7oxyaw=; h=In-Reply-To:References:Subject:From:Date:To:From; b=SuKbk0GzdzslxiCJe6mt2snNAhReWmrsdVlG/TBlyVUYprk+oA47YFTPZGzS+Bqvz c3pqU3fY8NHBe/IsZE4N4MjfrgOzzkF4FxoznXAYamU26PSAeBMsa2ifNeQKI3d04h TQ71tmTX9YuHZb1wPoUK7DDWSQ3rjmfWKoIWH8os= Received: from [IPV6:2600:1003:b024:c195:2d58:ff81:8f11:3f5c] (unknown [IPv6:2600:1003:b024:c195:2d58:ff81:8f11:3f5c]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E2C52D0405B; Fri, 14 Dec 2012 15:11:13 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20121214122344.0b306450@resistor.net> References: <1758411.Z4lZWUANF0@scott-latitude-e6320> <6.2.5.6.2.20121214122344.0b306450@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Fri, 14 Dec 2012 16:11:10 -0500 To: spfbis@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 to draft-ietf-spfbis-4408bis-08 difference X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 21:11:19 -0000 Yes. Sorry about that and thanks for catching it. Scott K From spf2@kitterman.com Fri Dec 14 18:20:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE65821F8B4A for ; Fri, 14 Dec 2012 18:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfYXGL5Ca1Gt for ; Fri, 14 Dec 2012 18:20:56 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 63AF821F8B35 for ; Fri, 14 Dec 2012 18:20:44 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5EE1920E40CF; Fri, 14 Dec 2012 21:20:38 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1355538042; bh=t+v11xQNKmVLwns3sE2R1cOTzSthTzQm6OzFhv9yfCc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=eGyaRmOAx7LM/kIY3GlvL37Bqa31D86fQRkXwAHG/iI0avydRDXxN9LpuxvkeAsXY CTJlnOXwEc/Tx+tW7sfAvPX0NY59HXCeyWMBUtdQuEuCcOGs9QjZ+SPS5Y0Jw/hmvD zT2T7lTJx+I8+pkoscvjHf6+EMp0Ex79heMXS13o= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 6026520E407B; Fri, 14 Dec 2012 21:20:36 -0500 (EST) From: Scott Kitterman To: spfbis@ietf.org Date: Fri, 14 Dec 2012 21:20:35 -0500 Message-ID: <1694569.lX5zHpQNXS@scott-latitude-e6320> User-Agent: KMail/4.9.3 (Linux/3.5.0-21-generic; KDE/4.9.3; i686; ; ) In-Reply-To: <6.2.5.6.2.20121214122344.0b306450@resistor.net> References: <1758411.Z4lZWUANF0@scott-latitude-e6320> <6.2.5.6.2.20121214122344.0b306450@resistor.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart42364935.Jmi9YR0pFl" Content-Transfer-Encoding: 7Bit X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] RFC 4408 to draft-ietf-spfbis-4408bis-08 difference X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 02:20:59 -0000 This is a multi-part message in MIME format. --nextPart42364935.Jmi9YR0pFl Content-Type: multipart/alternative; boundary="nextPart1485834.jITXE1tHj5" Content-Transfer-Encoding: 7Bit This is a multi-part message in MIME format. --nextPart1485834.jITXE1tHj5 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="iso-8859-1" rfc4408.txt draft-ietf-spfbis-4408bis-08.txt Network Working Group M. Wong Network Working Group S. Kitterman Request for Comments: 4408 W. Schlitt Internet-Draft Kitterman Technical Services Category: Experimental April 2006 Obsoletes: 4408 (if approved) October 22, 2012 Intended status: Standards Track Sender Policy Framework (SPF) for Expires: April 25, 2013 Authorizing Use of Domains in E-Mail, Version 1 Status of This Memo Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 draft-ietf-spfbis-4408bis-08.txt This memo defines an Experimental Protocol for the Internet Abstract community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. Copyright (C) The Internet Society (2006). This document obsoletes RFC4408. IESG Note Status of this Memo The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) This Internet-Draft is submitted in full conformance with the are published simultaneously as Experimental RFCs, although there is provisions of BCP 78 and BCP 79. no general technical consensus and efforts to reconcile the two approaches have failed. As such, these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group. The IESG takes no position about which approach is to be preferred Internet-Drafts are working documents of the Internet Engineering and cautions the reader that there are serious open issues for each Task Force (IETF). Note that other groups may also distribute approach and concerns about using them in tandem. The IESG believes working documents as Internet-Drafts. The list of current Internet- that documenting the different approaches does less harm than not Drafts is at http://datatracker.ietf.org/drafts/current/. documenting them. Note that the Sender ID experiment may use DNS records that may have Internet-Drafts are draft documents valid for a maximum of six months been created for the current SPF experiment or earlier versions in and may be updated, replaced, or obsoleted by other documents at any this set of experiments. Depending on the content of the record, time. It is inappropriate to use Internet-Drafts as reference this may mean that Sender-ID heuristics would be applied incorrectly material or to cite them other than as "work in progress." to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt. Participants relying on Sender ID experiment DNS records are warned This Internet-Draft will expire on April 25, 2013. that they may lose valid messages in this set of circumstances. aParticipants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict. Participants in the Sender-ID experiment need to be aware that the Copyright Notice way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem. The community is invited to observe the success or failure of the two Copyright (c) 2012 IETF Trust and the persons identified as the approaches during the two years following publication, in order that document authors. All rights reserved. a community consensus can be reached in the future. Abstract This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. E-mail on the Internet can be forged in a number of ways. In This document may contain material from IETF Documents or IETF particular, existing protocols place no restriction on what a sending Contributions published or made publicly available before November host can use as the reverse-path of a message or the domain given on 10, 2008. The person(s) controlling the copyright in some of this the SMTP HELO/EHLO commands. This document describes version 1 of material may not have granted the IETF Trust the right to allow the Sender Policy Framework (SPF) protocol, whereby a domain may modifications of such material outside the IETF Standards Process. explicitly authorize the hosts that are allowed to use its domain Without obtaining an adequate license from the person(s) controlling name, and a receiving host may check such authorization. the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents Table of Contents 1. Introduction ....................................................4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Protocol Status ............................................4 1.1. Protocol Status . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology ................................................5 1.2. Experimental History . . . . . . . . . . . . . . . . . . . 7 2. Operation .......................................................5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. The HELO Identity ..........................................5 1.3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. The MAIL FROM Identity .....................................5 1.3.2. Imported Definitions . . . . . . . . . . . . . . . . . 7 2.3. Publishing Authorization ...................................6 1.3.3. Mail From Definition . . . . . . . . . . . . . . . . . 7 2.4. Checking Authorization .....................................6 1.3.4. HELO Definition . . . . . . . . . . . . . . . . . . . 8 2.5. Interpreting the Result ....................................7 1.3.5. Deprecated . . . . . . . . . . . . . . . . . . . . . . 8 2.5.1. None ................................................8 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.2. Neutral .............................................8 2.1. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9 2.5.3. Pass ................................................8 2.2. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 9 2.5.4. Fail ................................................8 2.3. Publishing Authorization . . . . . . . . . . . . . . . . . 9 2.5.5. SoftFail ............................................9 2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 10 2.5.6. TempError ...........................................9 2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 11 2.5.7. PermError ...........................................9 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. SPF Records .....................................................9 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Publishing ................................................10 2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1. DNS Resource Record Types ..........................10 2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2. Multiple DNS Records ...............................11 2.5.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.3. Multiple Strings in a Single DNS record ............11 2.5.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 13 3.1.4. Record Size ........................................11 2.5.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 13 3.1.5. Wildcard Records ...................................11 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 14 4. The check_host() Function ......................................12 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 15 4.1. Arguments .................................................12 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 15 4.2. Results ...................................................13 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Initial Processing ........................................13 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 15 4.4. Record Lookup .............................................13 4. The check_host() Function . . . . . . . . . . . . . . . . . . 17 4.5. Selecting Records .........................................13 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. Record Evaluation .........................................14 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6.1. Term Evaluation ....................................14 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 17 4.6.2. Mechanisms .........................................15 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 18 4.6.3. Modifiers ..........................................15 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 18 4.7. Default Result ............................................16 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 18 4.8. Domain Specification ......................................16 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 19 5. Mechanism Definitions ..........................................16 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 19 5.1. "all" .....................................................17 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 20 5.2. "include" .................................................18 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 20 5.3. "a" .......................................................19 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 21 5.4. "mx" ......................................................20 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 21 5.5. "ptr" .....................................................20 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 22 5.6. "ip4" and "ip6" ...........................................21 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.7. "exists" ..................................................22 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Modifier Definitions ...........................................22 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. redirect: Redirected Query ................................23 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2. exp: Explanation ..........................................23 5.5. "ptr" (deprecated) . . . . . . . . . . . . . . . . . . . . 25 7. The Received-SPF Header Field ..................................25 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 27 8. Macros .........................................................27 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Macro Definitions .........................................27 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 29 8.2. Expansion Examples ........................................30 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 29 9. Implications ...................................................31 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 30 9.1. Sending Domains ...........................................31 7. Recording The Result . . . . . . . . . . . . . . . . . . . . . 32 9.2. Mailing Lists .............................................32 7.1. The Received-SPF Header Field . . . . . . . . . . . . . . 32 9.3. Forwarding Services and Aliases ...........................32 7.2. SPF Results in the Authentication-Results Header Field . . 34 9.4. Mail Services .............................................34 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.5. MTA Relays ................................................34 8.1. Macro Definitions . . . . . . . . . . . . . . . . . . . . 36 10. Security Considerations .......................................35 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 39 10.1. Processing Limits ........................................35 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 41 10.2. SPF-Authorized E-Mail May Contain Other False 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 41 Identities ...............................................37 9.1.1. DNS Resource Considerations . . . . . . . . . . . . . 41 10.3. Spoofed DNS and IP Data ..................................37 9.1.2. Administrator's Considerations . . . . . . . . . . . . 42 10.4. Cross-User Forgery .......................................37 9.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 43 10.5. Untrusted Information Sources ............................38 9.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 43 10.6. Privacy Exposure .........................................38 9.2.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 43 11. Contributors and Acknowledgements .............................38 9.2.2. Forwarding Services and Aliases . . . . . . . . . . . 44 12. IANA Considerations ...........................................39 9.2.3. Mail Services . . . . . . . . . . . . . . . . . . . . 46 12.1. The SPF DNS Record Type ..................................39 9.2.4. MTA Relays . . . . . . . . . . . . . . . . . . . . . . 46 12.2. The Received-SPF Mail Header Field .......................39 9.3. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 47 13. References ....................................................39 9.3.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . 47 13.1. Normative References .....................................39 9.3.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . 47 13.2. Informative References ...................................40 9.3.3. Policy For SPF Permerror . . . . . . . . . . . . . . . 48 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 Appendix A. Collected ABNF .......................................42 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 49 Appendix B. Extended Examples ....................................44 10.2. SPF-Authorized Email May Contain Other False Identities . 49 B.1. Simple Examples ..........................................44 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 50 B.2. Multiple Domain Example ..................................45 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 50 B.3. DNSBL Style Example ......................................46 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 50 B.4. Multiple Requirements Example ............................46 10.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 50 10.5.2. External Explanations . . . . . . . . . . . . . . . . 51 10.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 51 10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 51 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 52 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 53 12.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 53 12.3. SPF Modifier Registration . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.1. Normative References . . . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . . 55 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 57 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 60 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 60 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 61 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 62 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 62 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 66 1. Introduction 1. Introduction The current E-Mail infrastructure has the property that any host The current email infrastructure has the property that any host injecting mail into the mail system can identify itself as any domain injecting mail into the system can use any DNS domain name it wants name it wants. Hosts can do this at a variety of levels: in in each of the various identifiers specified by [RFC5321] and particular, the session, the envelope, and the mail headers. [RFC5322]. Although this feature is desirable in some circumstances, Although this feature is desirable in some circumstances, it is a it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). spam). Furthermore, many domain owning ADMDs (ADministrative Furthermore, many domain name holders are understandably concerned Management Domains, see [RFC5598]) are understandably concerned about about the ease with which other entities may make use of their domain the ease with which other entities can make use of their domain names, often with malicious intent. names, often with malicious intent. This document defines a protocol by which domain owners may authorize This document defines a protocol by which ADMDs can authorize hosts hosts to use their domain name in the "MAIL FROM" or "HELO" identity. to use their domain names in the "MAIL FROM" or "HELO" identities. Compliant domain holders publish Sender Policy Framework (SPF) Compliant ADMDs publish Sender Policy Framework (SPF) records in the records specifying which hosts are permitted to use their names, and DNS specifying which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the compliant mail receivers use the published SPF records to test the authorization of sending Mail Transfer Agents (MTAs) using a given authorization of sending Mail Transfer Agents (MTAs) using a given "HELO" or "MAIL FROM" identity during a mail transaction. "HELO" or "MAIL FROM" identity during a mail transaction. An additional benefit to mail receivers is that after the use of an An additional benefit to mail receivers is that after the use of an identity is verified, local policy decisions about the mail can be identity is verified, local policy decisions about the mail can be made based on the sender's domain, rather than the host's IP address. made based on the sender's domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses. Furthermore, be more accurate than reputation of host IP addresses. Furthermore, if a claimed identity fails verification, local policy can take if a claimed identity fails verification, local policy can take stronger action against such E-Mail, such as rejecting it. stronger action against such email, such as rejecting it. 1.1. Protocol Status 1.1. Protocol Status SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many discussed and debated in development forums. discussed and debated in development forums. The protocol was originally defined in [RFC4408], which this document replaces. The goal of this document is to clearly document the protocol defined [RFC4408] was designed to clearly document the protocol defined by by earlier draft specifications of SPF as used in existing earlier draft specifications of SPF as used in existing implementations. This conception of SPF is sometimes called "SPF implementations. This updated specification is intended to clarify Classic". It is understood that particular implementations and identified ambiguities in [RFC4408], resolve techincal issues deployments may differ from, and build upon, this work. It is hoped identified in post-RFC 4408 deplyment experience, and document widely that we have nonetheless captured the common understanding of SPF deployed extensions to SPF that have been developed since [RFC4408] version 1. was published. 1.2. Terminology 1.2. Experimental History This document updates and replaces RFC 4408 that was part of a group of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the community observe the success or failure of the two approaches documented in these RFCs during the two years following publication, in order that a community consensus could be reached in the future. SPF is widely deployed by large and small email providers alike. There are multiple, interoperable implementations. For SPF (as documented in RFC 4408) a careful effort was made to collect and document lessons learned and errata during the two year period. The errata list has been stable (no new submissions) and only minor protocol lessons learned were identified. Resolution of the IESG's experiment is documented in [RFC6686]. 1.3. Terminology 1.3.1. Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3.2. Imported Definitions The ABNF tokens "ALPHA", "DIGIT", and "SP" are defined in [RFC5234]. The token "local-part" is defined in [RFC5321]. "dot-atom", "quoted-string", "comment", "CFWS", "FWS", and "CRLF" are defined in [RFC5322]. 1.3.3. Mail From Definition This document is concerned with the portion of a mail message This document is concerned with the portion of a mail message commonly called "envelope sender", "return path", "reverse path", commonly called "envelope sender", "return path", "reverse path", "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom. either not well defined or often used casually, this document defines Since these terms are either not well defined or often used casually, the "MAIL FROM" identity in Section 2.2. Note that other terms that this document uses "MAIL FROM" for consistency. This means the may superficially look like the common terms, such as "reverse-path", RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that are used only with the defined meanings from normative documents. might superficially look like the common terms, such as "reverse- path", are used only with the defined meanings from normative documents. 2. Operation 1.3.4. HELO Definition 2.1. The HELO Identity This document also makes use of the HELO/EHLO identity. The "HELO" identity derives from either the SMTP HELO or EHLO command (see [RFC5321]). Since HELO and EHLO can, in many cases, be used interchangeably, they are identified commonly as "HELO" in this document. This means RFC5321.HELO/.EHLO as defined in [RFC5598]. These commands supply the identity of the SMTP client (sending host) for the SMTP session. The "HELO" identity derives from either the SMTP HELO or EHLO command 1.3.5. Deprecated (see [RFC2821]). These commands supply the SMTP client (sending host) for the SMTP session. Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF clients must be prepared for the "HELO" identity to be malformed or an IP address literal. At the time of this writing, many legitimate E-Mails are delivered with invalid HELO domains. It is RECOMMENDED that SPF clients not only check the "MAIL FROM" There are [RFC4408] features that are marked "deprecated". In the context of this document, deprecated means that senders SHOULD NOT publish SPF records that make use of such features because they might be removed entirely in future updates to the protocol. Such features do, however, remain part of the SPF protocol and receiving systems MUST support them unless this document explicitly says otherwise. 2. Operation 2.1. The "HELO" Identity It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity, but also separately check the "HELO" identity by applying identity, but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the the check_host() function (Section 4) to the "HELO" identity as the . . Checking "HELO" promotes consistency of results and can reduce DNS resource usage. Additionally, since SPF records published for "HELO" identities refer to a single host, when available, they are a very reliable source of host authorization status. 2.2. The MAIL FROM Identity Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF verifiers MUST be prepared for the "HELO" identity to be malformed or an IP address literal. This SPF check can only be performed when the "HELO" string is a valid fully qualified domain. The "MAIL FROM" identity derives from the SMTP MAIL command (see 2.2. The "MAIL FROM" Identity [RFC2821]). This command supplies the "reverse-path" for a message, which generally consists of the sender mailbox, and is the mailbox to which notification messages are to be sent if there are problems delivering the message. [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in SPF verifiers MUST check the ""MAIL FROM" identity if a completed RFC 2821). In this case, there is no explicit sender mailbox, and "HELO" check has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the . [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in [RFC5321]). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the defines the "MAIL FROM" identity to be the mailbox composed of the localpart "postmaster" and the "HELO" identity (which may or may not local-part "postmaster" and the "HELO" identity (which might or might have been checked separately before). not have been checked separately before). SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the . 2.3. Publishing Authorization 2.3. Publishing Authorization An SPF-compliant domain MUST publish a valid SPF record as described An SPF-compliant domain MUST have valid SPF records as described in in Section 3. This record authorizes the use of the domain name in Section 3. These records authorize the use of the relevant domain the "HELO" and "MAIL FROM" identities by the MTAs it specifies. names in the "HELO" and "MAIL FROM" identities by the MTAs specified therein. If domain owners choose to publish SPF records, it is RECOMMENDED SPF results can be used to make both positive (source is authorized) that they end in "-all", or redirect to other records that do, so and negative (source is not authorized) determinations. If domain that a definitive determination of authorization can be made. owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. Potential issues and mitigations associated with negative determinations are discussed in Section 9. Domain holders may publish SPF records that explicitly authorize no ADMDs can publish SPF records that explicitly authorize no hosts for hosts if mail should never originate using that domain. domain names that are neither used in the domain part of email addresses nor expected to originate mail. When changing SPF records, care must be taken to ensure that there is When changing SPF records, care has to be taken to ensure that there a transition period so that the old policy remains valid until all is a transition period so that the old policy remains valid until all legitimate E-Mail has been checked. legitimate email can reasonably expect to have been checked. This can be as much as 30 days. 2.4. Checking Authorization 2.4. Checking Authorization A mail receiver can perform a set of SPF checks for each mail message A mail receiver can perform a set of SPF checks for each mail message it receives. An SPF check tests the authorization of a client host it receives. An SPF check tests the authorization of a client host to emit mail with a given identity. Typically, such checks are done to emit mail with a given identity. Typically, such checks are done by a receiving MTA, but can be performed elsewhere in the mail by a receiving MTA, but can be performed elsewhere in the mail processing chain so long as the required information is available and processing chain so long as the required information is available and reliable. At least the "MAIL FROM" identity MUST be checked, but it reliable. At least the "MAIL FROM" identity MUST be checked, but it is RECOMMENDED that the "HELO" identity also be checked beforehand. is RECOMMENDED that the "HELO" identity also be checked beforehand. Without explicit approval of the domain owner, checking other Without explicit approval of the domain owner, checking other identities against SPF version 1 records is NOT RECOMMENDED because identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. For there are cases that are known to give incorrect results. For example, almost all mailing lists rewrite the "MAIL FROM" identity example, almost all mailing lists rewrite the "MAIL FROM" identity (see Section 9.2), but some do not change any other identities in the (see Section 9.2.1), but some do not change any other identities in message. The scenario described in Section 9.3, sub-section 1.2, is the message. The scenario described in Section 9.2.2, sub-section another example. Documents that define other identities should 1.2, is another example. Documents that define other identities will define the method for explicit approval. have to define the method for explicit approval. It is possible that mail receivers will use the SPF check as part of It is possible that mail receivers will use the SPF check as part of a larger set of tests on incoming mail. The results of other tests a larger set of tests on incoming mail. The results of other tests may influence whether or not a particular SPF check is performed. might influence whether or not a particular SPF check is performed. For example, finding the sending host's IP address on a local white For example, finding the sending host's IP address on a local white list may cause all other tests to be skipped and all mail from that list might cause all other tests to be skipped and all mail from that host to be accepted. host to be accepted. When a mail receiver decides to perform an SPF check, it MUST use a When a mail receiver decides to perform an SPF check, it MUST use a correctly-implemented check_host() function (Section 4) evaluated correctly-implemented check_host() function (Section 4) evaluated with the correct parameters. Although the test as a whole is with the correct parameters. Although the test as a whole is optional, once it has been decided to perform a test it must be optional, once it has been decided to perform a test it has to be performed as specified so that the correct semantics are preserved performed as specified so that the correct semantics are preserved between publisher and receiver. between publisher and receiver. To make the test, the mail receiver MUST evaluate the check_host() To make the test, the mail receiver MUST evaluate the check_host() function with the arguments set as follows: function with the arguments set as follows: - the IP address of the SMTP client that is emitting the - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. mail, either IPv4 or IPv6. - the domain portion of the "MAIL FROM" or "HELO" identity. - the domain portion of the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. Note that the argument may not be a well-formed domain name. Note that the argument might not be a well-formed domain For example, if the reverse-path was null, then the EHLO/HELO domain name. For example, if the reverse-path was null, then the EHLO/HELO is used, with its associated problems (see Section 2.1). In these domain is used, with its associated problems (see Section 2.1). In cases, check_host() is defined in Section 4.3 to return a "None" these cases, check_host() is defined in Section 4.3 to return a result. "none" result. Although invalid, malformed, or non-existent domains cause SPF checks Although invalid, malformed, or non-existent domains cause SPF checks to return "None" because no SPF record can be found, it has long been to return "none" because no SPF record can be found, it has long been the policy of many MTAs to reject E-Mail from such domains, the policy of many MTAs to reject email from such domains, especially especially in the case of invalid "MAIL FROM". In order to prevent in the case of invalid "MAIL FROM". Rejecting email will prevent one the circumvention of SPF records, rejecting E-Mail from invalid method of circumventing of SPF records. domains should be considered. Implementations must take care to correctly extract the from Implementations have to take care to correctly extract the the data given with the SMTP MAIL FROM command as many MTAs will from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes (see [RFC2821], Appendix still accept such things as source routes (see [RFC5321], Appendix C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These archaic features have been maliciously used to bypass security These archaic features have been maliciously used to bypass security systems. systems. 2.5. Interpreting the Result 2.5. Interpreting the Result This section describes how software that performs the authorization This section describes how software that performs the authorization should interpret the results of the check_host() function. The interprets the results of the check_host() function. The authorization check SHOULD be performed during the processing of the authorization check SHOULD be performed during the processing of the SMTP transaction that sends the mail. This allows errors to be SMTP transaction that sends the mail. This allows errors to be returned directly to the sending MTA by way of SMTP replies. returned directly to the sending MTA by way of SMTP replies. Performing the authorization after the SMTP transaction has finished Performing the authorization other than using the return-path and may cause problems, such as the following: (1) It may be difficult to client address at the time of the MAIL command during the SMTP accurately extract the required information from potentially transaction can cause problems, such as the following: (1) It might deceptive headers; (2) legitimate E-Mail may fail because the be difficult to accurately extract the required information from sender's policy may have since changed. potentially deceptive headers; (2) legitimate email might fail because the sender's policy had since changed. Generating non-delivery notifications to forged identities that have Generating non-delivery notifications to forged identities that have failed the authorization check is generally abusive and against the failed the authorization check is a source of backscatter and SHOULD explicit wishes of the identity owner. be avoided. [RFC3834] section 2 describes backscatter and the problems it causes. 2.5.1. None 2.5.1. None A result of "None" means that no records were published by the domain A result of "none" means either (a) no syntactically valid DNS domain or that no checkable sender domain could be determined from the given name was extracted from the SMTP session that could be used as the identity. The checking software cannot ascertain whether or not the one to be authorized, or (b) no TXT records were retrieved from the client host is authorized. DNS that appeared to be intended for use by SPF verifiers. 2.5.2. Neutral 2.5.2. Neutral The domain owner has explicitly stated that he cannot or does not The domain owner has explicitly stated that they cannot or do not want to assert whether or not the IP address is authorized. A want to assert whether the IP address is authorized or not. A "Neutral" result MUST be treated exactly like the "None" result; the "neutral" result MUST be treated exactly like the "none" result; the distinction exists only for informational purposes. Treating distinction exists only for informational purposes. Treating "Neutral" more harshly than "None" would discourage domain owners "neutral" more harshly than "none" would discourage domain owners from testing the use of SPF records (see Section 9.1). from testing the use of SPF records (see Section 9.1). 2.5.3. Pass 2.5.3. Pass A "Pass" result means that the client is authorized to inject mail A "pass" result means that the client is authorized to inject mail with the given identity. The domain can now, in the sense of with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the Further policy checks can now proceed with confidence in the legitimate use of the identity. legitimate use of the identity. This is further discussed in Section 9.3.1. 2.5.4. Fail 2.5.4. Fail A "Fail" result is an explicit statement that the client is not A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking authorized to use the domain in the given identity. Disposition of software can choose to mark the mail based on this or to reject the SPF fail messages is a matter of local policy. See Section 9.3.2 for mail outright. considerations on developing local policy. If the checking software chooses to reject the mail during the SMTP If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see (DSN) code (see [RFC3464]), in addition to an appropriate reply text. [RFC3463]), in addition to an appropriate reply text. The The check_host() function may return either a default explanation check_host() function will return either a default explanation string string or one from the domain that published the SPF records (see or one from the domain that published the SPF records (see Section 6.2). If the information does not originate with the Section 6.2). If the information does not originate with the checking software, it should be made clear that the text is provided checking software, it is good to make it clear that the text is by the sender's domain. For example: provided by the sender's domain. For example: 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 The domain example.com explains: 550-5.7.1 The domain example.com explains: 550 5.7.1 Please see http://www.example.com/mailpolicy.html 550 5.7.1 Please see http://www.example.com/mailpolicy.html 2.5.5. SoftFail If the checking software chooses not to reject the mail during the SMTP transaction, then it SHOULD add a Received-SPF or Authentication-Results header field (see Section 7) to communicate this result to downstream message processors. While this is true for all SPF results, it is of particular importance for "fail" results since the message is explicitly not authorized by the domain owner. A "SoftFail" result should be treated as somewhere between a "Fail" 2.5.5. Softfail and a "Neutral". The domain believes the host is not authorized but is not willing to make that strong of a statement. Receiving A "softfail" result ought to be treated as somewhere between "fail" software SHOULD NOT reject the message based solely on this result, and "neutral"/"none". The domain owner believes the host is not but MAY subject the message to closer scrutiny than normal. authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal. The domain owner wants to discourage the use of this host and thus The domain owner wants to discourage the use of this host and thus desires limited feedback when a "SoftFail" result occurs. For desires limited feedback when a "softfail" result occurs. For example, the recipient's Mail User Agent (MUA) could highlight the example, the recipient's Mail User Agent (MUA) could highlight the "SoftFail" status, or the receiving MTA could give the sender a "softfail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can message using greylisting, [RFC6647], with a note the first time the issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the message is received, but accept it on a later attempt based on first time the message is received, but accept it the second time. receiver policy. 2.5.6. TempError 2.5.6. Temperror A "TempError" result means that the SPF client encountered a A "temperror" result means the SPF verifier encountered a transient transient error while performing the check. Checking software can (generally DNS) error while performing the check. Checking software choose to accept or temporarily reject the message. If the message can choose to accept or temporarily reject the message. If the is rejected during the SMTP transaction for this reason, the software message is rejected during the SMTP transaction for this reason, the SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN software SHOULD use an SMTP reply code of 451 and, if supported, the code. 4.4.3 enhanced status code. These errors can be caused by problems in either the sender's or receiver's DNS software. 2.5.7. PermError 2.5.7. Permerror A "PermError" result means that the domain's published records could A "permerror" result means the domain's published records could not not be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that requires manual intervention to be resolved, as opposed to the definitely requires manual intervention to be resolved. If the TempError result. Be aware that if the domain owner uses macros message is rejected during the SMTP transaction for this reason, the (Section 8), it is possible that this result is due to the checked software SHOULD use an SMTP reply code of 550 and, if supported, the identities having an unexpected format. 5.5.2 enhanced status code. Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format. It is also possible that this result is generated by certain SPF clients due to the input arguments having an unexpected format; see Section 4.8. 3. SPF Records 3. SPF Records An SPF record is a DNS Resource Record (RR) that declares which hosts An SPF record is a DNS record that declares which hosts are, and are are, and are not, authorized to use a domain name for the "HELO" and not, authorized to use a domain name for the "HELO" and "MAIL FROM" "MAIL FROM" identities. Loosely, the record partitions all hosts identities. Loosely, the record partitions all hosts into permitted into permitted and not-permitted sets (though some hosts might fall and not-permitted sets (though some hosts might fall into neither into neither category). category). The SPF record is a single string of text. An example record is the The SPF record is a single string of text. The record format is following: described below in Section 4. An example record is the following: v=spf1 +mx a:colo.example.com/28 -all v=spf1 +mx a:colo.example.com/28 -all This record has a version of "spf1" and three directives: "+mx", This record has a version of "spf1" and three directives: "+mx", "a:colo.example.com/28" (the + is implied), and "-all". "a:colo.example.com/28" (the + is implied), and "-all". 3.1. Publishing Each SPF record is placed in the DNS tree at the host name it Domain owners wishing to be SPF compliant must publish SPF records for the hosts that are used in the "MAIL FROM" and "HELO" identities. The SPF records are placed in the DNS tree at the host name it pertains to, not a subdomain under it, such as is done with SRV pertains to, not a subdomain under it, such as is done with SRV records. This is the same whether the TXT or SPF RR type (see records [RFC2782]. Section 3.1.1) is used. The example above in Section 3 might be published via these lines in The example in this section might be published via these lines in a a domain zone file: domain zone file: example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" smtp-out.example.com. TXT "v=spf1 a -all" smtp-out.example.com. TXT "v=spf1 a -all" When publishing via TXT records, beware of other TXT records Since TXT records have multiple uses, beware of other TXT records published there for other purposes. They may cause problems with published there for other purposes. They might cause problems with size limits (see Section 3.1.4). size limits (see Section 3.4) and care has to be taken to ensure only SPF records are used for SPF processing. 3.1.1. DNS Resource Record Types This document defines a new DNS RR of type SPF, code 99. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII]. It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle the new RR type. The two-record-type scheme provides a forward path to the better solution of using an RR type reserved for this purpose. An SPF-compliant domain name SHOULD have SPF records of both RR ADMDs publishing SPF records SHOULD try to keep the number of types. A compliant domain name MUST have a record of at least one "include" mechanisms and chained "redirect" modifiers to a minimum. type. If a domain has records of both types, they MUST have ADMDs SHOULD also try to minimize the amount of other DNS information identical content. For example, instead of publishing just one needed to evaluate a record. Section 4.6.4 and Section 9.1.1 provide record as in Section 3.1 above, it is better to publish: some suggestions on how to achieve this. example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" 3.1. DNS Resource Records example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" Example RRs in this document are shown with the TXT record type; SPF records MUST be published as a DNS TXT (type 16) Resource Record however, they could be published with the SPF type or with both (RR) [RFC1035] only. The character content of the record is encoded types. as [US-ASCII]. Use of alternate DNS RR types was supported in SPF's experimental phase, but has been discontinued. See Appendix A of [RFC6686] for further information. 3.1.2. Multiple DNS Records 3.2. Multiple DNS Records A domain name MUST NOT have multiple records that would cause an A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record. See Section 4.5 authorization check to select more than one record. See Section 4.5 for the selection rules. for the selection rules. 3.1.3. Multiple Strings in a Single DNS record 3.3. Multiple Strings in a Single DNS record As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one record can be composed of more than one string. If a published string. If a published record contains multiple strings, then the record contains multiple character-strings, then the record MUST be record MUST be treated as if those strings are concatenated together treated as if those strings are concatenated together without adding without adding spaces. For example: spaces. For example: IN TXT "v=spf1 .... first" "second string..." IN TXT "v=spf1 .... first" "second string..." MUST be treated as equivalent to MUST be treated as equivalent to IN TXT "v=spf1 .... firstsecond string..." IN TXT "v=spf1 .... firstsecond string..." SPF or TXT records containing multiple strings are useful in TXT records containing multiple strings are useful in constructing constructing records that would exceed the 255-byte maximum length of records that would exceed the 255-byte maximum length of a character- a string within a single TXT or SPF RR record. string within a single TXT record. 3.1.4. Record Size 3.4. Record Size The published SPF record for a given domain name SHOULD remain small The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. enough that the results of a query for it will fit within 512 octets. This will keep even older DNS implementations from falling over to This UDP limit is defined in [RFC1035] section 2.3.4. This will keep TCP. Since the answer size is dependent on many things outside the even older DNS implementations from falling over to TCP. Since the scope of this document, it is only possible to give this guideline: answer size is dependent on many things outside the scope of this If the combined length of the DNS name and the text of all the document, it is only possible to give this guideline: If the combined records of a given type (TXT or SPF) is under 450 characters, then length of the DNS name and the text of all the records of a given DNS answers should fit in UDP packets. Note that when computing the type is under 450 characters, then DNS answers ought to fit in UDP sizes for queries of the TXT format, one must take into account any packets. Note that when computing the sizes for queries of the TXT other TXT records published at the domain name. Records that are too format, one has to take into account any other TXT records published long to fit in a single UDP packet MAY be silently ignored by SPF at the domain name. Records that are too long to fit in a single UDP clients. packet could be silently ignored by SPF verifiers due to firewall and other issues that cause DNS over TCP to be less reliable than DNS 3.1.5. Wildcard Records over UDP. Use of wildcard records for publishing is not recommended. Care must 3.5. Wildcard Records be taken if wildcard records are used. If a domain publishes wildcard MX records, it may want to publish wildcard declarations, subject to the same requirements and problems. In particular, the declaration must be repeated for any host that has any RR records at all, and for subdomains thereof. For example, the example given in [RFC1034], Section 4.3.3, could be extended with the following: X.COM. MX 10 A.X.COM Use of wildcard records for publishing is discouraged and care has to X.COM. TXT "v=spf1 a:A.X.COM -all" be taken if they are used. If a zone includes wildcard MX records, it might want to publish wildcard declarations, subject to the same requirements and problems. In particular, the declaration MUST be repeated for any host that has any RR records at all, and for subdomains thereof. Consider the example in [RFC1034], Section 4.3.3. Based on that, we can do the following: *.X.COM. MX 10 A.X.COM EXAMPLE.COM. MX 10 A.EXAMPLE.COM *.X.COM. TXT "v=spf1 a:A.X.COM -all" EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" A.X.COM. A 1.2.3.4 *.EXAMPLE.COM. MX 10 A.EXAMPLE.COM A.X.COM. MX 10 A.X.COM *.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" A.X.COM. TXT "v=spf1 a:A.X.COM -all" *.A.X.COM. MX 10 A.X.COM A.EXAMPLE.COM. A 203.0.113.1 *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" Notice that SPF records must be repeated twice for every name within *.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM the domain: once for the name, and once with a wildcard to cover the *.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" tree under the name. Use of wildcards is discouraged in general as they cause every name SPF records have to be listed twice for every name within the zone: under the domain to exist and queries against arbitrary names will once for the name, and once with a wildcard to cover the tree under never return RCODE 3 (Name Error). the name, in order to cover all domains in use in outgoing mail. 4. The check_host() Function 4. The check_host() Function This description is not an API (Application Program Interface) definition, but rather a function description used to illustrate the algorithm. A compliant SPF implementation MUST do something semantically equivalent to this description. The check_host() function fetches SPF records, parses them, and The check_host() function fetches SPF records, parses them, and interprets them to determine whether a particular host is or is not evaluates them to determine whether a particular host is or is not permitted to send mail with a given identity. Mail receivers that permitted to send mail with a given identity. Mail receivers that perform this check MUST correctly evaluate the check_host() function perform this check MUST correctly evaluate the check_host() function as described here. as described here. Implementations MAY use a different algorithm than the canonical Implementations MAY use a different algorithm than the canonical algorithm defined here, so long as the results are the same in all algorithm defined here, so long as the results are the same in all cases. cases. 4.1. Arguments 4.1. Arguments skipping to change at page 13, line 12 skipping to change at page 17, line 40 information; initially, the domain portion of the "MAIL information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. The domain portion of will usually be the same as the The domain portion of will usually be the same as the argument when check_host() is initially evaluated. However, argument when check_host() is initially evaluated. However, this will generally not be true for recursive evaluations (see this will generally not be true for recursive evaluations (see Section 5.2 below). Section 5.2 below). Actual implementations of the check_host() function may need additional arguments. 4.2. Results 4.2. Results The function check_host() can return one of several results described The function check_host() can return one of several results described in Section 2.5. Based on the result, the action to be taken is in Section 2.5. Based on the result, the action to be taken is determined by the local policies of the receiver. determined by the local policies of the receiver. 4.3. Initial Processing 4.3. Initial Processing If the is malformed (label longer than 63 characters, zero- If the is malformed (e.g. label longer than 63 characters, length label not at the end, etc.) or is not a fully qualified domain zero-length label not at the end, etc.) or is not a fully qualified name, or if the DNS lookup returns "domain does not exist" (RCODE 3), domain name, or if the DNS lookup returns "domain does not exist" check_host() immediately returns the result "None". (RCODE 3), check_host() immediately returns the result "none". Properly formed domains are fully qualified email domains as described in [RFC5321] Section 2.3.5. Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]. If the has no localpart, substitute the string "postmaster" If the has no local-part, substitute the string "postmaster" for the localpart. for the local-part. 4.4. Record Lookup 4.4. Record Lookup In accordance with how the records are published (see Section 3.1 In accordance with how the records are published (see Section 3 above), a DNS query needs to be made for the name, querying above), a DNS query needs to be made for the name, querying for either RR type TXT, SPF, or both. If both SPF and TXT RRs are for type TXT only. looked up, the queries MAY be done in parallel. If all DNS lookups that are made return a server failure (RCODE 2), If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then or other error (RCODE other than 0 or 3), or time out, then check_host() exits immediately with the result "TempError". check_host() terminates immediately with the result "temperror". Alternatively, for a server failure (RCODE 2) result, check_host() MAY track failures and treat multiple failures within 24 hours for the same domain as "permerror". This alternative is intended to shorten the queue time of messages that cannot be accepted, by returning a permanent negative completion reply code to the client, instead of a transient one. [RFC2308] suggests on an algorithm for doing such tracking and handling of server failure codes. 4.5. Selecting Records 4.5. Selecting Records Records begin with a version section: Records begin with a version section: record = version terms *SP record = version terms *SP version = "v=spf1" version = "v=spf1" Starting with the set of records that were returned by the lookup, Starting with the set of records that were returned by the lookup, record selection proceeds in two steps: discard records that do not begin with a version section of exactly "v=spf1". Note that the version section is terminated either by an 1. Records that do not begin with a version section of exactly SP character or the end of the record. A record with a version "v=spf1" are discarded. Note that the version section is section of "v=spf10" does not match and MUST be discarded. terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and must be discarded. 2. If any records of type SPF are in the set, then all records of type TXT are discarded. After the above steps, there should be exactly one record remaining and evaluation can proceed. If there are two or more records remaining, then check_host() exits immediately with the result of "PermError". If no matching records are returned, an SPF client MUST assume that If the resultant record set includes no records, check_host() the domain makes no SPF declarations. SPF processing MUST stop and produces the "none" result. If the resultant record set includes return "None". more than one record, check_host() produces the "permerror" result. 4.6. Record Evaluation 4.6. Record Evaluation After one SPF record has been selected, the check_host() function The check_host() function parses and interprets the SPF record to parses and interprets it to find a result for the current test. If find a result for the current test. If there are any syntax errors, there are any syntax errors, check_host() returns immediately with check_host() returns immediately with the result "permerror". the result "PermError". Implementations MAY choose to parse the entire record first and Implementations MAY choose to parse the entire record first and return "PermError" if the record is not syntactically well formed. return "permerror" if the record is not syntactically well formed. However, in all cases, any syntax errors anywhere in the record MUST However, in all cases, any syntax errors anywhere in the record MUST be detected. be detected. 4.6.1. Term Evaluation 4.6.1. Term Evaluation There are two types of terms: mechanisms and modifiers. A record There are two types of terms: mechanisms and modifiers. A record contains an ordered list of these as specified in the following contains an ordered list of these as specified in the following Augmented Backus-Naur Form (ABNF). Augmented Backus-Naur Form (ABNF). terms = *( 1*SP ( directive / modifier ) ) terms = *( 1*SP ( directive / modifier ) ) directive = [ qualifier ] mechanism directive = [ qualifier ] mechanism qualifier = "+" / "-" / "?" / "~" qualifier = "+" / "-" / "?" / "~" mechanism = ( all / include mechanism = ( all / include / A / MX / PTR / IP4 / IP6 / exists ) / A / MX / PTR / IP4 / IP6 / exists ) modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string ; where name is not any known modifier name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) Most mechanisms allow a ":" or "/" character after the name. Most mechanisms allow a ":" or "/" character after the name. Modifiers always contain an equals ('=') character immediately after Modifiers always contain an equals ('=') character immediately after the name, and before any ":" or "/" characters that may be part of the name, and before any ":" or "/" characters that might be part of the macro-string. the macro-string. Terms that do not contain any of "=", ":", or "/" are mechanisms, as Terms that do not contain any of "=", ":", or "/" are mechanisms, as defined in Section 5. defined in Section 5. As per the definition of the ABNF notation in [RFC4234], mechanism As per the definition of the ABNF notation in [RFC5234], mechanism and modifier names are case-insensitive. and modifier names are case-insensitive. 4.6.2. Mechanisms 4.6.2. Mechanisms Each mechanism is considered in turn from left to right. If there Each mechanism is considered in turn from left to right. If there are no more mechanisms, the result is specified in Section 4.7. are no more mechanisms, the result is specified in Section 4.7. When a mechanism is evaluated, one of three things can happen: it can When a mechanism is evaluated, one of three things can happen: it can match, not match, or throw an exception. match, not match, or return an exception. If it matches, processing ends and the qualifier value is returned as If it matches, processing ends and the qualifier value is returned as the result of that record. If it does not match, processing the result of that record. If it does not match, processing continues with the next mechanism. If it throws an exception, continues with the next mechanism. If it returns an exception, mechanism processing ends and the exception value is returned. mechanism processing ends and the exception value is returned. The possible qualifiers, and the results they return are as follows: The possible qualifiers, and the results they cause check_host() to return are as follows: "+" Pass "+" pass "-" Fail "-" fail "~" SoftFail "~" softfail "?" Neutral "?" neutral The qualifier is optional and defaults to "+". The qualifier is optional and defaults to "+". When a mechanism matches and the qualifier is "-", then a "Fail" When a mechanism matches and the qualifier is "-", then a "fail" result is returned and the explanation string is computed as result is returned and the explanation string is computed as described in Section 6.2. described in Section 6.2. The specific mechanisms are described in Section 5. The specific mechanisms are described in Section 5. 4.6.3. Modifiers 4.6.3. Modifiers Modifiers are not mechanisms: they do not return match or not-match. Modifiers are not mechanisms. They do not return match or not-match. Instead they provide additional information. Although modifiers do Instead, they provide additional information. Although modifiers do not directly affect the evaluation of the record, the "redirect" not directly affect the evaluation of the record, the "redirect" modifier has an effect after all the mechanisms have been evaluated. modifier has an effect after all the mechanisms have been evaluated. 4.6.4. DNS Lookup Limits SPF implementations MUST limit the number of mechanisms and modifiers ("terms") that cause any DNS query to at most 10 during SPF evaluation. Specifically, the "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier count against this limit. The "all", "ip4", and "ip6" mechanisms do not count against this limit. If this number is exceeded during a check, a permerror MUST be returned. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record evaluation has been completed. When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. If more than 10 "mx" or "ptr" records are returned for this further lookup, a permerror MUST be returned. This limit is per mechanism or macro in the record and in addition to the lookup limits above. MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "temperror". 4.7. Default Result 4.7. Default Result If none of the mechanisms match and there is no "redirect" modifier, If none of the mechanisms match and there is no "redirect" modifier, then the check_host() returns a result of "Neutral", just as if then the check_host() returns a result of "neutral", just as if "?all" were specified as the last directive. If there is a "?all" were specified as the last directive. If there is a "redirect" modifier, check_host() proceeds as defined in Section 6.1. "redirect" modifier, check_host() proceeds as defined in Section 6.1. Note that records SHOULD always use either a "redirect" modifier or Note that records SHOULD always use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing. an "all" mechanism to explicitly terminate processing. Although the latter has default (specifically "?all"), it aids debugging efforts if it is explicitly included. For example: For example: v=spf1 +mx -all v=spf1 +mx -all or or v=spf1 +mx redirect=_spf.example.com v=spf1 +mx redirect=_spf.example.com 4.8. Domain Specification 4.8. Domain Specification Several of these mechanisms and modifiers have a Several of these mechanisms and modifiers have a domain-spec section. section. The string is macro expanded (see Section 8). The domain-spec string is subject to macro expansion (see Section 8). The resulting string is the common presentation form of a fully- The resulting string is the common presentation form of a fully- qualified DNS name: a series of labels separated by periods. This qualified DNS name: a series of labels separated by periods. This domain is called the in the rest of this document. domain is called the in the rest of this document. Note: The result of the macro expansion is not subject to any further Note: The result of the macro expansion is not subject to any further escaping. Hence, this facility cannot produce all characters that escaping. Hence, this facility cannot produce all characters that are legal in a DNS label (e.g., the control characters). However, are legal in a DNS label (e.g., the control characters). However, this facility is powerful enough to express legal host names and this facility is powerful enough to express legal host names and common utility labels (such as "_spf") that are used in DNS. common utility labels (such as "_spf") that are used in DNS. For several mechanisms, the is optional. If it is not For several mechanisms, the is optional. If it is not provided, the is used as the . provided, the is used as the . Domain and domain-spec are syntactically identical after macro expansion. Domain is an input value for check_host() while domain-spec is computed by check_host(). Note: Historically, this document has made no provisions for how to handle domain-specs, or macro-expansions thereof, that are syntactically invalid per [RFC1035], such as names with empty labels (e.g., "foo..example.com") or overlong labels (more than 63 characters). Some implementations choose to treat as a no-match mechanisms, and ignore modifiers, with such names, whereas others return a "permerror" exception. The outcome for an unexpected domain-spec without macros might even differ from that for an unexpected target-name after macro expansion. 5. Mechanism Definitions 5. Mechanism Definitions This section defines two types of mechanisms. This section defines two types of mechanisms. Basic mechanisms contribute to the language framework. They do not Basic mechanisms contribute to the language framework. They do not specify a particular type of authorization scheme. specify a particular type of authorization scheme. all all include include Designated sender mechanisms are used to designate a set of Designated sender mechanisms are used to designate a set of addresses as being permitted or not permitted to use the for addresses as being permitted or not permitted to use the for sending mail. sending mail. a a mx mx ptr ptr (deprecated) ip4 ip4 ip6 ip6 exists exists The following conventions apply to all mechanisms that perform a The following conventions apply to all mechanisms that perform a comparison between and an IP address at any point: comparison between and an IP address at any point: If no CIDR-length is given in the directive, then and the IP If no CIDR prefix length is given in the directive, then and the address are compared for equality. (Here, CIDR is Classless Inter- IP address are compared for equality. (Here, CIDR is Classless Domain Routing.) Inter-Domain Routing, described in [RFC4632].) If a CIDR-length is specified, then only the specified number of If a CIDR prefix length is specified, then only the specified number high-order bits of and the IP address are compared for equality. of high-order bits of and the IP address are compared for equality. When any mechanism fetches host addresses to compare with , when When any mechanism fetches host addresses to compare with , when is an IPv4 address, A records are fetched, when is an IPv6 is an IPv4 address, A records are fetched; when is an IPv6 address, AAAA records are fetched. Even if the SMTP connection is address, AAAA records are fetched. Even if the SMTP connection uses via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) 2.5.5) MUST still be considered an IPv4 address. MUST still be considered an IPv4 address and MUST be evaluated using IPv4 mechanisms (i.e. "ip4" and "a"). Several mechanisms rely on information fetched from DNS. For these Several mechanisms rely on information fetched from the DNS. For DNS queries, except where noted, if the DNS server returns an error these DNS queries, except where noted, if the DNS server returns an (RCODE other than 0 or 3) or the query times out, the mechanism error (RCODE other than 0 or 3) or the query times out, the mechanism throws the exception "TempError". If the server returns "domain does stops and the topmost check_host() returns "temperror". If the not exist" (RCODE 3), then evaluation of the mechanism continues as server returns "domain does not exist" (RCODE 3), then evaluation of if the server returned no error (RCODE 0) and zero answer records. the mechanism continues as if the server returned no error (RCODE 0) and zero answer records. 5.1. "all" 5.1. "all" all = "all" all = "all" The "all" mechanism is a test that always matches. It is used as the The "all" mechanism is a test that always matches. It is used as the rightmost mechanism in a record to provide an explicit default. rightmost mechanism in a record to provide an explicit default. For example: For example: v=spf1 a mx -all v=spf1 a mx -all Mechanisms after "all" will never be tested. Any "redirect" modifier Mechanisms after "all" will never be tested. Mechanisms listed after (Section 6.1) has no effect when there is an "all" mechanism. "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be ignored when there is an "all" mechanism in the record. 5.2. "include" 5.2. "include" include = "include" ":" domain-spec include = "include" ":" domain-spec The "include" mechanism triggers a recursive evaluation of The "include" mechanism triggers a recursive evaluation of check_host(). The domain-spec is expanded as per Section 8. Then check_host(). check_host() is evaluated with the resulting string as the . The and arguments remain the same as in the current 1. The domain-spec is expanded as per Section 8. evaluation of check_host(). 2. Check_host() is evaluated with the resulting string as the . The and arguments remain the same as in the current evaluation of check_host(). 3. The recursive evaluation returns either match, not match, or an error. If it matches, then the appropriate result for the include: mechanism is used (e.g. include or +include gives a "pass" result and -include gives "fail). 4. If there is no match, the parent check_host() resumes processing as per the table below, with the previous value of restored. In hindsight, the name "include" was poorly chosen. Only the In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the acting as if the referenced SPF record was literally included in the first. For example, evaluating a "-all" directive in the referenced first. For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not record does not terminate the overall processing and does not necessarily result in an overall "Fail". (Better names for this necessarily result in an overall "fail". (Better names for this mechanism would have been "if-pass", "on-pass", etc.) mechanism would have been "if-match", "on-match", etc.) The "include" mechanism makes it possible for one domain to designate The "include" mechanism makes it possible for one domain to designate multiple administratively-independent domains. For example, a vanity multiple administratively-independent domains. For example, a vanity domain "example.net" might send mail using the servers of domain "example.net" might send mail using the servers of administratively-independent domains example.com and example.org. administratively-independent domains example.com and example.org. Example.net could say Example.net could say IN TXT "v=spf1 include:example.com include:example.org -all" IN TXT "v=spf1 include:example.com include:example.org -all" This would direct check_host() to, in effect, check the records of This would direct check_host() to, in effect, check the records of example.com and example.org for a "Pass" result. Only if the host example.com and example.org for a "pass" result. Only if the host were not permitted for either of those domains would the result be were not permitted for either of those domains would the result be "Fail". "fail". Whether this mechanism matches, does not match, or throws an Whether this mechanism matches, does not match, or returns an exception depends on the result of the recursive evaluation of exception depends on the result of the recursive evaluation of check_host(): check_host(): +---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+ | A recursive check_host() result | Causes the "include" mechanism | | A recursive check_host() result | Causes the "include" mechanism | | of: | to: | | of: | to: | +---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+ | Pass | match | | pass | match | | | | | | | | Fail | not match | | fail | not match | | | | | | | | SoftFail | not match | | softfail | not match | | | | | | | | Neutral | not match | | neutral | not match | | | | | | | | TempError | throw TempError | | temperror | return temperror | | | | | | | | PermError | throw PermError | | permerror | return permerror | | | | | | | | None | throw PermError | | none | return permerror | +---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+ The "include" mechanism is intended for crossing administrative The "include" mechanism is intended for crossing administrative boundaries. Although it is possible to use includes to consolidate boundaries. For example, if example.com and example.org were managed multiple domains that share the same set of designated hosts, domains by the same entity, and if the permitted set of hosts for both are encouraged to use redirects where possible, and to minimize the domains was number of includes within a single administrative domain. For example, if example.com and example.org were managed by the same entity, and if the permitted set of hosts for both domains was "mx:example.com", it would be possible for example.org to specify "mx:example.com", it would be possible for example.org to specify "include:example.com", but it would be preferable to specify "include:example.com", but it would be preferable to specify "redirect=example.com" or even "mx:example.com". "redirect=example.com" or even "mx:example.com". With the "include" mechanism an administratively external set of hosts can be authorized, but determination of sender policy is still a function of the original domain's SPF record (as determined by the "all" mechanism in that record). The redirect modifier is more suitable for consolidating both authorizations and policy into a common set to be shared within an ADMD. Redirect is much more like a common code element to be shared among records in a single ADMD. It is possible to control both authorized hosts and policy for an arbitrary number of domains from a single record. 5.3. "a" 5.3. "a" This mechanism matches if is one of the 's IP This mechanism matches if is one of the 's IP addresses. addresses. A = "a" [ ":" domain-spec ] [ dual-cidr-length ] a = "a" [ ":" domain-spec ] [ dual-cidr-length ] An address lookup is done on the . The is compared An address lookup is done on the . The is compared to the returned address(es). If any address matches, the mechanism to the returned address(es). If any address matches, the mechanism matches. matches. 5.4. "mx" 5.4. "mx" This mechanism matches if is one of the MX hosts for a domain This mechanism matches if is one of the MX hosts for a domain name. name. MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ] check_host() first performs an MX lookup on the . Then check_host() first performs an MX lookup on the . Then it performs an address lookup on each MX name returned. The is it performs an address lookup on each MX name returned. The is compared to each returned IP address. To prevent Denial of Service compared to each returned IP address. To prevent Denial of Service (DoS) attacks, more than 10 MX names MUST NOT be looked up during the (DoS) attacks, more than 10 MX names MUST NOT be looked up during the evaluation of an "mx" mechanism (see Section 10). If any address evaluation of an "mx" mechanism. If there are more than 10 MX names matches, the mechanism matches. then permerror is returned and the evaluation terminated (see Section 4.6.4). If any address matches, the mechanism matches. Note regarding implicit MXs: If the has no MX records, Note regarding implicit MXs: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the directly. This NOT default to an A or AAAA lookup on the directly. behavior breaks with the legacy "implicit MX" rule. See [RFC2821], This behavior diverges from the legacy "implicit MX" rule, (See Section 5. If such behavior is desired, the publisher should specify [RFC5321], Section 5. If such behavior is desired, the publisher an "a" directive. will have to specify an "a" directive). 5.5. "ptr" 5.5. "ptr" (deprecated) This mechanism tests whether the DNS reverse-mapping for exists This mechanism tests whether the DNS reverse-mapping for exists and correctly points to a domain name within a particular domain. and correctly points to a domain name within a particular domain. This mechanism is deprecated and SHOULD NOT be used. PTR = "ptr" [ ":" domain-spec ] ptr = "ptr" [ ":" domain-spec ] First, the 's name is looked up using this procedure: perform a The 's name is looked up using this procedure: DNS reverse-mapping for , looking up the corresponding PTR record in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." if it is an IPv6 address. For each record returned, validate the domain name by looking up its IP address. To prevent DoS attacks, more than 10 PTR names MUST NOT be looked up during the evaluation of a "ptr" mechanism (see Section 10). If is among the returned IP addresses, then that domain name is validated. In pseudocode: sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 1. Perform a DNS reverse-mapping for : Look up the corresponding sending-domain_names are found, use at most 10. for each name in PTR record in "in-addr.arpa." if the address is an IPv4 one and (sending-domain_names) { in "ip6.arpa." if it is an IPv6 address. IP_addresses := a_lookup(name); if the sending-domain_IP is one of the IP_addresses { validated-sending-domain_names += name; } } Check all validated domain names to see if they end in the 2. For each record returned, validate the domain name by looking up domain. If any do, this mechanism matches. If no its IP addresses. To prevent DoS attacks, more than 10 PTR names validated domain name can be found, or if none of the validated MUST NOT be looked up during the evaluation of a "ptr" mechanism domain names end in the , this mechanism fails to match. (see Section 4.6.4). If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR 3. If is among the returned IP addresses, then that domain name lookup, then that domain name is skipped and the search continues. is validated. Check all validated domain names to see if they either match the domain or are a subdomain of the domain. If any do, this mechanism matches. If no validated domain name can be found, or if none of the validated domain names match or are a subdomain of the , this mechanism fails to match. If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues. Pseudocode: Pseudocode: sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 sending-domain_names are found, use at most 10. for each name in (sending-domain_names) { IP_addresses := a_lookup(name); if the sending-domain_IP is one of the IP_addresses { validated-sending-domain_names += name; } } for each name in (validated-sending-domain_names) { for each name in (validated-sending-domain_names) { if name ends in , return match. if name ends in , return match. if name is , return match. if name is , return match. } } return no-match. return no-match. This mechanism matches if the is either an ancestor of This mechanism matches if the is either a subdomain of a validated domain name or if the and a validated a validated domain name or if the and a validated domain name are the same. For example: "mail.example.com" is within domain name are the same. For example: "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not. the domain "example.com", but "mail.bad-example.com" is not. Note: Use of this mechanism is discouraged because it is slow, it is Note: This mechanism has been deprecated because it is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the arpa name servers. If used, proper PTR places a large burden on the .arpa name servers. If used, proper PTR records must be in place for the domain's hosts and the "ptr" records MUST be in place for the domain's hosts and the "ptr" mechanism should be one of the last mechanisms checked. mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience it has been concluded it is unnecessary and more reliable alternatives used instead. It is, however, still in use and part of the SPF protocol, so compliant check_host() implementations MUST support it. 5.6. "ip4" and "ip6" 5.6. "ip4" and "ip6" These mechanisms test whether is contained within a given IP These mechanisms test whether is contained within a given IP network. network. IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255 ; as per conventional dotted quad notation. e.g., 192.0.2.0 ; as per conventional dotted quad notation. e.g., 192.0.2.0 ip6-network = ip6-network = ; e.g., 2001:DB8::CD30 ; e.g., 2001:DB8::CD30 The is compared to the given network. If CIDR-length high-order The is compared to the given network. If CIDR prefix length bits match, the mechanism matches. high-order bits match, the mechanism matches. If ip4-cidr-length is omitted, it is taken to be "/32". If If ip4-cidr-length is omitted, it is taken to be "/32". If ip6-cidr-length is omitted, it is taken to be "/128". It is not ip6-cidr-length is omitted, it is taken to be "/128". It is not permitted to omit parts of the IP address instead of using CIDR permitted to omit parts of the IP address instead of using CIDR notations. That is, use 192.0.2.0/24 instead of 192.0.2. notations. That is, use 192.0.2.0/24 instead of 192.0.2. 5.7. "exists" 5.7. "exists" This mechanism is used to construct an arbitrary domain name that is This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query. It allows for complicated schemes used for a DNS A record query. It allows for complicated schemes skipping to change at page 22, line 34 skipping to change at page 28, line 15 Domains can use this mechanism to specify arbitrarily complex Domains can use this mechanism to specify arbitrarily complex queries. For example, suppose example.com publishes the record: queries. For example, suppose example.com publishes the record: v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all The might expand to The might expand to "1.2.0.192.someuser._spf.example.com". This makes fine-grained "1.2.0.192.someuser._spf.example.com". This makes fine-grained decisions possible at the level of the user and client IP address. decisions possible at the level of the user and client IP address. This mechanism enables queries that mimic the style of tests that This mechanism enables queries that mimic the style of tests that existing anti-spam DNS blacklists (DNSBL) use. existing DNS white/black lists (DNSxLs) use, as described in [RFC5782]. The query will either return NXDOMAIN (no match), any valid answer (match), or an error. 6. Modifier Definitions 6. Modifier Definitions Modifiers are name/value pairs that provide additional information. Modifiers are name/value pairs that provide additional information. Modifiers always have an "=" separating the name and the value. Modifiers always have an "=" separating the name and the value. The modifiers defined in this document ("redirect" and "exp") MAY The modifiers defined in this document ("redirect" and "exp") MAY appear anywhere in the record, but SHOULD appear at the end, after appear anywhere in the record, but SHOULD appear at the end, after all mechanisms. Ordering of these two modifiers does not matter. all mechanisms. Ordering of these two modifiers does not matter. These two modifiers MUST NOT appear in a record more than once each. These two modifiers MUST NOT appear in a record more than once each. If they do, then check_host() exits with a result of "PermError". If they do, then check_host() exits with a result of "permerror". Unrecognized modifiers MUST be ignored no matter where in a record, Unrecognized modifiers MUST be ignored no matter where in a record, or how often. This allows implementations of this document to or how often. This allows implementations of this document to gracefully handle records with modifiers that are defined in other gracefully handle records with modifiers that are defined in other specifications. specifications. 6.1. redirect: Redirected Query 6.1. redirect: Redirected Query If all mechanisms fail to match, and a "redirect" modifier is The redirect modifier is intended for consolidating both present, then processing proceeds as follows: authorizations and policy into a common set to be shared within a single ADMD. Redirect is like a common code element to be shared among records in a single ADMD. It is possible to control both authorized hosts and policy for an arbitrary number of domains from a single record. redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec If all mechanisms fail to match, and a "redirect" modifier is present, then processing proceeds as follows: The domain-spec portion of the redirect section is expanded as per The domain-spec portion of the redirect section is expanded as per the macro rules in Section 8. Then check_host() is evaluated with the macro rules in Section 8. Then check_host() is evaluated with the resulting string as the . The and the resulting string as the . The and arguments remain the same as current evaluation of check_host(). arguments remain the same as in the current evaluation of check_host(). The result of this new evaluation of check_host() is then considered The result of this new evaluation of check_host() is then considered the result of the current evaluation with the exception that if no the result of the current evaluation with the exception that if no SPF record is found, or if the target-name is malformed, the result SPF record is found, or if the target-name is malformed, the result is a "PermError" rather than "None". is a "permerror" rather than "none". Note that the newly-queried domain may itself specify redirect Note that the newly-queried domain can itself specify redirect processing. processing. This facility is intended for use by organizations that wish to apply This facility is intended for use by organizations that wish to apply the same record to multiple domains. For example: the same record to multiple domains. For example: la.example.com. TXT "v=spf1 redirect=_spf.example.com" la.example.com. TXT "v=spf1 redirect=_spf.example.com" ny.example.com. TXT "v=spf1 redirect=_spf.example.com" ny.example.com. TXT "v=spf1 redirect=_spf.example.com" sf.example.com. TXT "v=spf1 redirect=_spf.example.com" sf.example.com. TXT "v=spf1 redirect=_spf.example.com" _spf.example.com. TXT "v=spf1 mx:example.com -all" _spf.example.com. TXT "v=spf1 mx:example.com -all" In this example, mail from any of the three domains is described by In this example, mail from any of the three domains is described by the same record. This can be an administrative advantage. the same record. This can be an administrative advantage. Note: In general, the domain "A" cannot reliably use a redirect to Note: In general, the domain "A" cannot reliably use a redirect to another domain "B" not under the same administrative control. Since another domain "B" not under the same administrative control. Since the stays the same, there is no guarantee that the record at the stays the same, there is no guarantee that the record at domain "B" will correctly work for mailboxes in domain "A", domain "B" will correctly work for mailboxes in domain "A", especially if domain "B" uses mechanisms involving localparts. An especially if domain "B" uses mechanisms involving local-parts. An "include" directive may be more appropriate. "include" directive is generally be more appropriate. For clarity, it is RECOMMENDED that any "redirect" modifier appear as For clarity, it is RECOMMENDED that any "redirect" modifier appear as the very last term in a record. the very last term in a record. 6.2. exp: Explanation 6.2. exp: Explanation explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec If check_host() results in a "Fail" due to a mechanism match (such as If check_host() results in a "fail" due to a mechanism match (such as "-all"), and the "exp" modifier is present, then the explanation "-all"), and the "exp" modifier is present, then the explanation string returned is computed as described below. If no "exp" modifier string returned is computed as described below. If no "exp" modifier is present, then either a default explanation string or an empty is present, then either a default explanation string or an empty explanation string may be returned. explanation string MUST be returned. The is macro expanded (see Section 8) and becomes the The domain-spec is macro expanded (see Section 8) and becomes the . The DNS TXT record for the is fetched. . The DNS TXT record for the is fetched. If is empty, or there are any DNS processing errors If there are any DNS processing errors (any RCODE other than 0), or (any RCODE other than 0), or if no records are returned, or if more if no records are returned, or if more than one record is returned, than one record is returned, or if there are syntax errors in the or if there are syntax errors in the explanation string, then proceed explanation string, then proceed as if no exp modifier was given. as if no exp modifier was given. The fetched TXT record's strings are concatenated with no spaces, and The fetched TXT record's strings are concatenated with no spaces, and then treated as an , which is macro-expanded. This then treated as an explain-string, which is macro-expanded. This final result is the explanation string. Implementations MAY limit final result is the explanation string. Implementations MAY limit the length of the resulting explanation string to allow for other the length of the resulting explanation string to allow for other protocol constraints and/or reasonable processing limits. Since the protocol constraints and/or reasonable processing limits. Since the explanation string is intended for an SMTP response and [RFC2821] explanation string is intended for an SMTP response and [RFC5321] Section 2.4 says that responses are in [US-ASCII], the explanation Section 2.4 says that responses are in [US-ASCII], the explanation string is also limited to US-ASCII. string MUST be limited to US-ASCII. Software evaluating check_host() can use this string to communicate Software evaluating check_host() can use this string to communicate information from the publishing domain in the form of a short message information from the publishing domain in the form of a short message or URL. Software SHOULD make it clear that the explanation string or URL. Software SHOULD make it clear that the explanation string comes from a third party. For example, it can prepend the macro comes from a third party. For example, it can prepend the macro string "%{o} explains: " to the explanation, such as shown in Section string "%{o} explains: " to the explanation, such as shown in 2.5.4. Section 2.5.4. Suppose example.com has this record: Suppose example.com has this record: v=spf1 mx -all exp=explain._spf.%{d} v=spf1 mx -all exp=explain._spf.%{d} Here are some examples of possible explanation TXT records at Here are some examples of possible explanation TXT records at explain._spf.example.com: explain._spf.example.com: "Mail from example.com should only be sent by its own servers." "Mail from example.com should only be sent by its own servers." -- a simple, constant message -- a simple, constant message "%{i} is not one of %{d}'s designated mail servers." "%{i} is not one of %{d}'s designated mail servers." -- a message with a little more information, including the IP -- a message with a little more information, including the IP address that failed the check address that failed the check "See http://%{d}/why.html?s=%{S}&i=%{I}" "See http://%{d}/why.html?s=%{S}&i=%{I}" -- a complicated example that constructs a URL with the -- a complicated example that constructs a URL with the arguments to check_host() so that a web page can be arguments to check_host() so that a web page can be generated with detailed, custom instructions generated with detailed, custom instructions Note: During recursion into an "include" mechanism, an exp= modifier Note: During recursion into an "include" mechanism, an exp= modifier from the MUST NOT be used. In contrast, when executing from the MUST NOT be used. In contrast, when executing a "redirect" modifier, an exp= modifier from the original domain MUST a "redirect" modifier, an exp= modifier from the original domain MUST NOT be used. NOT be used. 7. The Received-SPF Header Field 7. Recording The Result It is RECOMMENDED that SMTP receivers record the result of SPF To provide downstream agents, such as MUAs, with the information they processing in the message header. If an SMTP receiver chooses to do might need in terms of evaluating or representing the apparent safety so, it SHOULD use the "Received-SPF" header field defined here for of the message content, it is RECOMMENDED that SMTP receivers record each identity that was checked. This information is intended for the the result of SPF processing in the message header. For operators recipient. (Information intended for the sender is described in that choose to record SPF results in the header of the message for Section 6.2, Explanation.) processing by internal filters or MUAs, two methods are presented. Section 7.1 defines the Received-SPF field, which is the results field originally defined for SPF use. Section 7.2 discusses Authentication-Results [RFC5451] which was specified more recently and is designed for use by SPF and other authentication methods. The Received-SPF header field is a trace field (see [RFC2822] Section Both are in common use, and hence both are included here. However, it is important to note that they were designed to serve slightly different purposes. Received-SPF is intended to include enough forensic information to enable reconstruction of the SPF evaluation of the message, while Authentication-Results is designed only to relay the result itself and related output details of likely use to end users (e.g., what property of the message was actually authenticated and what it contained), leaving forensic work to the purview of system logs and the Received field contents. Also, Received-SPF relies on compliance of agents within the receiving ADMD to adhere to the header field ordering rules of [RFC5321] and [RFC5322], while Authentication-Results includes some provisions to protect against non-compliant implementations. An operator could choose to use both to serve different downstream agents. In such cases, care needs to be taken to ensure both fields are conveying the same details, or unexpected results can occur. 7.1. The Received-SPF Header Field The Received-SPF header field is a trace field (see [RFC5322] Section 3.6.7) and SHOULD be prepended to the existing header, above the 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver. It MUST Received: field that is generated by the SMTP receiver. It MUST appear above all other Received-SPF fields in the message. The appear above all other Received-SPF fields in the message. The header field has the following format: header field has the following format: header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF [ key-value-list ] CRLF result = "Pass" / "Fail" / "SoftFail" / "Neutral" / result = "pass" / "fail" / "softfail" / "neutral" / "None" / "TempError" / "PermError" "none" / "temperror" / "permerror" key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) [";"] [";"] key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / "problem" / "receiver" / "identity" / mechanism / "x-" name / name mechanism / name identity = "mailfrom" ; for the "MAIL FROM" identity identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / "helo" ; for the "HELO" identity / name ; other identities / name ; other identities dot-atom = dot-atom = quoted-string = quoted-string = comment = comment = CFWS = CFWS = FWS = FWS = CRLF = CRLF = The header field SHOULD include a "(...)" style after the The header field SHOULD include a "(...)" style comment after the result, conveying supporting information for the result, such as result, conveying supporting information for the result, such as , , and . , , and . The following key-value pairs are designed for later machine parsing. The following key-value pairs are designed for later machine parsing. SPF clients SHOULD give enough information so that the SPF results SPF verifiers SHOULD give enough information so that the SPF results can be verified. That is, at least "client-ip", "helo", and, if the can be verified. That is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from". "MAIL FROM" identity was checked, "envelope-from". client-ip the IP address of the SMTP client client-ip the IP address of the SMTP client envelope-from the envelope sender mailbox envelope-from the envelope sender mailbox helo the host name given in the HELO or EHLO command helo the host name given in the HELO or EHLO command mechanism the mechanism that matched (if no mechanisms matched, mechanism the mechanism that matched (if no mechanisms matched, substitute the word "default") substitute the word "default") problem if an error was returned, details about the error problem if an error was returned, details about the error receiver the host name of the SPF verifier receiver the host name of the SPF client identity the identity that was checked; see the ABNF identity the identity that was checked; see the ABNF rule rule Other keys may be defined by SPF clients. Until a new key name Other keys MAY be defined by SPF verifiers. becomes widely accepted, new key names should start with "x-". SPF clients MUST make sure that the Received-SPF header field does SPF verifiers MUST make sure that the Received-SPF header field does not contain invalid characters, is not excessively long, and does not not contain invalid characters, is not excessively long (See contain malicious data that has been provided by the sender. [RFC5322] Section 2.1.1), and does not contain malicious data that has been provided by the sender. Examples of various header styles that could be generated are the Examples of various header field styles that could be generated are following: the following: Received-SPF: Pass (mybox.example.org: domain of Received-SPF: pass (mybox.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from=; helo=foo.example.com; envelope-from="myname@example.com"; helo=foo.example.com; Received-SPF: Fail (mybox.example.org: domain of Received-SPF: fail (mybox.example.org: domain of myname@example.com does not designate myname@example.com does not designate 192.0.2.1 as permitted sender) 192.0.2.1 as permitted sender) identity=mailfrom; client-ip=192.0.2.1; identity=mailfrom; client-ip=192.0.2.1; envelope-from=; envelope-from="myname@example.com"; 7.2. SPF Results in the Authentication-Results Header Field As mentioned in Section 7, the Authentication-Results header field is designed to communicate lists of tests a border MTA did and their results. The specified elements of the field provide less information than the SPF-Received field: Authentication-Results: myhost.example.org; spf=pass smtp.mailfrom=example.net Received-SPF: pass (myhost.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from="myname@example.com"; helo=foo.example.com; It is, however, possible to add CFWS in the "reason" part of an Authentication-Results header field and provide the equivalent information, if desired. As an example, an expanded Authentication-Results header field might look like (for a "MAIL FROM" check in this example): Authentication-Results: myhost.example.org; spf=pass reason="client-ip=192.0.2.1; smtp.helo=foo.example.com" smtp.mailfrom=user@example.net 8. Macros 8. Macros 8.1. Macro Definitions 8.1. Macro Definitions Many mechanisms and modifiers perform macro expansion on part of the Many mechanisms and modifiers perform macro expansion on a term. term. domain-spec = macro-string domain-end domain-spec = macro-string domain-end domain-end = ( "." toplabel [ "." ] ) / macro-expand domain-end = ( "." toplabel [ "." ] ) / macro-expand toplabel = ( *alphanum ALPHA *alphanum ) / toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) ; (see [RFC3696], Section 2 for background) alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT explain-string = *( macro-string / SP ) explain-string = *( macro-string / SP ) macro-string = *( macro-expand / macro-literal ) macro-string = *( macro-expand / macro-literal ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) / "%%" / "%_" / "%-" / "%%" / "%_" / "%-" macro-literal = %x21-24 / %x26-7E macro-literal = %x21-24 / %x26-7E ; visible characters except "%" ; visible characters except "%" macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / "c" / "r" / "t" "c" / "r" / "t" / "v" transformers = *DIGIT [ "r" ] transformers = *DIGIT [ "r" ] delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" A literal "%" is expressed by "%%". A literal "%" is expressed by "%%". "%_" expands to a single " " space. "%_" expands to a single " " space. "%-" expands to a URL-encoded space, viz., "%20". "%-" expands to a URL-encoded space, viz., "%20". The following macro letters are expanded in term arguments: The following macro letters are expanded in term arguments: s = s = l = local-part of l = local-part of o = domain of o = domain of d = d = i = i = p = the validated domain name of p = the validated domain name of (deprecated) v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 h = HELO/EHLO domain h = HELO/EHLO domain The following macro letters are allowed only in "exp" text: The following macro letters are allowed only in "exp" text: c = SMTP client IP (easily readable format) c = SMTP client IP (easily readable format) r = domain name of host performing the check r = domain name of host performing the check t = current timestamp t = current timestamp A '%' character not followed by a '{', '%', '-', or '_' character is A '%' character not followed by a '{', '%', '-', or '_' character is skipping to change at page 28, line 13 skipping to change at page 37, line 7 h = HELO/EHLO domain h = HELO/EHLO domain The following macro letters are allowed only in "exp" text: The following macro letters are allowed only in "exp" text: c = SMTP client IP (easily readable format) c = SMTP client IP (easily readable format) r = domain name of host performing the check r = domain name of host performing the check t = current timestamp t = current timestamp A '%' character not followed by a '{', '%', '-', or '_' character is A '%' character not followed by a '{', '%', '-', or '_' character is a syntax error. So a syntax error. So -exists:%(ir).sbl.spamhaus.example.org -exists:%(ir).sbl.spamhaus.example.org is incorrect and will cause check_host() to yield a "permerror". is incorrect and will cause check_host() to return a "PermError". Instead, say Instead, say -exists:%{ir}.sbl.spamhaus.example.org -exists:%{ir}.sbl.spamhaus.example.org Optional transformers are the following: Optional transformers are the following: *DIGIT = zero or more digits *DIGIT = zero or more digits 'r' = reverse value, splitting on dots by default 'r' = reverse value, splitting on dots by default If transformers or delimiters are provided, the replacement value for If transformers or delimiters are provided, the replacement value for a macro letter is split into parts. After performing any reversal a macro letter is split into parts. After performing any reversal operation and/or removal of left-hand parts, the parts are rejoined operation and/or removal of left-hand parts, the parts are rejoined skipping to change at page 28, line 32 skipping to change at page 37, line 23 *DIGIT = zero or more digits *DIGIT = zero or more digits 'r' = reverse value, splitting on dots by default 'r' = reverse value, splitting on dots by default If transformers or delimiters are provided, the replacement value for If transformers or delimiters are provided, the replacement value for a macro letter is split into parts. After performing any reversal a macro letter is split into parts. After performing any reversal operation and/or removal of left-hand parts, the parts are rejoined operation and/or removal of left-hand parts, the parts are rejoined using "." and not the original splitting characters. using "." and not the original splitting characters. By default, strings are split on "." (dots). Note that no special By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, treatment is given to leading, trailing, or consecutive delimiters in and so the list of parts may contain empty strings. Older input strings, and so the list of parts might contain empty strings. implementations of SPF prohibit trailing dots in domain names, so Some older implementations of SPF prohibit trailing dots in domain trailing dots should not be published by domain owners, although they names, so trailing dots SHOULD NOT be published by domain owners, must be accepted by implementations conforming to this document. although they MUST be accepted by implementations conforming to this Macros may specify delimiter characters that are used instead of ".". document. Macros can specify delimiter characters that are used instead of ".". The 'r' transformer indicates a reversal operation: if the client IP The 'r' transformer indicates a reversal operation: if the client IP address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" and the macro %{ir} would expand to "1.2.0.192". and the macro %{ir} would expand to "1.2.0.192". The DIGIT transformer indicates the number of right-hand parts to The DIGIT transformer indicates the number of right-hand parts to use, after optional reversal. If a DIGIT is specified, the value use, after optional reversal. If a DIGIT is specified, the value MUST be nonzero. If no DIGITs are specified, or if the value MUST be nonzero. If no DIGITs are specified, or if the value specifies more parts than are available, all the available parts are specifies more parts than are available, all the available parts are used. If the DIGIT was 5, and only 3 parts were available, the macro used. If the DIGIT was 5, and only 3 parts were available, the macro interpreter would pretend the DIGIT was 3. Implementations MUST interpreter would pretend the DIGIT was 3. Implementations MUST support at least a value of 128, as that is the maximum number of support at least a value of 128, as that is the maximum number of labels in a domain name. labels in a domain name. The "s" macro expands to the argument. It is an E-Mail The "s" macro expands to the argument. It is an email address with a localpart, an "@" character, and a domain. The "l" address with a local-part, an "@" character, and a domain. The "l" macro expands to just the localpart. The "o" macro expands to just macro expands to just the local-part. The "o" macro expands to just the domain part. Note that these values remain the same during the domain part. Note that these values remain the same during recursive and chained evaluations due to "include" and/or "redirect". recursive and chained evaluations due to "include" and/or "redirect". Note also that if the original had no localpart, the Note also that if the original had no local-part, the local- localpart was set to "postmaster" in initial processing (see Section part was set to "postmaster" in initial processing (see Section 4.3). 4.3). For IPv4 addresses, both the "i" and "c" macros expand to the For IPv4 addresses, both the "i" and "c" macros expand to the standard dotted-quad format. standard dotted-quad format. For IPv6 addresses, the "i" macro expands to a dot-format address; it For IPv6 addresses, the "i" macro expands to a dot-format address; it is intended for use in %{ir}. The "c" macro may expand to any of the is intended for use in %{ir}. The "c" macro can expand to any of the hexadecimal colon-format addresses specified in [RFC3513], Section hexadecimal colon-format addresses specified in [RFC4291], Section 2.2. It is intended for humans to read. 2.2. It is intended for humans to read. The "p" macro expands to the validated domain name of . The The "p" macro expands to the validated domain name of . The procedure for finding the validated domain name is defined in Section procedure for finding the validated domain name is defined in 5.5. If the is present in the list of validated domains, it Section 5.5. If the is present in the list of validated SHOULD be used. Otherwise, if a subdomain of the is domains, it SHOULD be used. Otherwise, if a subdomain of the present, it SHOULD be used. Otherwise, any name from the list may be is present, it SHOULD be used. Otherwise, any name from the used. If there are no validated domain names or if a DNS error list can be used. If there are no validated domain names or if a DNS occurs, the string "unknown" is used. error occurs, the string "unknown" is used. This macro is deprecated and SHOULD NOT be used. The "r" macro expands to the name of the receiving MTA. This SHOULD The "r" macro expands to the name of the receiving MTA. This SHOULD be a fully qualified domain name, but if one does not exist (as when be a fully qualified domain name, but if one does not exist (as when the checking is done by a MUA) or if policy restrictions dictate the checking is done by a MUA) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted. The domain name otherwise, the word "unknown" SHOULD be substituted. The domain name may be different from the name found in the MX record that the client can be different from the name found in the MX record that the client MTA used to locate the receiving MTA. MTA used to locate the receiving MTA. The "t" macro expands to the decimal representation of the The "t" macro expands to the decimal representation of the approximate number of seconds since the Epoch (Midnight, January 1, approximate number of seconds since the Epoch (Midnight, January 1, 1970, UTC). This is the same value as is returned by the POSIX 1970, UTC) at the time of the evaluation. This is the same value as time() function in most standards-compliant libraries. is returned by the POSIX time() function in most standards-compliant libraries. When the result of macro expansion is used in a domain name query, if When the result of macro expansion is used in a domain name query, if the expanded domain name exceeds 253 characters (the maximum length the expanded domain name exceeds 253 characters (the maximum length of a domain name), the left side is truncated to fit, by removing of a domain name), the left side is truncated to fit, by removing successive domain labels until the total length does not exceed 253 successive domain labels (and their following dots) until the total characters. length does not exceed 253 characters. Uppercased macros expand exactly as their lowercased equivalents, and Uppercased macros expand exactly as their lowercased equivalents, and are then URL escaped. URL escaping must be performed for characters are then URL escaped. URL escaping MUST be performed for characters not in the "uric" set, which is defined in [RFC3986]. not in the "unreserved" set, which is defined in [RFC3986]. Note: Care must be taken so that macro expansion for legitimate Note: Care has to be taken so that macro expansion for legitimate E-Mail does not exceed the 63-character limit on DNS labels. The email does not exceed the 63-character limit on DNS labels. The localpart of E-Mail addresses, in particular, can have more than 63 local-part of email addresses, in particular, can have more than 63 characters between dots. characters between dots. Note: Domains should avoid using the "s", "l", "o", or "h" macros in Note: Domains SHOULD avoid using the "s", "l", "o", or "h" macros in conjunction with any mechanism directive. Although these macros are conjunction with any mechanism directive. Although these macros are powerful and allow per-user records to be published, they severely powerful and allow per-user records to be published, they severely limit the ability of implementations to cache results of check_host() limit the ability of implementations to cache results of check_host() and they reduce the effectiveness of DNS caches. and they reduce the effectiveness of DNS caches. Implementations should be aware that if no directive processed during Note: If no directive processed during the evaluation of check_host() the evaluation of check_host() contains an "s", "l", "o", or "h" contains an "s", "l", "o", or "h" macro, then the results of the macro, then the results of the evaluation can be cached on the basis evaluation can be cached on the basis of and alone for of and alone for as long as the shortest Time To Live as long as the shortest Time To Live (TTL) of all the DNS records (TTL) of all the DNS records involved. involved. 8.2. Expansion Examples 8.2. Expansion Examples The is strong-bad@email.example.com. The is strong-bad@email.example.com. The IPv4 SMTP client IP is 192.0.2.3. The IPv4 SMTP client IP is 192.0.2.3. The IPv6 SMTP client IP is 2001:DB8::CB01. The IPv6 SMTP client IP is 2001:DB8::CB01. The PTR domain name of the client IP is mx.example.org. The PTR domain name of the client IP is mx.example.org. macro expansion macro expansion ------- ---------------------------- ------- ---------------------------- skipping to change at page 31, line 20 skipping to change at page 40, line 4 bad.strong.lp.3.2.0.192.in-addr._spf.example.com bad.strong.lp.3.2.0.192.in-addr._spf.example.com %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 3.2.0.192.in-addr.strong.lp._spf.example.com 3.2.0.192.in-addr.strong.lp._spf.example.com %{d2}.trusted-domains.example.net %{d2}.trusted-domains.example.net example.com.trusted-domains.example.net example.com.trusted-domains.example.net IPv6: IPv6: %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 9. Implications 9. Implications This section outlines the major implications that adoption of this This section outlines the major implications that adoption of this document will have on various entities involved in Internet E-Mail. document will have on various entities involved in Internet email. It is intended to make clear to the reader where this document It is intended to make clear to the reader where this document knowingly affects the operation of such entities. This section is knowingly affects the operation of such entities. This section is not a "how-to" manual, or a "best practices" document, and it is not not a "how-to" manual, or a "best practices" document, and it is not a comprehensive list of what such entities should do in light of this a comprehensive list of what such entities SHOULD do in light of this document. document. This section is non-normative. This section is non-normative. [RFC5598] describes the Internet email architecture. This section is organized based on the different segments of the architecture. 9.1. Sending Domains 9.1. Sending Domains Domains that wish to be compliant with this specification will need Originating ADMDs (ADministrative Management Domains - [RFC5598] to determine the list of hosts that they allow to use their domain Section 2.2.1 and Section 2.3) that wish to be compliant with this name in the "HELO" and "MAIL FROM" identities. It is recognized that specification will need to determine the list of relays ([RFC5598] forming such a list is not just a simple technical exercise, but Section 2.2.2) that they allow to use their domain name in the "HELO" involves policy decisions with both technical and administrative and "MAIL FROM" identities when relaying to other ADMDs. It is considerations. recognized that forming such a list is not just a simple technical exercise, but involves policy decisions with both technical and administrative considerations. It can be helpful to publish records that include a "tracking 9.1.1. DNS Resource Considerations Minimizing the DNS resources required for SPF lookups can be done by choosing directives that require less DNS information and by placing lower-cost mechanisms earlier in the SPF record. +----------+--------+-----------------+ | term | cost | limit | +----------+--------+-----------------+ | ip4/ip6 | 0 | - | | a | 1 | 10 | | include | 1 | 10 | | redirect | 1 | 10 | | exists | 1 | 10 | | mx | 1 + N* | 10 and N* <= 10 | | ptr/%{p} | 1 + N* | 10 and N* <= 10 | | all | 0 | - | +----------+--------+-----------------+ * N is the number of RRs found during each term evaluation Section 4.6.4 specifies the limits receivers have to use. It is essential to publish records that do not exceed these requirements. It is also required to carefully weight the cost and the maintainability of licit solutions. For example, consider a domain set up as follows: example.com. IN MX 10 mx.example.com. IN MX 20 mx2.example.com. mx.example.com. IN A 192.0.2.1 mx2.example.com. IN A 192.0.2.129 Assume the administrative point is to authorize (pass) mx and mx2 while failing every other host. Compare the following solutions: Best record: example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all" Good record: $ORIGIN example.com. @ IN TXT "v=spf1 a:authorized-spf.example.com -all" authorized-spf IN A 192.0.2.1 IN A 192.0.2.129 Expensive record: example.com. IN TXT "v=spf1 mx:example.com -all" Wasteful, bad record: example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all" 9.1.2. Administrator's Considerations There might be administrative considerations: using "a" over "ip4" or "ip6" allows hosts to be renumbered easily. Using "mx" over "a" allows the set of mail hosts to be changed easily. Unless such changes are common, it is better to use the less resource intensive mechanisms like "ip4" and "ip6" over "a" or "a" or "mx". In some specific cases, standard advice on record content is appropriate. Publishing SPF records for domains that send no mail is a well established best practice. The record for a domain that sends no mail is: www.example.com. IN TXT "v=spf1 -all" Publishing SPF records for individual hosts is also best practice. The hostname is generally the identity used in the 5321.HELO/.EHLO command. In the case of messages with a null 5321.MailFrom, this is used as the domain for 5321.MailFrom SPF checks, in addition to being used in 5321.HELO/.EHLO based SPF checks. The standard SPF record for an individual host that is involved in mail processing is: relay.example.com. IN TXT "v=spf1 a -all" Validating correct deployment is difficult. [RFC6652] describes one mechanism for soliciting feedback on SPF failures. Another approach that can be helpful to publish records that include a "tracking exists:" mechanism. By looking at the name server logs, a rough list exists:" mechanism. By looking at the name server logs, a rough list may then be generated. For example: can then be generated. For example: v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all 9.2. Mailing Lists Regardless of the method used, understanding the ADMD's outbound mail architecture is essential to effective deployment. Mailing lists must be aware of how they re-inject mail that is sent 9.1.3. Bounces to the list. Mailing lists MUST comply with the requirements in [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that As explained in Section 1.3.3, [RFC5321] allows the reverse-path to be null, which is typical of some Delivery Status Notification [RFC3464], commonly called email bounces. In this case the only entity available for performing an SPF check is the "HELO" identity defined in Section 1.3.4. SPF functionality is enhanced by administrators ensuring this identity is set correctly and has an appropriate SPF record. It is normal to have the HELO identity set to hostname instead of domain. Zone file generation for significant numbers of hosts can be consolidated using the redirect modifier and scripted for initial deployment. Specific deployment advice is given above in Section 9.1.2. 9.2. Mediators Broadly speaking, there are two types of mediating ADMDs that can affect SPF deployment of other ADMDs: mailing lists (see [RFC5598] Section 5.3) and ReSenders ([RFC5598] Section 5.2). 9.2.1. Mailing Lists Mailing lists have to be aware of how they re-inject mail that is sent to the list. Mailing lists MUST comply with the requirements in [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that the reverse-path MUST be changed to be the mailbox of a person or the reverse-path MUST be changed to be the mailbox of a person or other entity who administers the list. Whereas the reasons for other entity who administers the list. Whereas the reasons for changing the reverse-path are many and long-standing, SPF adds changing the reverse-path are many and long-standing, SPF adds enforcement to this requirement. enforcement to this requirement. In practice, almost all mailing list software in use already complies In practice, almost all mailing list software in use already complies with this requirement. Mailing lists that do not comply may or may with this requirement. Mailing lists that do not comply might not encounter problems depending on how access to the list is encounter problems depending on how access to the list is restricted. restricted. Such lists that are entirely internal to a domain (only Such lists that are entirely internal to a domain (only people in the people in the domain can send to or receive from the list) are not domain can send to or receive from the list) are not affected. affected. 9.3. Forwarding Services and Aliases 9.2.2. Forwarding Services and Aliases Forwarding services take mail that is received at a mailbox and Forwarding services take mail that is received at a mailbox and direct it to some external mailbox. At the time of this writing, the direct it to some external mailbox. At the time of this writing, the near-universal practice of such services is to use the original "MAIL near-universal practice of such services is to use the original "MAIL FROM" of a message when re-injecting it for delivery to the external FROM" of a message when re-injecting it for delivery to the external mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" mailbox. [RFC1123] and [RFC5321] describe this action as an "alias" rather than a "mail list". This means that the external mailbox's rather than a "mail list". This means the external mailbox's MTA MTA sees all such mail in a connection from a host of the forwarding sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not, in general, pass service, and so the "MAIL FROM" identity will not, in general, pass authorization. authorization. There are three places that techniques can be used to ameliorate this There are three places that techniques can be used to ameliorate this problem. problem. 1. The beginning, when E-Mail is first sent. 1. The beginning, when email is first sent (Originating ADMDs). 1. "Neutral" results could be given for IP addresses that may be 1. "Neutral" results could be given for IP addresses that might forwarders, instead of "Fail" results. For example: be forwarders, instead of "fail" results based on a list of known reliable forwarders. For example: "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" "v=spf1 mx ?exists:%{ir}.whitlist.example.org -all" This would cause a lookup on an anti-spam DNS blacklist This would cause a lookup on an DNS white list (DNSWL) and (DNSBL) and cause a result of "Fail" only for E-Mail coming cause a result of "fail" only for email not either coming from listed sources. All other E-Mail, including E-Mail sent from the domain's mx host(s) (SPF pass) or white listed through forwarders, would receive a "Neutral" result. By sources (SPF neutral). This, in effect, outsources an checking the DNSBL after the known good sources, problems with element of sender policy to the maintainer of the whitelist. incorrect listing on the DNSBL are greatly reduced. 2. The "MAIL FROM" identity could have additional information in 2. The "MAIL FROM" identity could have additional information in the localpart that cryptographically identifies the mail as the local-part that cryptographically identifies the mail as coming from an authorized source. In this case, such an SPF coming from an authorized source. In this case, such an SPF record could be used: record could be used: "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" Then, a specialized DNS server can be set up to serve the Then, a specialized DNS server can be set up to serve the _spf_verify subdomain that validates the localpart. Although _spf_verify subdomain that validates the local-part. this requires an extra DNS lookup, this happens only when the Although this requires an extra DNS lookup, this happens only E-Mail would otherwise be rejected as not coming from a known when the email would otherwise be rejected as not coming from good source. a known good source. Note that due to the 63-character limit for domain labels, this approach only works reliably if the local-part signature scheme is guaranteed either to only produce local-parts with a maximum of 63 characters or to gracefully handle truncated local-parts. Note that due to the 63-character limit for domain labels, 3. Similarly, a specialized DNS server could be set up that will this approach only works reliably if the localpart signature rate-limit the email coming from unexpected IP addresses. scheme is guaranteed either to only produce localparts with a maximum of 63 characters or to gracefully handle truncated localparts. 3. Similarly, a specialized DNS server could be set up that will "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" rate-limit the E-Mail coming from unexpected IP addresses. "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" 4. SPF allows the creation of per-user policies for special cases. For example, the following SPF record and appropriate wildcard DNS records can be used: 4. SPF allows the creation of per-user policies for special "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" cases. For example, the following SPF record and appropriate wildcard DNS records can be used: "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" 2. The middle, when email is forwarded (Mediating ADMDs). 2. The middle, when E-Mail is forwarded. 1. Forwarding services can solve the problem by rewriting the "MAIL FROM" to be in their own domain. This means mail rejected from the external mailbox will have to be forwarded back to the original sender by the forwarding service. Various schemes to do this exist though they vary widely in complexity and resource requirements on the part of the forwarding service. 1. Forwarding services can solve the problem by rewriting the 2. Several popular MTAs can be forced from "alias" semantics to "MAIL FROM" to be in their own domain. This means that mail "mailing list" semantics by configuring an additional alias bounced from the external mailbox will have to be re-bounced with "owner-" prepended to the original alias name (e.g., an by the forwarding service. Various schemes to do this exist alias of "friends: george@example.com, fred@example.org" though they vary widely in complexity and resource would need another alias of the form "owner-friends: requirements on the part of the forwarding service. localowner"). 2. Several popular MTAs can be forced from "alias" semantics to 3. Forwarding servers could reject mail that would "fail" SPF if "mailing list" semantics by configuring an additional alias forwarded using an SMTP reply code of 551, User not local, with "owner-" prepended to the original alias name (e.g., an (see [RFC5321] section 3.4) to communicate the correct target alias of "friends: george@example.com, fred@example.org" would address to resend the mail to. need another alias of the form "owner-friends: localowner"). 3. The end, when E-Mail is received. 3. The end, when email is received (Receiving ADMDs). 1. If the owner of the external mailbox wishes to trust the 1. If the owner of the external mailbox wishes to trust the forwarding service, he can direct the external mailbox's MTA forwarding service, he can direct the external mailbox's MTA to skip SPF tests when the client host belongs to the to skip SPF tests when the client host belongs to the forwarding service. forwarding service. 2. Tests against other identities, such as the "HELO" identity, 2. Tests against other identities, such as the "HELO" identity, may be used to override a failed test against the "MAIL FROM" MAY be used to override a failed test against the "MAIL FROM" identity. identity. 3. For larger domains, it may not be possible to have a complete 3. For larger domains, it might not be possible to have a or accurate list of forwarding services used by the owners of complete or accurate list of forwarding services used by the the domain's mailboxes. In such cases, whitelists of owners of the domain's mailboxes. In such cases, whitelists generally-recognized forwarding services could be employed. of generally-recognized forwarding services could be employed. 9.4. Mail Services 9.2.3. Mail Services Service providers that offer mail services to third-party domains, MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail such as sending of bulk mail, may want to adjust their setup in light services to third-party domains, such as sending of bulk mail, might of the authorization check described in this document. If the "MAIL want to adjust their configurations in light of the authorization FROM" identity used for such E-Mail uses the domain of the service check described in this document. If the domain part of the "MAIL provider, then the provider needs only to ensure that its sending FROM" identity used for such email uses the domain of one of the MSPs host is authorized by its own SPF record, if any. domain, then the provider needs only to ensure that its sending host is authorized by its own SPF record, if any. If the "MAIL FROM" identity does not use the mail service provider's If the "MAIL FROM" identity does not use the MSP's domain, then extra domain, then extra care must be taken. The SPF record format has care has to be taken. The SPF record format has several options for several options for the third-party domain to authorize the service the third-party domain to authorize the service provider's MTAs to provider's MTAs to send mail on its behalf. For mail service send mail on its behalf. For MSPs, such as ISPs, that have a wide providers, such as ISPs, that have a wide variety of customers using variety of customers using the same MTA, steps are required to the same MTA, steps should be taken to prevent cross-customer forgery mitiate the risk of cross-customer forgery (see Section 10.4). (see Section 10.4). 9.5. MTA Relays 9.2.4. MTA Relays The authorization check generally precludes the use of arbitrary MTA Relays are described in [RFC5598] Section 2.2.2. The authorization relays between sender and receiver of an E-Mail message. check generally precludes the use of arbitrary MTA relays between sender and receiver of an email message. Within an organization, MTA relays can be effectively deployed. Within an organization, MTA relays can be effectively deployed. However, for purposes of this document, such relays are effectively However, for purposes of this document, such relays are effectively transparent. The SPF authorization check is a check between border transparent. The SPF authorization check is a check between border MTAs of different domains. MTAs of different ADMDs. For mail senders, this means that published SPF records must For mail senders, this means that published SPF records have to authorize any MTAs that actually send across the Internet. Usually, authorize any MTAs that actually send across the Internet. Usually, these are just the border MTAs as internal MTAs simply forward mail these are just the border MTAs as internal MTAs simply forward mail to these MTAs for delivery. to these MTAs for relaying. Mail receivers will generally want to perform the authorization check The receiving ADMD will generally want to perform the authorization at the border MTAs, specifically including all secondary MXs. This check at the boundary MTAs, including all secondary MXs. Internal allows mail that fails to be rejected during the SMTP session rather MTAs (including MTAs that might serve both as boundary MTAs and than bounced. Internal MTAs then do not perform the authorization internal relays from secondary MXs when they are processing the test. To perform the authorization test other than at the border, relayed mail stream) then do not perform the authorization test. To the host that first transferred the message to the organization must perform the authorization test other than at the boundary, the host be determined, which can be difficult to extract from the message that first transferred the message to the receiving ADMD have to be header. Testing other than at the border is not recommended. determined, which can be difficult to extract from the message header because (a) header fields can be forged or malformed, and (b) there's no standard way to encode that information such that it can be reliably extracted. Testing other than at the boundary is likely to produce unreliable results. 9.3. Receivers SPF results can be used in combination with other methods to determine the final local disposition (either positive or negative of a message. It can also be considered dispositive on its own. 9.3.1. Policy For SPF Pass SPF pass results can be used in combination with "white lists" of known "good" domains to bypass some or all additional pre-delivery email checks. Exactly which checks and how to determine appropriate white list entries has to be based on local conditions and requirements. 9.3.2. Policy For SPF Fail SPF fail results can be used to reject messages during the SMTP transaction based on either "MAIL FROM" or "HELO" identity results. This reduces resource requirements for various content filtering methods and conserves bandwidth since rejection can be done before the SMTP content is transferred. It also gives immediate feedback to the sender who might then be able to resolve the issue. Due to some of the issues described above in this section (Section 9), SPF based rejection does present some risk of rejecting legitimate email when rejecting based on "MAIL FROM" results. SPF fail results can alternately be used as one input into a larger set of evaluations which might, based on a combination with other evaluation techniques, result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means). Developing the details of such an approach have to be based on local conditions and requirements. Using SPF results in this way does not have the advantages of resource conservation and immediate feedback to the sender associated with SMTP rejection, but could produce fewer undesirable rejections in a well designed system. Such an approach might result in email that was not authorized by the sending ADMD being unknowingly delivered to end users. Either general approach can be used as they both leave a clear disposition of emails. They are either delivered in some manner or the sender is notified of the failure. Other dispositions such as "dropping" or deleting email after acceptance are inappropriate because they leave uncertainty and reduce the overall reliabilility and utility of email across the Internet. 9.3.3. Policy For SPF Permerror The "permerror" result (see Section 2.5.7) indicates the SPF processing module at the receiver determined that the retrieved SPF policy record could not be interpreted. This gives no true indication about the authorized use of the data found in the envelope. As with all results, implementers have a choice to make regarding what to do with a message that yields this result. SMTP allows only a few basic options. Rejection of the message is an option, in that it is the one thing a receiver can do to draw attention to the difficulty encountered while protecting itself from messages that do not have a definite SPF result of some kind. However, if the SPF implementation is defective and returns spurious "permerror" results, only the sender is actively notified of the defect (in the form of rejected mail), and not the receiver making use of SPF. The less intrusive handling choice is to deliver the message, perhaps with some kind of annotation of the difficulty encountered and/or logging of a similar nature. However, this will not be desirable to operators that wish to implement SPF checking as strictly as possible, nor is this sort of passive problem reporting typically effective. There is of course the option placing this choice in the hands of the operator rather than the implementer since this kind of choice is often a matter of local policy rather than a condition with a universal solution, but this adds one more piece of complexity to an already non-trivial environment. Both implementers and operators need to be cautious of all choices and outcomes when handling SPF results. 10. Security Considerations 10. Security Considerations 10.1. Processing Limits 10.1. Processing Limits As with most aspects of E-Mail, there are a number of ways that As with most aspects of email, there are a number of ways that malicious parties could use the protocol as an avenue for a malicious parties could use the protocol as an avenue for a Denial-of-Service (DoS) attack. The processing limits outlined here Denial-of-Service (DoS) attack. The processing limits outlined in are designed to prevent attacks such as the following: Section 4.6.4 are designed to prevent attacks such as the following: o A malicious party could create an SPF record with many references o A malicious party could create an SPF record with many references to a victim's domain and send many E-Mails to different SPF to a victim's domain and send many emails to different SPF clients; those SPF clients would then create a DoS attack. In verifiers; those SPF verifiers would then create a DoS attack. In effect, the SPF clients are being used to amplify the attacker's effect, the SPF verifiers are being used to amplify the attacker's bandwidth by using fewer bytes in the SMTP session than are used bandwidth by using fewer bytes in the SMTP session than are used by the DNS queries. Using SPF clients also allows the attacker to by the DNS queries. Using SPF clients also allows the attacker to hide the true source of the attack. hide the true source of the attack. o Whereas implementations of check_host() are supposed to limit the o Whereas implementations of check_host() are supposed to limit the number of DNS lookups, malicious domains could publish records number of DNS lookups, malicious domains could publish records that exceed these limits in an attempt to waste computation effort that exceed these limits in an attempt to waste computation effort at their targets when they send them mail. Malicious domains at their targets when they send them mail. Malicious domains could also design SPF records that cause particular could also design SPF records that cause particular implementations to use excessive memory or CPU usage, or to implementations to use excessive memory or CPU usage, or to trigger bugs. trigger bugs. o Malicious parties could send a large volume of mail purporting to o Malicious parties could send a large volume of mail purporting to come from the intended target to a wide variety of legitimate mail come from the intended target to a wide variety of legitimate mail hosts. These legitimate machines would then present a DNS load on hosts. These legitimate machines would then present a DNS load on the target as they fetched the relevant records. the target as they fetched the relevant records. Of these, the case of a third party referenced in the SPF record is Of these, the case of a third party referenced in the SPF record is the easiest for a DoS attack to effectively exploit. As a result, the easiest for a DoS attack to effectively exploit. As a result, limits that may seem reasonable for an individual mail server can limits that might seem reasonable for an individual mail server can still allow an unreasonable amount of bandwidth amplification. still allow an unreasonable amount of bandwidth amplification. Therefore, the processing limits need to be quite low. Therefore, the processing limits need to be quite low. SPF implementations MUST limit the number of mechanisms and modifiers 10.2. SPF-Authorized Email May Contain Other False Identities that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated. When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. SPF implementations SHOULD limit the total amount of data obtained from the DNS queries. For example, when DNS over TCP or EDNS0 are available, there may need to be an explicit limit to how much data will be accepted to prevent excessive bandwidth usage or memory usage and DoS attacks. MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "TempError". Domains publishing records SHOULD try to keep the number of "include" mechanisms and chained "redirect" modifiers to a minimum. Domains SHOULD also try to minimize the amount of other DNS information needed to evaluate a record. This can be done by choosing directives that require less DNS information and placing lower-cost mechanisms earlier in the SPF record. For example, consider a domain set up as follows: example.com. IN MX 10 mx.example.com. mx.example.com. IN A 192.0.2.1 a.example.com. IN TXT "v=spf1 mx:example.com -all" b.example.com. IN TXT "v=spf1 a:mx.example.com -all" c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" Evaluating check_host() for the domain "a.example.com" requires the MX records for "example.com", and then the A records for the listed hosts. Evaluating for "b.example.com" requires only the A records. Evaluating for "c.example.com" requires none. However, there may be administrative considerations: using "a" over "ip4" allows hosts to be renumbered easily. Using "mx" over "a" allows the set of mail hosts to be changed easily. 10.2. SPF-Authorized E-Mail May Contain Other False Identities The "MAIL FROM" and "HELO" identity authorizations must not be Do not construe the "MAIL FROM" and "HELO" identity authorizations to construed to provide more assurance than they do. It is entirely provide more assurance than they do. It is entirely possible for a possible for a malicious sender to inject a message using his own malicious sender to inject a message using his own domain in the domain in the identities used by SPF, to have that domain's SPF identities used by SPF, to have that domain's SPF record authorize record authorize the sending host, and yet the message can easily the sending host, and yet the message can easily list other list other identities in its header. Unless the user or the MUA identities in its header. Unless the user or the MUA takes care to takes care to note that the authorized identity does not match the note that the authorized identity does not match the other more other more commonly-presented identities (such as the From: header commonly-presented identities (such as the From: header field), the field), the user may be lulled into a false sense of security. user might be lulled into a false sense of security. 10.3. Spoofed DNS and IP Data 10.3. Spoofed DNS and IP Data There are two aspects of this protocol that malicious parties could There are two aspects of this protocol that malicious parties could exploit to undermine the validity of the check_host() function: exploit to undermine the validity of the check_host() function: o The evaluation of check_host() relies heavily on DNS. A malicious o The evaluation of check_host() relies heavily on DNS. A malicious attacker could attack the DNS infrastructure and cause attacker could attack the DNS infrastructure and cause check_host() to see spoofed DNS data, and then return incorrect check_host() to see spoofed DNS data, and then return incorrect results. This could include returning "Pass" for an value results. This could include returning "pass" for an value where the actual domain's record would evaluate to "Fail". See where the actual domain's record would evaluate to "fail". See [RFC3833] for a description of DNS weaknesses. [RFC3833] for a description of DNS weaknesses. o The client IP address, , is assumed to be correct. A o The client IP address, , is assumed to be correct. In a malicious attacker could spoof TCP sequence numbers to make mail modern, correctly configured system the risk of this not being appear to come from a permitted host for a domain that the true is nil. attacker is impersonating. 10.4. Cross-User Forgery 10.4. Cross-User Forgery By definition, SPF policies just map domain names to sets of By definition, SPF policies just map domain names to sets of authorized MTAs, not whole E-Mail addresses to sets of authorized authorized MTAs, not whole email addresses to sets of authorized users. Although the "l" macro (Section 8) provides a limited way to users. Although the "l" macro (Section 8) provides a limited way to define individual sets of authorized MTAs for specific E-Mail define individual sets of authorized MTAs for specific email addresses, it is generally impossible to verify, through SPF, the use addresses, it is generally impossible to verify, through SPF, the use of specific E-Mail addresses by individual users of the same MTA. of specific email addresses by individual users of the same MTA. It is up to mail services and their MTAs to directly prevent It is up to mail services and their MTAs to directly prevent cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be cross-user forgery: based on SMTP AUTH ([RFC4954]), users have to be restricted to using only those E-Mail addresses that are actually restricted to using only those email addresses that are actually under their control (see [RFC4409], Section 6.1). Another means to under their control (see [RFC6409], Section 6.1). Another means to verify the identity of individual users is message cryptography such verify the identity of individual users is message cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851]). as PGP ([RFC4880]) or S/MIME ([RFC5751]). 10.5. Untrusted Information Sources 10.5. Untrusted Information Sources SPF uses information supplied by third parties, such as the "HELO" An SPF compliant receiver gathers information from the SMTP commands domain name, the "MAIL FROM" address, and SPF records. This it receives and from the published DNS records of the sending domain information is then passed to the receiver in the Received-SPF: trace holder, (e.g., "HELO" domain name, the "MAIL FROM" address from the fields and possibly returned to the client MTA in the form of an SMTP envelope, and SPF DNS records published by the domain holder). rejection message. This information must be checked for invalid characters and excessively long lines. When the authorization check fails, an explanation string may be 10.5.1. Recorded Results This information, passed to the receiver in the Received-SPF: or Authentication-Results: trace fields, may be returned to the client MTA as an SMTP rejection message. If such an SMTP rejection message is generated, the information from the trace fields has to be checked for such problems as invalid characters and excessively long lines. 10.5.2. External Explanations When the authorization check fails, an explanation string could be included in the reject response. Both the sender and the rejecting included in the reject response. Both the sender and the rejecting receiver need to be aware that the explanation was determined by the receiver need to be aware that the explanation was determined by the publisher of the SPF record checked and, in general, not the publisher of the SPF record checked and, in general, not the receiver. The explanation may contain malicious URLs, or it may be receiver. The explanation can contain malicious URLs, or it might be offensive or misleading. offensive or misleading. This is probably less of a concern than it may initially seem since Explanations returned to sender domains due to "exp" modifiers, such messages are returned to the sender, and the explanation strings (Section 6.2), were generated by the sender policy published by the come from the sender policy published by the domain in the identity domain holders themselves. As long as messages are only returned claimed by that very sender. As long as the DSN is not redirected to with non-delivery notification ([RFC3464]) to domains publishing the someone other than the actual sender, the only people who see explanation strings from their own DNS SPF records, the only affected malicious explanation strings are people whose messages claim to be parties are the original publishers of the domain's SPF records. from domains that publish such strings in their SPF records. In practice, DSNs can be misdirected, such as when an MTA accepts an In practice, such non-delivery notifications can be misdirected, such E-Mail and then later generates a DSN to a forged address, or when an as when an MTA accepts an email and only later generates the E-Mail forwarder does not direct the DSN back to the original sender. notification to a forged address, or when an email forwarder does not direct the bounce back to the original sender. 10.5.3. Macro Expansion Macros (Section 8) allow senders to inject arbitrary text (any non- null [US-ASCII] character) into receiver DNS queries. It is necesary to be prepared for hostile or unexpected content. 10.6. Privacy Exposure 10.6. Privacy Exposure Checking SPF records causes DNS queries to be sent to the domain Checking SPF records causes DNS queries to be sent to the domain owner. These DNS queries, especially if they are caused by the owner. These DNS queries, especially if they are caused by the "exists" mechanism, can contain information about who is sending "exists" mechanism, can contain information about who is sending E-Mail and likely to which MTA the E-Mail is being sent. This can email and likely to which MTA the email is being sent. This can introduce some privacy concerns, which may be more or less of an introduce some privacy concerns, which are more or less of an issue issue depending on local laws and the relationship between the domain depending on local laws and the relationship between the domain owner owner and the person sending the E-Mail. and the person sending the email. 11. Contributors and Acknowledgements 11. Contributors and Acknowledgements This document is largely based on the work of Meng Weng Wong and Mark This document is largely based on the work of Meng Weng Wong, Mark Lentczner. Although, as this section acknowledges, many people have Lentczner, and Wayne Schlitt. Although, as this section contributed to this document, a very large portion of the writing and acknowledges, many people have contributed to this document, a very editing are due to Meng and Mark. large portion of the writing and editing are due to Meng, Mark, and Wayne. This design owes a debt of parentage to [RMX] by Hadmut Danisch and This design owes a debt of parentage to [RMX] by Hadmut Danisch and to [DMP] by Gordon Fecyk. The idea of using a DNS record to check to [DMP] by Gordon Fecyk. The idea of using a DNS record to check the legitimacy of an E-Mail address traces its ancestry further back the legitimacy of an email address traces its ancestry further back through messages on the namedroppers mailing list by Paul Vixie through messages on the namedroppers mailing list by Paul Vixie [Vixie] (based on suggestion by Jim Miller) and by David Green [Vixie] (based on suggestion by Jim Miller) and by David Green [Green]. [Green]. Philip Gladstone contributed the concept of macros to the Philip Gladstone contributed the concept of macros to the specification, multiplying the expressiveness of the language and specification, multiplying the expressiveness of the language and making per-user and per-IP lookups possible. making per-user and per-IP lookups possible. The authors would also like to thank the literally hundreds of The authors of both this document and [RFC4408] would also like to individuals who have participated in the development of this design. thank the literally hundreds of individuals who have participated in They are far too numerous to name, but they include the following: the development of this design. They are far too numerous to name, but they include the following: The participants in the SPFbis working group. The folks on the spf-discuss mailing list. The folks on the spf-discuss mailing list. The folks on the SPAM-L mailing list. The folks on the SPAM-L mailing list. The folks on the IRTF ASRG mailing list. The folks on the IRTF ASRG mailing list. The folks on the IETF MARID mailing list. The folks on the IETF MARID mailing list. The folks on #perl. The folks on #perl. 12. IANA Considerations 12. IANA Considerations 12.1. The SPF DNS Record Type 12.1. The SPF DNS Record Type The IANA has assigned a new Resource Record Type and Qtype from the Per [RFC4408], the IANA assigned the Resource Record Type and Qtype DNS Parameters Registry for the SPF RR type with code 99. from the DNS Parameters Registry for the SPF RR type with code 99. The format of this type is identical to the TXT RR [RFC1035]. The character content of the record is encoded as [US-ASCII]. Use of this record type is obsolete for SPF Version 1. IANA is requested to add an annotation to the SPF RRTYPE saying "(OBSOLETE - use TXT)" in the DNS Parameters registry. [NOTE TO RFC EDITOR: (to be changed to " ... has added ..." upon publication)] 12.2. The Received-SPF Mail Header Field 12.2. The Received-SPF Mail Header Field Per [RFC3864], the "Received-SPF:" header field is added to the IANA Per [RFC3864], the "Received-SPF:" header field is added to the IANA Permanent Message Header Field Registry. The following is the Permanent Message Header Field Registry. The following is the registration template: registration template: Header field name: Received-SPF Header field name: Received-SPF Applicable protocol: mail ([RFC2822]) Applicable protocol: mail ([RFC5322]) Status: Experimental Status: Standards Track Author/Change controller: IETF Author/Change controller: IETF Specification document(s): RFC 4408 Specification document(s): RFC XXXX Related information: [NOTE TO RFC EDITOR: (this document)] Requesting SPF Council review of any proposed changes and additions to this field are recommended. For information about 12.3. SPF Modifier Registration the SPF Council see http://www.openspf.org/Council [RFC6652] created a new SPF Modifier Registration. IANA is requested to change the reference for the exp and redirect modifiers from [RFC4408] to this document. Their status should not be changed. 13. References 13. References 13.1. Normative References 13.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", April 2001. RFC 3463, January 2003. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. September 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, 3986, January 2005. RFC 3986, January 2005. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Specifications: ABNF", RFC 4234, October 2005. Architecture", RFC 4291, February 2006. [US-ASCII] American National Standards Institute (formerly United [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [US-ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for Information Interchange, X3.4", 1968. Information Interchange, X3.4", 1968. ANSI X3.4-1968 has been replaced by newer versions with slight ANSI X3.4-1968 has been replaced by newer versions with modifications, but the 1968 version remains definitive for slight modifications, but the 1968 version remains the Internet. definitive for the Internet. 13.2 Informative References 13.2. Informative References [DMP] Fecyk, G., "Designated Mailers Protocol". Work In Progress [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987. [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1996. August 1996. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS "OpenPGP Message Format", RFC 2440, November 1998. NCACHE)", RFC 2308, March 1998. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for RFC 2554, March 1999. specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [RFC3696] Klensin, J., "Application Techniques for Checking and [RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004. Transformation of Names", RFC 3696, February 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3834] Moore, K., "Recommendations for Automatic Responses to Extensions (S/MIME) Version 3.1 Message Specification", Electronic Mail", RFC 3834, August 2004. RFC 3851, July 2004. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) RFC 4409, April 2006. for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. [RMX] Danish, H., "The RMX DNS RR Type for light weight sender [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing authentication", Work In Progress (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. [DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007. [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010. [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011. [RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An Applicability Statement for SMTP", RFC 6647, June 2012. [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012. [RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments", RFC 6686, July 2012. [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender authentication". Work In Progress [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. Appendix A. Collected ABNF Appendix A. Collected ABNF This section is normative and any discrepancies with the ABNF This section is normative and any discrepancies with the ABNF fragments in the preceding text are to be resolved in favor of this fragments in the preceding text are to be resolved in favor of this grammar. grammar. See [RFC4234] for ABNF notation. Please note that as per this ABNF See [RFC5234] for ABNF notation. Please note that as per this ABNF definition, literal text strings (those in quotes) are case- definition, literal text strings (those in quotes) are case- insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". record = version terms *SP record = version terms *SP version = "v=spf1" version = "v=spf1" terms = *( 1*SP ( directive / modifier ) ) terms = *( 1*SP ( directive / modifier ) ) directive = [ qualifier ] mechanism directive = [ qualifier ] mechanism qualifier = "+" / "-" / "?" / "~" qualifier = "+" / "-" / "?" / "~" skipping to change at page 42, line 38 skipping to change at page 57, line 38 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] PTR = "ptr" [ ":" domain-spec ] PTR = "ptr" [ ":" domain-spec ] IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] exists = "exists" ":" domain-spec exists = "exists" ":" domain-spec modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string ; where name is not any known modifier ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255 ; conventional dotted quad notation. e.g., 192.0.2.0 ; conventional dotted quad notation. e.g., 192.0.2.0 ip6-network = ip6-network = ; e.g., 2001:DB8::CD30 ; e.g., 2001:DB8::CD30 domain-spec = macro-string domain-end domain-spec = macro-string domain-end domain-end = ( "." toplabel [ "." ] ) / macro-expand domain-end = ( "." toplabel [ "." ] ) / macro-expand toplabel = ( *alphanum ALPHA *alphanum ) / toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) ; (see [RFC3696], Section 2 for background) alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT explain-string = *( macro-string / SP ) explain-string = *( macro-string / SP ) macro-string = *( macro-expand / macro-literal ) macro-string = *( macro-expand / macro-literal ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) / "%%" / "%_" / "%-" / "%%" / "%_" / "%-" macro-literal = %x21-24 / %x26-7E macro-literal = %x21-24 / %x26-7E ; visible characters except "%" ; visible characters except "%" macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / "c" / "r" / "t" "c" / "r" / "t" / "v" transformers = *DIGIT [ "r" ] transformers = *DIGIT [ "r" ] delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF [ key-value-list ] CRLF result = "Pass" / "Fail" / "SoftFail" / "Neutral" / result = "pass" / "fail" / "softfail" / "neutral" / "None" / "TempError" / "PermError" "none" / "temperror" / "permerror" key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) [";"] [";"] key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / "problem" / "receiver" / identity / mechanism / "x-" name / name mechanism / name identity = "mailfrom" ; for the "MAIL FROM" identity identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / "helo" ; for the "HELO" identity / name ; other identities / name ; other identities dot-atom = ALPHA = quoted-string = DIGIT = <0-9 as per [RFC5234]> comment = SP = CFWS = domain = FWS = dot-atom = CRLF = quoted-string = comment = CFWS = FWS = CRLF = authserv-id = reasonspec = Appendix B. Extended Examples Appendix B. Extended Examples These examples are based on the following DNS setup: These examples are based on the following DNS setup: ; A domain with two mail servers, two hosts ; A domain with two mail servers, two hosts ; and two servers at the domain name ; and two servers at the domain name $ORIGIN example.com. $ORIGIN example.com. @ MX 10 mail-a @ MX 10 mail-a MX 20 mail-b MX 20 mail-b skipping to change at page 44, line 46 skipping to change at page 60, line 46 ; A rogue reverse IP domain that claims to be ; A rogue reverse IP domain that claims to be ; something it's not ; something it's not $ORIGIN 0.0.10.in-addr.arpa. $ORIGIN 0.0.10.in-addr.arpa. 4 PTR bob.example.com. 4 PTR bob.example.com. B.1. Simple Examples B.1. Simple Examples These examples show various possible published records for These examples show various possible published records for example.com and which values if would cause check_host() to example.com and which values if would cause check_host() to return "Pass". Note that is "example.com". return "pass". Note that is "example.com". v=spf1 +all v=spf1 +all -- any passes -- any passes v=spf1 a -all v=spf1 a -all -- hosts 192.0.2.10 and 192.0.2.11 pass -- hosts 192.0.2.10 and 192.0.2.11 pass v=spf1 a:example.org -all v=spf1 a:example.org -all -- no sending hosts pass since example.org has no A records -- no sending hosts pass since example.org has no A records v=spf1 mx -all v=spf1 mx -all -- sending hosts 192.0.2.129 and 192.0.2.130 pass -- sending hosts 192.0.2.129 and 192.0.2.130 pass v=spf1 mx:example.org -all v=spf1 mx:example.org -all -- sending host 192.0.2.140 passes -- sending host 192.0.2.140 passes v=spf1 mx mx:example.org -all v=spf1 mx mx:example.org -all -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass v=spf1 mx/30 mx:example.org/30 -all v=spf1 mx/30 mx:example.org/30 -all -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes v=spf1 ptr -all v=spf1 ptr -all -- sending host 192.0.2.65 passes (reverse DNS is valid and is in -- sending host 192.0.2.65 passes (reverse DNS is valid and is in example.com) example.com) -- sending host 192.0.2.140 fails (reverse DNS is valid, but not -- sending host 192.0.2.140 fails (reverse DNS is valid, but not in example.com) in example.com) -- sending host 10.0.0.4 fails (reverse IP is not valid) -- sending host 10.0.0.4 fails (reverse IP is not valid) v=spf1 ip4:192.0.2.128/28 -all v=spf1 ip4:192.0.2.128/28 -all -- sending host 192.0.2.65 fails -- sending host 192.0.2.65 fails -- sending host 192.0.2.129 passes -- sending host 192.0.2.129 passes B.2. Multiple Domain Example B.2. Multiple Domain Example These examples show the effect of related records: These examples show the effect of related records: example.org: "v=spf1 include:example.com include:example.net -all" example.org: "v=spf1 include:example.com include:example.net -all" This record would be used if mail from example.org actually came This record would be used if mail from example.org actually came through servers at example.com and example.net. Example.org's through servers at example.com and example.net. Example.org's designated servers are the union of example.com's and example.net's designated servers are the union of example.com's and example.net's skipping to change at page 46, line 10 skipping to change at page 62, line 12 These records allow a set of domains that all use the same mail These records allow a set of domains that all use the same mail system to make use of that mail system's record. In this way, only system to make use of that mail system's record. In this way, only the mail system's record needs to be updated when the mail setup the mail system's record needs to be updated when the mail setup changes. These domains' records never have to change. changes. These domains' records never have to change. B.3. DNSBL Style Example B.3. DNSBL Style Example Imagine that, in addition to the domain records listed above, there Imagine that, in addition to the domain records listed above, there are these: are these: $ORIGIN _spf.example.com. mary.mobile-users A $ORIGIN _spf.example.com. 127.0.0.2 fred.mobile-users A 127.0.0.2 mary.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2 The following records describe users at example.com who mail from The following records describe users at example.com who mail from arbitrary servers, or who mail from personal servers. arbitrary servers, or who mail from personal servers. example.com: example.com: v=spf1 mx v=spf1 mx include:mobile-users._spf.%{d} include:mobile-users._spf.%{d} skipping to change at page 47, line 5 skipping to change at page 63, line 5 "-include:ip4._spf.%{d} " "-include:ip4._spf.%{d} " "-include:ptr._spf.%{d} " "-include:ptr._spf.%{d} " "+all" ) "+all" ) ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" ptr._spf.example.com. SPF "v=spf1 -ptr +all" ptr._spf.example.com. SPF "v=spf1 -ptr +all" This example shows how the "-include" mechanism can be useful, how an This example shows how the "-include" mechanism can be useful, how an SPF record that ends in "+all" can be very restrictive, and the use SPF record that ends in "+all" can be very restrictive, and the use of De Morgan's Law. of De Morgan's Law. Authors' Addresses Appendix C. Change History Meng Weng Wong Changes since RFC 4408 (to be removed prior to publication) Singapore EMail: mengwong+spf@pobox.com Moved to standards track Wayne Schlitt Authors updated 4615 Meredeth #9 Lincoln Nebraska, NE 68506 United States of America EMail: wayne@schlitt.net IESG Note regarding experimental use replaced with discussion of URI: http://www.schlitt.net/spf/ results Full Copyright Statement Process errata: Copyright (C) The Internet Society (2006). Resolved Section 2.5.7 PermError on invalid domains after macro expansion errata in favor of documenting that different clients produce different results. This document is subject to the rights, licenses and restrictions Add %v macro to ABNF grammar contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an Replace "uric" by "unreserved" "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Recommend an SMTP reply code for optional permerror rejections The IETF takes no position regarding the validity or scope of any Correct syntax in Received-SPF examples Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any Fix unknown-modifier clause is too greedy in ABNF assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any Correct use of empty domain-spec on exp modifier copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Fix minor typo errata Funding for the RFC Editor function is provided by the IETF Convert to spfbis working group draft, Administrative Support Activity (IASA). draft-ietf-spfbis-4408bis-00 Addressed Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors by giving the option to turn repeated SERVFAIL into permerror and adding RFC 2308 reference. Clarified text about IPv4 mapped addresses to resolve test suite ambiguity Clarified ambiguity about result when more than 10 "mx" or "ptr" records are returned for lookup to specify permerror. This resolves one of the test suite ambiguities Made all references to result codes lower case per issue #7 Adjusted section 2.2 Requirement to check mail from per issue #15 Added missing "v" element in macro-letter in the collected ABNF per issue #16 - section 8.1 was already fixed in the pre-WG draft Marked ptr and "p" macro deprecated/SHOULD NOT use per issue #27 Expunged lower case may from the draft per issue #8 Expunged "x-" name as an obsolete concept Updated obslete references: RFC2821 to RFC5321, RFC2822 to RFC5322, and RFC4234 to RFC5234 Refer to RFC6647 to describe greylisting instead of trying to describe it directly. Updated informative references to the current versions. Added definition for deprecated since there are questions. Start to rework section 9 with some RFC5598 terms. Added mention of RFC 6552 feedback reports in section 9. Added draft-ietf-spfbis-experiment as an informational reference. Drop Type SPF. Try and clarify informational nature of RFC3696 Fix ABNF nits and add missing definitions per Bill's ABNF checker. Make DNS lookup time limit SHOULD instead of MAY. Reorganize and clarify processing limits. Move hard limits to new section 4.6.4, Evaluation Limits. Move advice to non-normative section 9. Removed paragraph in section 10.1 about limiting total data volumes as it is unused (and removable per the charter) and serves no purpose (it isn't something that actually can be implemented in any reasonable way). Added text and figures from Alessandro Vesely in section 9.1 to better explain DNS resource limits. Multiple editorial fixes from Murray Kucherawy's review. Also based on Murray's review, reworked SMTP identity definitions and made RFC 5598 a normative reference instead of informative. This is a downref that will have to be mentioned in the last call. Added RFC 3834 as an informative reference about backscatter. Added IDN requirements and normative reference to RFC 5890 to deal with the question "like DKIM did it.: Added informative reference to RFC 4632 for CIDR and use CIDR prefix length instead of CIDR-length to match its terminology. Added RFC 5782 informative reference on DNSxLs to support improving the exists description. Added text on creating a Authentication-Results header field that matches the Received-SPF header field information and added a normative reference to RFC 5451. Added informative reference to RFC 2782 due to SRV mention. Added informative reference to RFC 3464 due to DSN mention. Added informative reference to RFC 5617 for it's DNS wildcard use. Added informative reference to RFC 5782 to enhance the explanation of how the exists mechanism works. Clarified the intended match/ no-match method. Added new sections on Receiver policy for SPF pass, fail, and permerror. Added new section 9 discussion on treatment of bounces and the significance of HELO records. Added request to IANA to update the SPF modifier registry. Author's Address Scott Kitterman Kitterman Technical Services 3611 Scheel Dr Ellicott City, MD 21042 United States of America Email: scott@kitterman.com End of changes. 318 change blocks. 943 lines changed or deleted 1353 lines changed or added This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ rfc4408.txt draft-ietf-spfbis-4408bis-08.txt Network Working Group M. Wong Network Working Group S. Kitterman Request for Comments: 4408 W. Schlitt Internet-Draft Kitterman Technical Services Category: Experimental April 2006 Obsoletes: 4408 (if approved) October 22, 2012 Intended status: Standards Track Sender Policy Framework (SPF) for Expires: April 25, 2013 Authorizing Use of Domains in E-Mail, Version 1 Status of This Memo Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 draft-ietf-spfbis-4408bis-08.txt This memo defines an Experimental Protocol for the Internet Abstract community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby an ADMD can explicitly authorize the hosts that are allowed to use its domain names, and a receiving host can check such authorization. Copyright (C) The Internet Society (2006). This document obsoletes RFC4408. IESG Note Status of this Memo The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) This Internet-Draft is submitted in full conformance with the are published simultaneously as Experimental RFCs, although there is provisions of BCP 78 and BCP 79. no general technical consensus and efforts to reconcile the two approaches have failed. As such, these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group. The IESG takes no position about which approach is to be preferred Internet-Drafts are working documents of the Internet Engineering and cautions the reader that there are serious open issues for each Task Force (IETF). Note that other groups may also distribute approach and concerns about using them in tandem. The IESG believes working documents as Internet-Drafts. The list of current Internet- that documenting the different approaches does less harm than not Drafts is at http://datatracker.ietf.org/drafts/current/. documenting them. Note that the Sender ID experiment may use DNS records that may have Internet-Drafts are draft documents valid for a maximum of six months been created for the current SPF experiment or earlier versions in and may be updated, replaced, or obsoleted by other documents at any this set of experiments. Depending on the content of the record, time. It is inappropriate to use Internet-Drafts as reference this may mean that Sender-ID heuristics would be applied incorrectly material or to cite them other than as "work in progress." to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt. Participants relying on Sender ID experiment DNS records are warned This Internet-Draft will expire on April 25, 2013. that they may lose valid messages in this set of circumstances. aParticipants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict. Participants in the Sender-ID experiment need to be aware that the Copyright Notice way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem. The community is invited to observe the success or failure of the two Copyright (c) 2012 IETF Trust and the persons identified as the approaches during the two years following publication, in order that document authors. All rights reserved. a community consensus can be reached in the future. Abstract This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. E-mail on the Internet can be forged in a number of ways. In This document may contain material from IETF Documents or IETF particular, existing protocols place no restriction on what a sending Contributions published or made publicly available before November host can use as the reverse-path of a message or the domain given on 10, 2008. The person(s) controlling the copyright in some of this the SMTP HELO/EHLO commands. This document describes version 1 of material may not have granted the IETF Trust the right to allow the Sender Policy Framework (SPF) protocol, whereby a domain may modifications of such material outside the IETF Standards Process. explicitly authorize the hosts that are allowed to use its domain Without obtaining an adequate license from the person(s) controlling name, and a receiving host may check such authorization. the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents Table of Contents 1. Introduction ....................................................4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Protocol Status ............................................4 1.1. Protocol Status . . . . . . . . . . . . . . . . . . . . . 6 1.2. Terminology ................................................5 1.2. Experimental History . . . . . . . . . . . . . . . . . . . 7 2. Operation .......................................................5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. The HELO Identity ..........................................5 1.3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. The MAIL FROM Identity .....................................5 1.3.2. Imported Definitions . . . . . . . . . . . . . . . . . 7 2.3. Publishing Authorization ...................................6 1.3.3. Mail From Definition . . . . . . . . . . . . . . . . . 7 2.4. Checking Authorization .....................................6 1.3.4. HELO Definition . . . . . . . . . . . . . . . . . . . 8 2.5. Interpreting the Result ....................................7 1.3.5. Deprecated . . . . . . . . . . . . . . . . . . . . . . 8 2.5.1. None ................................................8 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.2. Neutral .............................................8 2.1. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9 2.5.3. Pass ................................................8 2.2. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 9 2.5.4. Fail ................................................8 2.3. Publishing Authorization . . . . . . . . . . . . . . . . . 9 2.5.5. SoftFail ............................................9 2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 10 2.5.6. TempError ...........................................9 2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 11 2.5.7. PermError ...........................................9 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 12 3. SPF Records .....................................................9 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Publishing ................................................10 2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.1. DNS Resource Record Types ..........................10 2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1.2. Multiple DNS Records ...............................11 2.5.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.3. Multiple Strings in a Single DNS record ............11 2.5.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 13 3.1.4. Record Size ........................................11 2.5.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 13 3.1.5. Wildcard Records ...................................11 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 14 4. The check_host() Function ......................................12 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 15 4.1. Arguments .................................................12 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 15 4.2. Results ...................................................13 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 15 4.3. Initial Processing ........................................13 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 15 4.4. Record Lookup .............................................13 4. The check_host() Function . . . . . . . . . . . . . . . . . . 17 4.5. Selecting Records .........................................13 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. Record Evaluation .........................................14 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6.1. Term Evaluation ....................................14 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 17 4.6.2. Mechanisms .........................................15 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 18 4.6.3. Modifiers ..........................................15 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 18 4.7. Default Result ............................................16 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 18 4.8. Domain Specification ......................................16 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 19 5. Mechanism Definitions ..........................................16 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 19 5.1. "all" .....................................................17 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 20 5.2. "include" .................................................18 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 20 5.3. "a" .......................................................19 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 21 5.4. "mx" ......................................................20 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 21 5.5. "ptr" .....................................................20 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 22 5.6. "ip4" and "ip6" ...........................................21 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.7. "exists" ..................................................22 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Modifier Definitions ...........................................22 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. redirect: Redirected Query ................................23 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2. exp: Explanation ..........................................23 5.5. "ptr" (deprecated) . . . . . . . . . . . . . . . . . . . . 25 7. The Received-SPF Header Field ..................................25 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 27 8. Macros .........................................................27 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Macro Definitions .........................................27 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 29 8.2. Expansion Examples ........................................30 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 29 9. Implications ...................................................31 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 30 9.1. Sending Domains ...........................................31 7. Recording The Result . . . . . . . . . . . . . . . . . . . . . 32 9.2. Mailing Lists .............................................32 7.1. The Received-SPF Header Field . . . . . . . . . . . . . . 32 9.3. Forwarding Services and Aliases ...........................32 7.2. SPF Results in the Authentication-Results Header Field . . 34 9.4. Mail Services .............................................34 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.5. MTA Relays ................................................34 8.1. Macro Definitions . . . . . . . . . . . . . . . . . . . . 36 10. Security Considerations .......................................35 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 39 10.1. Processing Limits ........................................35 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 41 10.2. SPF-Authorized E-Mail May Contain Other False 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 41 Identities ...............................................37 9.1.1. DNS Resource Considerations . . . . . . . . . . . . . 41 10.3. Spoofed DNS and IP Data ..................................37 9.1.2. Administrator's Considerations . . . . . . . . . . . . 42 10.4. Cross-User Forgery .......................................37 9.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 43 10.5. Untrusted Information Sources ............................38 9.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 43 10.6. Privacy Exposure .........................................38 9.2.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 43 11. Contributors and Acknowledgements .............................38 9.2.2. Forwarding Services and Aliases . . . . . . . . . . . 44 12. IANA Considerations ...........................................39 9.2.3. Mail Services . . . . . . . . . . . . . . . . . . . . 46 12.1. The SPF DNS Record Type ..................................39 9.2.4. MTA Relays . . . . . . . . . . . . . . . . . . . . . . 46 12.2. The Received-SPF Mail Header Field .......................39 9.3. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 47 13. References ....................................................39 9.3.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . 47 13.1. Normative References .....................................39 9.3.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . 47 13.2. Informative References ...................................40 9.3.3. Policy For SPF Permerror . . . . . . . . . . . . . . . 48 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49 Appendix A. Collected ABNF .......................................42 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 49 Appendix B. Extended Examples ....................................44 10.2. SPF-Authorized Email May Contain Other False Identities . 49 B.1. Simple Examples ..........................................44 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 50 B.2. Multiple Domain Example ..................................45 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 50 B.3. DNSBL Style Example ......................................46 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 50 B.4. Multiple Requirements Example ............................46 10.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 50 10.5.2. External Explanations . . . . . . . . . . . . . . . . 51 10.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 51 10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 51 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 52 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 53 12.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 53 12.3. SPF Modifier Registration . . . . . . . . . . . . . . . . 53 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 13.1. Normative References . . . . . . . . . . . . . . . . . . . 54 13.2. Informative References . . . . . . . . . . . . . . . . . . 55 Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 57 Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 60 B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 60 B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 61 B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 62 B.4. Multiple Requirements Example . . . . . . . . . . . . . . 62 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 66 1. Introduction 1. Introduction The current E-Mail infrastructure has the property that any host The current email infrastructure has the property that any host injecting mail into the mail system can identify itself as any domain injecting mail into the system can use any DNS domain name it wants name it wants. Hosts can do this at a variety of levels: in in each of the various identifiers specified by [RFC5321] and particular, the session, the envelope, and the mail headers. [RFC5322]. Although this feature is desirable in some circumstances, Although this feature is desirable in some circumstances, it is a it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). spam). Furthermore, many domain owning ADMDs (ADministrative Furthermore, many domain name holders are understandably concerned Management Domains, see [RFC5598]) are understandably concerned about about the ease with which other entities may make use of their domain the ease with which other entities can make use of their domain names, often with malicious intent. names, often with malicious intent. This document defines a protocol by which domain owners may authorize This document defines a protocol by which ADMDs can authorize hosts hosts to use their domain name in the "MAIL FROM" or "HELO" identity. to use their domain names in the "MAIL FROM" or "HELO" identities. Compliant domain holders publish Sender Policy Framework (SPF) Compliant ADMDs publish Sender Policy Framework (SPF) records in the records specifying which hosts are permitted to use their names, and DNS specifying which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the compliant mail receivers use the published SPF records to test the authorization of sending Mail Transfer Agents (MTAs) using a given authorization of sending Mail Transfer Agents (MTAs) using a given "HELO" or "MAIL FROM" identity during a mail transaction. "HELO" or "MAIL FROM" identity during a mail transaction. An additional benefit to mail receivers is that after the use of an An additional benefit to mail receivers is that after the use of an identity is verified, local policy decisions about the mail can be identity is verified, local policy decisions about the mail can be made based on the sender's domain, rather than the host's IP address. made based on the sender's domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses. Furthermore, be more accurate than reputation of host IP addresses. Furthermore, if a claimed identity fails verification, local policy can take if a claimed identity fails verification, local policy can take stronger action against such E-Mail, such as rejecting it. stronger action against such email, such as rejecting it. 1.1. Protocol Status 1.1. Protocol Status SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many discussed and debated in development forums. discussed and debated in development forums. The protocol was originally defined in [RFC4408], which this document replaces. The goal of this document is to clearly document the protocol defined [RFC4408] was designed to clearly document the protocol defined by by earlier draft specifications of SPF as used in existing earlier draft specifications of SPF as used in existing implementations. This conception of SPF is sometimes called "SPF implementations. This updated specification is intended to clarify Classic". It is understood that particular implementations and identified ambiguities in [RFC4408], resolve techincal issues deployments may differ from, and build upon, this work. It is hoped identified in post-RFC 4408 deplyment experience, and document widely that we have nonetheless captured the common understanding of SPF deployed extensions to SPF that have been developed since [RFC4408] version 1. was published. 1.2. Terminology 1.2. Experimental History This document updates and replaces RFC 4408 that was part of a group of simultaneously published Experimental RFCs (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the community observe the success or failure of the two approaches documented in these RFCs during the two years following publication, in order that a community consensus could be reached in the future. SPF is widely deployed by large and small email providers alike. There are multiple, interoperable implementations. For SPF (as documented in RFC 4408) a careful effort was made to collect and document lessons learned and errata during the two year period. The errata list has been stable (no new submissions) and only minor protocol lessons learned were identified. Resolution of the IESG's experiment is documented in [RFC6686]. 1.3. Terminology 1.3.1. Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3.2. Imported Definitions The ABNF tokens "ALPHA", "DIGIT", and "SP" are defined in [RFC5234]. The token "local-part" is defined in [RFC5321]. "dot-atom", "quoted-string", "comment", "CFWS", "FWS", and "CRLF" are defined in [RFC5322]. 1.3.3. Mail From Definition This document is concerned with the portion of a mail message This document is concerned with the portion of a mail message commonly called "envelope sender", "return path", "reverse path", commonly called "envelope sender", "return path", "reverse path", "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom. either not well defined or often used casually, this document defines Since these terms are either not well defined or often used casually, the "MAIL FROM" identity in Section 2.2. Note that other terms that this document uses "MAIL FROM" for consistency. This means the may superficially look like the common terms, such as "reverse-path", RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that are used only with the defined meanings from normative documents. might superficially look like the common terms, such as "reverse- path", are used only with the defined meanings from normative documents. 2. Operation 1.3.4. HELO Definition 2.1. The HELO Identity This document also makes use of the HELO/EHLO identity. The "HELO" identity derives from either the SMTP HELO or EHLO command (see [RFC5321]). Since HELO and EHLO can, in many cases, be used interchangeably, they are identified commonly as "HELO" in this document. This means RFC5321.HELO/.EHLO as defined in [RFC5598]. These commands supply the identity of the SMTP client (sending host) for the SMTP session. The "HELO" identity derives from either the SMTP HELO or EHLO command 1.3.5. Deprecated (see [RFC2821]). These commands supply the SMTP client (sending host) for the SMTP session. Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF clients must be prepared for the "HELO" identity to be malformed or an IP address literal. At the time of this writing, many legitimate E-Mails are delivered with invalid HELO domains. It is RECOMMENDED that SPF clients not only check the "MAIL FROM" There are [RFC4408] features that are marked "deprecated". In the context of this document, deprecated means that senders SHOULD NOT publish SPF records that make use of such features because they might be removed entirely in future updates to the protocol. Such features do, however, remain part of the SPF protocol and receiving systems MUST support them unless this document explicitly says otherwise. 2. Operation 2.1. The "HELO" Identity It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM" identity, but also separately check the "HELO" identity by applying identity, but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the the check_host() function (Section 4) to the "HELO" identity as the . . Checking "HELO" promotes consistency of results and can reduce DNS resource usage. Additionally, since SPF records published for "HELO" identities refer to a single host, when available, they are a very reliable source of host authorization status. 2.2. The MAIL FROM Identity Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF verifiers MUST be prepared for the "HELO" identity to be malformed or an IP address literal. This SPF check can only be performed when the "HELO" string is a valid fully qualified domain. The "MAIL FROM" identity derives from the SMTP MAIL command (see 2.2. The "MAIL FROM" Identity [RFC2821]). This command supplies the "reverse-path" for a message, which generally consists of the sender mailbox, and is the mailbox to which notification messages are to be sent if there are problems delivering the message. [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in SPF verifiers MUST check the ""MAIL FROM" identity if a completed RFC 2821). In this case, there is no explicit sender mailbox, and "HELO" check has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the . [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in [RFC5321]). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document mail system itself. When the reverse-path is null, this document defines the "MAIL FROM" identity to be the mailbox composed of the defines the "MAIL FROM" identity to be the mailbox composed of the localpart "postmaster" and the "HELO" identity (which may or may not local-part "postmaster" and the "HELO" identity (which might or might have been checked separately before). not have been checked separately before). SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the . 2.3. Publishing Authorization 2.3. Publishing Authorization An SPF-compliant domain MUST publish a valid SPF record as described An SPF-compliant domain MUST have valid SPF records as described in in Section 3. This record authorizes the use of the domain name in Section 3. These records authorize the use of the relevant domain the "HELO" and "MAIL FROM" identities by the MTAs it specifies. names in the "HELO" and "MAIL FROM" identities by the MTAs specified therein. If domain owners choose to publish SPF records, it is RECOMMENDED SPF results can be used to make both positive (source is authorized) that they end in "-all", or redirect to other records that do, so and negative (source is not authorized) determinations. If domain that a definitive determination of authorization can be made. owners choose to publish SPF records and want to support receivers making negative authorization determinations, then they MUST publish records that end in "-all", or redirect to other records that do, otherwise, no definitive determination of authorization can be made. Potential issues and mitigations associated with negative determinations are discussed in Section 9. Domain holders may publish SPF records that explicitly authorize no ADMDs can publish SPF records that explicitly authorize no hosts for hosts if mail should never originate using that domain. domain names that are neither used in the domain part of email addresses nor expected to originate mail. When changing SPF records, care must be taken to ensure that there is When changing SPF records, care has to be taken to ensure that there a transition period so that the old policy remains valid until all is a transition period so that the old policy remains valid until all legitimate E-Mail has been checked. legitimate email can reasonably expect to have been checked. This can be as much as 30 days. 2.4. Checking Authorization 2.4. Checking Authorization A mail receiver can perform a set of SPF checks for each mail message A mail receiver can perform a set of SPF checks for each mail message it receives. An SPF check tests the authorization of a client host it receives. An SPF check tests the authorization of a client host to emit mail with a given identity. Typically, such checks are done to emit mail with a given identity. Typically, such checks are done by a receiving MTA, but can be performed elsewhere in the mail by a receiving MTA, but can be performed elsewhere in the mail processing chain so long as the required information is available and processing chain so long as the required information is available and reliable. At least the "MAIL FROM" identity MUST be checked, but it reliable. At least the "MAIL FROM" identity MUST be checked, but it is RECOMMENDED that the "HELO" identity also be checked beforehand. is RECOMMENDED that the "HELO" identity also be checked beforehand. Without explicit approval of the domain owner, checking other Without explicit approval of the domain owner, checking other identities against SPF version 1 records is NOT RECOMMENDED because identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. For there are cases that are known to give incorrect results. For example, almost all mailing lists rewrite the "MAIL FROM" identity example, almost all mailing lists rewrite the "MAIL FROM" identity (see Section 9.2), but some do not change any other identities in the (see Section 9.2.1), but some do not change any other identities in message. The scenario described in Section 9.3, sub-section 1.2, is the message. The scenario described in Section 9.2.2, sub-section another example. Documents that define other identities should 1.2, is another example. Documents that define other identities will define the method for explicit approval. have to define the method for explicit approval. It is possible that mail receivers will use the SPF check as part of It is possible that mail receivers will use the SPF check as part of a larger set of tests on incoming mail. The results of other tests a larger set of tests on incoming mail. The results of other tests may influence whether or not a particular SPF check is performed. might influence whether or not a particular SPF check is performed. For example, finding the sending host's IP address on a local white For example, finding the sending host's IP address on a local white list may cause all other tests to be skipped and all mail from that list might cause all other tests to be skipped and all mail from that host to be accepted. host to be accepted. When a mail receiver decides to perform an SPF check, it MUST use a When a mail receiver decides to perform an SPF check, it MUST use a correctly-implemented check_host() function (Section 4) evaluated correctly-implemented check_host() function (Section 4) evaluated with the correct parameters. Although the test as a whole is with the correct parameters. Although the test as a whole is optional, once it has been decided to perform a test it must be optional, once it has been decided to perform a test it has to be performed as specified so that the correct semantics are preserved performed as specified so that the correct semantics are preserved between publisher and receiver. between publisher and receiver. To make the test, the mail receiver MUST evaluate the check_host() To make the test, the mail receiver MUST evaluate the check_host() function with the arguments set as follows: function with the arguments set as follows: - the IP address of the SMTP client that is emitting the - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6. mail, either IPv4 or IPv6. - the domain portion of the "MAIL FROM" or "HELO" identity. - the domain portion of the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. Note that the argument may not be a well-formed domain name. Note that the argument might not be a well-formed domain For example, if the reverse-path was null, then the EHLO/HELO domain name. For example, if the reverse-path was null, then the EHLO/HELO is used, with its associated problems (see Section 2.1). In these domain is used, with its associated problems (see Section 2.1). In cases, check_host() is defined in Section 4.3 to return a "None" these cases, check_host() is defined in Section 4.3 to return a result. "none" result. Although invalid, malformed, or non-existent domains cause SPF checks Although invalid, malformed, or non-existent domains cause SPF checks to return "None" because no SPF record can be found, it has long been to return "none" because no SPF record can be found, it has long been the policy of many MTAs to reject E-Mail from such domains, the policy of many MTAs to reject email from such domains, especially especially in the case of invalid "MAIL FROM". In order to prevent in the case of invalid "MAIL FROM". Rejecting email will prevent one the circumvention of SPF records, rejecting E-Mail from invalid method of circumventing of SPF records. domains should be considered. Implementations must take care to correctly extract the from Implementations have to take care to correctly extract the the data given with the SMTP MAIL FROM command as many MTAs will from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes (see [RFC2821], Appendix still accept such things as source routes (see [RFC5321], Appendix C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These archaic features have been maliciously used to bypass security These archaic features have been maliciously used to bypass security systems. systems. 2.5. Interpreting the Result 2.5. Interpreting the Result This section describes how software that performs the authorization This section describes how software that performs the authorization should interpret the results of the check_host() function. The interprets the results of the check_host() function. The authorization check SHOULD be performed during the processing of the authorization check SHOULD be performed during the processing of the SMTP transaction that sends the mail. This allows errors to be SMTP transaction that sends the mail. This allows errors to be returned directly to the sending MTA by way of SMTP replies. returned directly to the sending MTA by way of SMTP replies. Performing the authorization after the SMTP transaction has finished Performing the authorization other than using the return-path and may cause problems, such as the following: (1) It may be difficult to client address at the time of the MAIL command during the SMTP accurately extract the required information from potentially transaction can cause problems, such as the following: (1) It might deceptive headers; (2) legitimate E-Mail may fail because the be difficult to accurately extract the required information from sender's policy may have since changed. potentially deceptive headers; (2) legitimate email might fail because the sender's policy had since changed. Generating non-delivery notifications to forged identities that have Generating non-delivery notifications to forged identities that have failed the authorization check is generally abusive and against the failed the authorization check is a source of backscatter and SHOULD explicit wishes of the identity owner. be avoided. [RFC3834] section 2 describes backscatter and the problems it causes. 2.5.1. None 2.5.1. None A result of "None" means that no records were published by the domain A result of "none" means either (a) no syntactically valid DNS domain or that no checkable sender domain could be determined from the given name was extracted from the SMTP session that could be used as the identity. The checking software cannot ascertain whether or not the one to be authorized, or (b) no TXT records were retrieved from the client host is authorized. DNS that appeared to be intended for use by SPF verifiers. 2.5.2. Neutral 2.5.2. Neutral The domain owner has explicitly stated that he cannot or does not The domain owner has explicitly stated that they cannot or do not want to assert whether or not the IP address is authorized. A want to assert whether the IP address is authorized or not. A "Neutral" result MUST be treated exactly like the "None" result; the "neutral" result MUST be treated exactly like the "none" result; the distinction exists only for informational purposes. Treating distinction exists only for informational purposes. Treating "Neutral" more harshly than "None" would discourage domain owners "neutral" more harshly than "none" would discourage domain owners from testing the use of SPF records (see Section 9.1). from testing the use of SPF records (see Section 9.1). 2.5.3. Pass 2.5.3. Pass A "Pass" result means that the client is authorized to inject mail A "pass" result means that the client is authorized to inject mail with the given identity. The domain can now, in the sense of with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the Further policy checks can now proceed with confidence in the legitimate use of the identity. legitimate use of the identity. This is further discussed in Section 9.3.1. 2.5.4. Fail 2.5.4. Fail A "Fail" result is an explicit statement that the client is not A "fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking authorized to use the domain in the given identity. Disposition of software can choose to mark the mail based on this or to reject the SPF fail messages is a matter of local policy. See Section 9.3.2 for mail outright. considerations on developing local policy. If the checking software chooses to reject the mail during the SMTP If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see (DSN) code (see [RFC3464]), in addition to an appropriate reply text. [RFC3463]), in addition to an appropriate reply text. The The check_host() function may return either a default explanation check_host() function will return either a default explanation string string or one from the domain that published the SPF records (see or one from the domain that published the SPF records (see Section 6.2). If the information does not originate with the Section 6.2). If the information does not originate with the checking software, it should be made clear that the text is provided checking software, it is good to make it clear that the text is by the sender's domain. For example: provided by the sender's domain. For example: 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 The domain example.com explains: 550-5.7.1 The domain example.com explains: 550 5.7.1 Please see http://www.example.com/mailpolicy.html 550 5.7.1 Please see http://www.example.com/mailpolicy.html 2.5.5. SoftFail If the checking software chooses not to reject the mail during the SMTP transaction, then it SHOULD add a Received-SPF or Authentication-Results header field (see Section 7) to communicate this result to downstream message processors. While this is true for all SPF results, it is of particular importance for "fail" results since the message is explicitly not authorized by the domain owner. A "SoftFail" result should be treated as somewhere between a "Fail" 2.5.5. Softfail and a "Neutral". The domain believes the host is not authorized but is not willing to make that strong of a statement. Receiving A "softfail" result ought to be treated as somewhere between "fail" software SHOULD NOT reject the message based solely on this result, and "neutral"/"none". The domain owner believes the host is not but MAY subject the message to closer scrutiny than normal. authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal. The domain owner wants to discourage the use of this host and thus The domain owner wants to discourage the use of this host and thus desires limited feedback when a "SoftFail" result occurs. For desires limited feedback when a "softfail" result occurs. For example, the recipient's Mail User Agent (MUA) could highlight the example, the recipient's Mail User Agent (MUA) could highlight the "SoftFail" status, or the receiving MTA could give the sender a "softfail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can message using greylisting, [RFC6647], with a note the first time the issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the message is received, but accept it on a later attempt based on first time the message is received, but accept it the second time. receiver policy. 2.5.6. TempError 2.5.6. Temperror A "TempError" result means that the SPF client encountered a A "temperror" result means the SPF verifier encountered a transient transient error while performing the check. Checking software can (generally DNS) error while performing the check. Checking software choose to accept or temporarily reject the message. If the message can choose to accept or temporarily reject the message. If the is rejected during the SMTP transaction for this reason, the software message is rejected during the SMTP transaction for this reason, the SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN software SHOULD use an SMTP reply code of 451 and, if supported, the code. 4.4.3 enhanced status code. These errors can be caused by problems in either the sender's or receiver's DNS software. 2.5.7. PermError 2.5.7. Permerror A "PermError" result means that the domain's published records could A "permerror" result means the domain's published records could not not be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that requires manual intervention to be resolved, as opposed to the definitely requires manual intervention to be resolved. If the TempError result. Be aware that if the domain owner uses macros message is rejected during the SMTP transaction for this reason, the (Section 8), it is possible that this result is due to the checked software SHOULD use an SMTP reply code of 550 and, if supported, the identities having an unexpected format. 5.5.2 enhanced status code. Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format. It is also possible that this result is generated by certain SPF clients due to the input arguments having an unexpected format; see Section 4.8. 3. SPF Records 3. SPF Records An SPF record is a DNS Resource Record (RR) that declares which hosts An SPF record is a DNS record that declares which hosts are, and are are, and are not, authorized to use a domain name for the "HELO" and not, authorized to use a domain name for the "HELO" and "MAIL FROM" "MAIL FROM" identities. Loosely, the record partitions all hosts identities. Loosely, the record partitions all hosts into permitted into permitted and not-permitted sets (though some hosts might fall and not-permitted sets (though some hosts might fall into neither into neither category). category). The SPF record is a single string of text. An example record is the The SPF record is a single string of text. The record format is following: described below in Section 4. An example record is the following: v=spf1 +mx a:colo.example.com/28 -all v=spf1 +mx a:colo.example.com/28 -all This record has a version of "spf1" and three directives: "+mx", This record has a version of "spf1" and three directives: "+mx", "a:colo.example.com/28" (the + is implied), and "-all". "a:colo.example.com/28" (the + is implied), and "-all". 3.1. Publishing Each SPF record is placed in the DNS tree at the host name it Domain owners wishing to be SPF compliant must publish SPF records for the hosts that are used in the "MAIL FROM" and "HELO" identities. The SPF records are placed in the DNS tree at the host name it pertains to, not a subdomain under it, such as is done with SRV pertains to, not a subdomain under it, such as is done with SRV records. This is the same whether the TXT or SPF RR type (see records [RFC2782]. Section 3.1.1) is used. The example above in Section 3 might be published via these lines in The example in this section might be published via these lines in a a domain zone file: domain zone file: example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" smtp-out.example.com. TXT "v=spf1 a -all" smtp-out.example.com. TXT "v=spf1 a -all" When publishing via TXT records, beware of other TXT records Since TXT records have multiple uses, beware of other TXT records published there for other purposes. They may cause problems with published there for other purposes. They might cause problems with size limits (see Section 3.1.4). size limits (see Section 3.4) and care has to be taken to ensure only SPF records are used for SPF processing. 3.1.1. DNS Resource Record Types This document defines a new DNS RR of type SPF, code 99. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII]. It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle the new RR type. The two-record-type scheme provides a forward path to the better solution of using an RR type reserved for this purpose. An SPF-compliant domain name SHOULD have SPF records of both RR ADMDs publishing SPF records SHOULD try to keep the number of types. A compliant domain name MUST have a record of at least one "include" mechanisms and chained "redirect" modifiers to a minimum. type. If a domain has records of both types, they MUST have ADMDs SHOULD also try to minimize the amount of other DNS information identical content. For example, instead of publishing just one needed to evaluate a record. Section 4.6.4 and Section 9.1.1 provide record as in Section 3.1 above, it is better to publish: some suggestions on how to achieve this. example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" 3.1. DNS Resource Records example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all" Example RRs in this document are shown with the TXT record type; SPF records MUST be published as a DNS TXT (type 16) Resource Record however, they could be published with the SPF type or with both (RR) [RFC1035] only. The character content of the record is encoded types. as [US-ASCII]. Use of alternate DNS RR types was supported in SPF's experimental phase, but has been discontinued. See Appendix A of [RFC6686] for further information. 3.1.2. Multiple DNS Records 3.2. Multiple DNS Records A domain name MUST NOT have multiple records that would cause an A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record. See Section 4.5 authorization check to select more than one record. See Section 4.5 for the selection rules. for the selection rules. 3.1.3. Multiple Strings in a Single DNS record 3.3. Multiple Strings in a Single DNS record As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one record can be composed of more than one string. If a published string. If a published record contains multiple strings, then the record contains multiple character-strings, then the record MUST be record MUST be treated as if those strings are concatenated together treated as if those strings are concatenated together without adding without adding spaces. For example: spaces. For example: IN TXT "v=spf1 .... first" "second string..." IN TXT "v=spf1 .... first" "second string..." MUST be treated as equivalent to MUST be treated as equivalent to IN TXT "v=spf1 .... firstsecond string..." IN TXT "v=spf1 .... firstsecond string..." SPF or TXT records containing multiple strings are useful in TXT records containing multiple strings are useful in constructing constructing records that would exceed the 255-byte maximum length of records that would exceed the 255-byte maximum length of a character- a string within a single TXT or SPF RR record. string within a single TXT record. 3.1.4. Record Size 3.4. Record Size The published SPF record for a given domain name SHOULD remain small The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. enough that the results of a query for it will fit within 512 octets. This will keep even older DNS implementations from falling over to This UDP limit is defined in [RFC1035] section 2.3.4. This will keep TCP. Since the answer size is dependent on many things outside the even older DNS implementations from falling over to TCP. Since the scope of this document, it is only possible to give this guideline: answer size is dependent on many things outside the scope of this If the combined length of the DNS name and the text of all the document, it is only possible to give this guideline: If the combined records of a given type (TXT or SPF) is under 450 characters, then length of the DNS name and the text of all the records of a given DNS answers should fit in UDP packets. Note that when computing the type is under 450 characters, then DNS answers ought to fit in UDP sizes for queries of the TXT format, one must take into account any packets. Note that when computing the sizes for queries of the TXT other TXT records published at the domain name. Records that are too format, one has to take into account any other TXT records published long to fit in a single UDP packet MAY be silently ignored by SPF at the domain name. Records that are too long to fit in a single UDP clients. packet could be silently ignored by SPF verifiers due to firewall and other issues that cause DNS over TCP to be less reliable than DNS 3.1.5. Wildcard Records over UDP. Use of wildcard records for publishing is not recommended. Care must 3.5. Wildcard Records be taken if wildcard records are used. If a domain publishes wildcard MX records, it may want to publish wildcard declarations, subject to the same requirements and problems. In particular, the declaration must be repeated for any host that has any RR records at all, and for subdomains thereof. For example, the example given in [RFC1034], Section 4.3.3, could be extended with the following: X.COM. MX 10 A.X.COM Use of wildcard records for publishing is discouraged and care has to X.COM. TXT "v=spf1 a:A.X.COM -all" be taken if they are used. If a zone includes wildcard MX records, it might want to publish wildcard declarations, subject to the same requirements and problems. In particular, the declaration MUST be repeated for any host that has any RR records at all, and for subdomains thereof. Consider the example in [RFC1034], Section 4.3.3. Based on that, we can do the following: *.X.COM. MX 10 A.X.COM EXAMPLE.COM. MX 10 A.EXAMPLE.COM *.X.COM. TXT "v=spf1 a:A.X.COM -all" EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" A.X.COM. A 1.2.3.4 *.EXAMPLE.COM. MX 10 A.EXAMPLE.COM A.X.COM. MX 10 A.X.COM *.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" A.X.COM. TXT "v=spf1 a:A.X.COM -all" *.A.X.COM. MX 10 A.X.COM A.EXAMPLE.COM. A 203.0.113.1 *.A.X.COM. TXT "v=spf1 a:A.X.COM -all" A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" Notice that SPF records must be repeated twice for every name within *.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM the domain: once for the name, and once with a wildcard to cover the *.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all" tree under the name. Use of wildcards is discouraged in general as they cause every name SPF records have to be listed twice for every name within the zone: under the domain to exist and queries against arbitrary names will once for the name, and once with a wildcard to cover the tree under never return RCODE 3 (Name Error). the name, in order to cover all domains in use in outgoing mail. 4. The check_host() Function 4. The check_host() Function This description is not an API (Application Program Interface) definition, but rather a function description used to illustrate the algorithm. A compliant SPF implementation MUST do something semantically equivalent to this description. The check_host() function fetches SPF records, parses them, and The check_host() function fetches SPF records, parses them, and interprets them to determine whether a particular host is or is not evaluates them to determine whether a particular host is or is not permitted to send mail with a given identity. Mail receivers that permitted to send mail with a given identity. Mail receivers that perform this check MUST correctly evaluate the check_host() function perform this check MUST correctly evaluate the check_host() function as described here. as described here. Implementations MAY use a different algorithm than the canonical Implementations MAY use a different algorithm than the canonical algorithm defined here, so long as the results are the same in all algorithm defined here, so long as the results are the same in all cases. cases. 4.1. Arguments 4.1. Arguments skipping to change at page 13, line 12 skipping to change at page 17, line 40 information; initially, the domain portion of the "MAIL information; initially, the domain portion of the "MAIL FROM" or "HELO" identity. FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. - the "MAIL FROM" or "HELO" identity. The domain portion of will usually be the same as the The domain portion of will usually be the same as the argument when check_host() is initially evaluated. However, argument when check_host() is initially evaluated. However, this will generally not be true for recursive evaluations (see this will generally not be true for recursive evaluations (see Section 5.2 below). Section 5.2 below). Actual implementations of the check_host() function may need additional arguments. 4.2. Results 4.2. Results The function check_host() can return one of several results described The function check_host() can return one of several results described in Section 2.5. Based on the result, the action to be taken is in Section 2.5. Based on the result, the action to be taken is determined by the local policies of the receiver. determined by the local policies of the receiver. 4.3. Initial Processing 4.3. Initial Processing If the is malformed (label longer than 63 characters, zero- If the is malformed (e.g. label longer than 63 characters, length label not at the end, etc.) or is not a fully qualified domain zero-length label not at the end, etc.) or is not a fully qualified name, or if the DNS lookup returns "domain does not exist" (RCODE 3), domain name, or if the DNS lookup returns "domain does not exist" check_host() immediately returns the result "None". (RCODE 3), check_host() immediately returns the result "none". Properly formed domains are fully qualified email domains as described in [RFC5321] Section 2.3.5. Internationalized domain names MUST be encoded as A-labels, as described in Section 2.3 of [RFC5890].on 2.3 of [RFC5890]. If the has no localpart, substitute the string "postmaster" If the has no local-part, substitute the string "postmaster" for the localpart. for the local-part. 4.4. Record Lookup 4.4. Record Lookup In accordance with how the records are published (see Section 3.1 In accordance with how the records are published (see Section 3 above), a DNS query needs to be made for the name, querying above), a DNS query needs to be made for the name, querying for either RR type TXT, SPF, or both. If both SPF and TXT RRs are for type TXT only. looked up, the queries MAY be done in parallel. If all DNS lookups that are made return a server failure (RCODE 2), If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then or other error (RCODE other than 0 or 3), or time out, then check_host() exits immediately with the result "TempError". check_host() terminates immediately with the result "temperror". Alternatively, for a server failure (RCODE 2) result, check_host() MAY track failures and treat multiple failures within 24 hours for the same domain as "permerror". This alternative is intended to shorten the queue time of messages that cannot be accepted, by returning a permanent negative completion reply code to the client, instead of a transient one. [RFC2308] suggests on an algorithm for doing such tracking and handling of server failure codes. 4.5. Selecting Records 4.5. Selecting Records Records begin with a version section: Records begin with a version section: record = version terms *SP record = version terms *SP version = "v=spf1" version = "v=spf1" Starting with the set of records that were returned by the lookup, Starting with the set of records that were returned by the lookup, record selection proceeds in two steps: discard records that do not begin with a version section of exactly "v=spf1". Note that the version section is terminated either by an 1. Records that do not begin with a version section of exactly SP character or the end of the record. A record with a version "v=spf1" are discarded. Note that the version section is section of "v=spf10" does not match and MUST be discarded. terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and must be discarded. 2. If any records of type SPF are in the set, then all records of type TXT are discarded. After the above steps, there should be exactly one record remaining and evaluation can proceed. If there are two or more records remaining, then check_host() exits immediately with the result of "PermError". If no matching records are returned, an SPF client MUST assume that If the resultant record set includes no records, check_host() the domain makes no SPF declarations. SPF processing MUST stop and produces the "none" result. If the resultant record set includes return "None". more than one record, check_host() produces the "permerror" result. 4.6. Record Evaluation 4.6. Record Evaluation After one SPF record has been selected, the check_host() function The check_host() function parses and interprets the SPF record to parses and interprets it to find a result for the current test. If find a result for the current test. If there are any syntax errors, there are any syntax errors, check_host() returns immediately with check_host() returns immediately with the result "permerror". the result "PermError". Implementations MAY choose to parse the entire record first and Implementations MAY choose to parse the entire record first and return "PermError" if the record is not syntactically well formed. return "permerror" if the record is not syntactically well formed. However, in all cases, any syntax errors anywhere in the record MUST However, in all cases, any syntax errors anywhere in the record MUST be detected. be detected. 4.6.1. Term Evaluation 4.6.1. Term Evaluation There are two types of terms: mechanisms and modifiers. A record There are two types of terms: mechanisms and modifiers. A record contains an ordered list of these as specified in the following contains an ordered list of these as specified in the following Augmented Backus-Naur Form (ABNF). Augmented Backus-Naur Form (ABNF). terms = *( 1*SP ( directive / modifier ) ) terms = *( 1*SP ( directive / modifier ) ) directive = [ qualifier ] mechanism directive = [ qualifier ] mechanism qualifier = "+" / "-" / "?" / "~" qualifier = "+" / "-" / "?" / "~" mechanism = ( all / include mechanism = ( all / include / A / MX / PTR / IP4 / IP6 / exists ) / A / MX / PTR / IP4 / IP6 / exists ) modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string ; where name is not any known modifier name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) Most mechanisms allow a ":" or "/" character after the name. Most mechanisms allow a ":" or "/" character after the name. Modifiers always contain an equals ('=') character immediately after Modifiers always contain an equals ('=') character immediately after the name, and before any ":" or "/" characters that may be part of the name, and before any ":" or "/" characters that might be part of the macro-string. the macro-string. Terms that do not contain any of "=", ":", or "/" are mechanisms, as Terms that do not contain any of "=", ":", or "/" are mechanisms, as defined in Section 5. defined in Section 5. As per the definition of the ABNF notation in [RFC4234], mechanism As per the definition of the ABNF notation in [RFC5234], mechanism and modifier names are case-insensitive. and modifier names are case-insensitive. 4.6.2. Mechanisms 4.6.2. Mechanisms Each mechanism is considered in turn from left to right. If there Each mechanism is considered in turn from left to right. If there are no more mechanisms, the result is specified in Section 4.7. are no more mechanisms, the result is specified in Section 4.7. When a mechanism is evaluated, one of three things can happen: it can When a mechanism is evaluated, one of three things can happen: it can match, not match, or throw an exception. match, not match, or return an exception. If it matches, processing ends and the qualifier value is returned as If it matches, processing ends and the qualifier value is returned as the result of that record. If it does not match, processing the result of that record. If it does not match, processing continues with the next mechanism. If it throws an exception, continues with the next mechanism. If it returns an exception, mechanism processing ends and the exception value is returned. mechanism processing ends and the exception value is returned. The possible qualifiers, and the results they return are as follows: The possible qualifiers, and the results they cause check_host() to return are as follows: "+" Pass "+" pass "-" Fail "-" fail "~" SoftFail "~" softfail "?" Neutral "?" neutral The qualifier is optional and defaults to "+". The qualifier is optional and defaults to "+". When a mechanism matches and the qualifier is "-", then a "Fail" When a mechanism matches and the qualifier is "-", then a "fail" result is returned and the explanation string is computed as result is returned and the explanation string is computed as described in Section 6.2. described in Section 6.2. The specific mechanisms are described in Section 5. The specific mechanisms are described in Section 5. 4.6.3. Modifiers 4.6.3. Modifiers Modifiers are not mechanisms: they do not return match or not-match. Modifiers are not mechanisms. They do not return match or not-match. Instead they provide additional information. Although modifiers do Instead, they provide additional information. Although modifiers do not directly affect the evaluation of the record, the "redirect" not directly affect the evaluation of the record, the "redirect" modifier has an effect after all the mechanisms have been evaluated. modifier has an effect after all the mechanisms have been evaluated. 4.6.4. DNS Lookup Limits SPF implementations MUST limit the number of mechanisms and modifiers ("terms") that cause any DNS query to at most 10 during SPF evaluation. Specifically, the "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier count against this limit. The "all", "ip4", and "ip6" mechanisms do not count against this limit. If this number is exceeded during a check, a permerror MUST be returned. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record evaluation has been completed. When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. If more than 10 "mx" or "ptr" records are returned for this further lookup, a permerror MUST be returned. This limit is per mechanism or macro in the record and in addition to the lookup limits above. MTAs or other processors SHOULD impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "temperror". 4.7. Default Result 4.7. Default Result If none of the mechanisms match and there is no "redirect" modifier, If none of the mechanisms match and there is no "redirect" modifier, then the check_host() returns a result of "Neutral", just as if then the check_host() returns a result of "neutral", just as if "?all" were specified as the last directive. If there is a "?all" were specified as the last directive. If there is a "redirect" modifier, check_host() proceeds as defined in Section 6.1. "redirect" modifier, check_host() proceeds as defined in Section 6.1. Note that records SHOULD always use either a "redirect" modifier or Note that records SHOULD always use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing. an "all" mechanism to explicitly terminate processing. Although the latter has default (specifically "?all"), it aids debugging efforts if it is explicitly included. For example: For example: v=spf1 +mx -all v=spf1 +mx -all or or v=spf1 +mx redirect=_spf.example.com v=spf1 +mx redirect=_spf.example.com 4.8. Domain Specification 4.8. Domain Specification Several of these mechanisms and modifiers have a Several of these mechanisms and modifiers have a domain-spec section. section. The string is macro expanded (see Section 8). The domain-spec string is subject to macro expansion (see Section 8). The resulting string is the common presentation form of a fully- The resulting string is the common presentation form of a fully- qualified DNS name: a series of labels separated by periods. This qualified DNS name: a series of labels separated by periods. This domain is called the in the rest of this document. domain is called the in the rest of this document. Note: The result of the macro expansion is not subject to any further Note: The result of the macro expansion is not subject to any further escaping. Hence, this facility cannot produce all characters that escaping. Hence, this facility cannot produce all characters that are legal in a DNS label (e.g., the control characters). However, are legal in a DNS label (e.g., the control characters). However, this facility is powerful enough to express legal host names and this facility is powerful enough to express legal host names and common utility labels (such as "_spf") that are used in DNS. common utility labels (such as "_spf") that are used in DNS. For several mechanisms, the is optional. If it is not For several mechanisms, the is optional. If it is not provided, the is used as the . provided, the is used as the . Domain and domain-spec are syntactically identical after macro expansion. Domain is an input value for check_host() while domain-spec is computed by check_host(). Note: Historically, this document has made no provisions for how to handle domain-specs, or macro-expansions thereof, that are syntactically invalid per [RFC1035], such as names with empty labels (e.g., "foo..example.com") or overlong labels (more than 63 characters). Some implementations choose to treat as a no-match mechanisms, and ignore modifiers, with such names, whereas others return a "permerror" exception. The outcome for an unexpected domain-spec without macros might even differ from that for an unexpected target-name after macro expansion. 5. Mechanism Definitions 5. Mechanism Definitions This section defines two types of mechanisms. This section defines two types of mechanisms. Basic mechanisms contribute to the language framework. They do not Basic mechanisms contribute to the language framework. They do not specify a particular type of authorization scheme. specify a particular type of authorization scheme. all all include include Designated sender mechanisms are used to designate a set of Designated sender mechanisms are used to designate a set of addresses as being permitted or not permitted to use the for addresses as being permitted or not permitted to use the for sending mail. sending mail. a a mx mx ptr ptr (deprecated) ip4 ip4 ip6 ip6 exists exists The following conventions apply to all mechanisms that perform a The following conventions apply to all mechanisms that perform a comparison between and an IP address at any point: comparison between and an IP address at any point: If no CIDR-length is given in the directive, then and the IP If no CIDR prefix length is given in the directive, then and the address are compared for equality. (Here, CIDR is Classless Inter- IP address are compared for equality. (Here, CIDR is Classless Domain Routing.) Inter-Domain Routing, described in [RFC4632].) If a CIDR-length is specified, then only the specified number of If a CIDR prefix length is specified, then only the specified number high-order bits of and the IP address are compared for equality. of high-order bits of and the IP address are compared for equality. When any mechanism fetches host addresses to compare with , when When any mechanism fetches host addresses to compare with , when is an IPv4 address, A records are fetched, when is an IPv6 is an IPv4 address, A records are fetched; when is an IPv6 address, AAAA records are fetched. Even if the SMTP connection is address, AAAA records are fetched. Even if the SMTP connection uses via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5) 2.5.5) MUST still be considered an IPv4 address. MUST still be considered an IPv4 address and MUST be evaluated using IPv4 mechanisms (i.e. "ip4" and "a"). Several mechanisms rely on information fetched from DNS. For these Several mechanisms rely on information fetched from the DNS. For DNS queries, except where noted, if the DNS server returns an error these DNS queries, except where noted, if the DNS server returns an (RCODE other than 0 or 3) or the query times out, the mechanism error (RCODE other than 0 or 3) or the query times out, the mechanism throws the exception "TempError". If the server returns "domain does stops and the topmost check_host() returns "temperror". If the not exist" (RCODE 3), then evaluation of the mechanism continues as server returns "domain does not exist" (RCODE 3), then evaluation of if the server returned no error (RCODE 0) and zero answer records. the mechanism continues as if the server returned no error (RCODE 0) and zero answer records. 5.1. "all" 5.1. "all" all = "all" all = "all" The "all" mechanism is a test that always matches. It is used as the The "all" mechanism is a test that always matches. It is used as the rightmost mechanism in a record to provide an explicit default. rightmost mechanism in a record to provide an explicit default. For example: For example: v=spf1 a mx -all v=spf1 a mx -all Mechanisms after "all" will never be tested. Any "redirect" modifier Mechanisms after "all" will never be tested. Mechanisms listed after (Section 6.1) has no effect when there is an "all" mechanism. "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be ignored when there is an "all" mechanism in the record. 5.2. "include" 5.2. "include" include = "include" ":" domain-spec include = "include" ":" domain-spec The "include" mechanism triggers a recursive evaluation of The "include" mechanism triggers a recursive evaluation of check_host(). The domain-spec is expanded as per Section 8. Then check_host(). check_host() is evaluated with the resulting string as the . The and arguments remain the same as in the current 1. The domain-spec is expanded as per Section 8. evaluation of check_host(). 2. Check_host() is evaluated with the resulting string as the . The and arguments remain the same as in the current evaluation of check_host(). 3. The recursive evaluation returns either match, not match, or an error. If it matches, then the appropriate result for the include: mechanism is used (e.g. include or +include gives a "pass" result and -include gives "fail). 4. If there is no match, the parent check_host() resumes processing as per the table below, with the previous value of restored. In hindsight, the name "include" was poorly chosen. Only the In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the acting as if the referenced SPF record was literally included in the first. For example, evaluating a "-all" directive in the referenced first. For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not record does not terminate the overall processing and does not necessarily result in an overall "Fail". (Better names for this necessarily result in an overall "fail". (Better names for this mechanism would have been "if-pass", "on-pass", etc.) mechanism would have been "if-match", "on-match", etc.) The "include" mechanism makes it possible for one domain to designate The "include" mechanism makes it possible for one domain to designate multiple administratively-independent domains. For example, a vanity multiple administratively-independent domains. For example, a vanity domain "example.net" might send mail using the servers of domain "example.net" might send mail using the servers of administratively-independent domains example.com and example.org. administratively-independent domains example.com and example.org. Example.net could say Example.net could say IN TXT "v=spf1 include:example.com include:example.org -all" IN TXT "v=spf1 include:example.com include:example.org -all" This would direct check_host() to, in effect, check the records of This would direct check_host() to, in effect, check the records of example.com and example.org for a "Pass" result. Only if the host example.com and example.org for a "pass" result. Only if the host were not permitted for either of those domains would the result be were not permitted for either of those domains would the result be "Fail". "fail". Whether this mechanism matches, does not match, or throws an Whether this mechanism matches, does not match, or returns an exception depends on the result of the recursive evaluation of exception depends on the result of the recursive evaluation of check_host(): check_host(): +---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+ | A recursive check_host() result | Causes the "include" mechanism | | A recursive check_host() result | Causes the "include" mechanism | | of: | to: | | of: | to: | +---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+ | Pass | match | | pass | match | | | | | | | | Fail | not match | | fail | not match | | | | | | | | SoftFail | not match | | softfail | not match | | | | | | | | Neutral | not match | | neutral | not match | | | | | | | | TempError | throw TempError | | temperror | return temperror | | | | | | | | PermError | throw PermError | | permerror | return permerror | | | | | | | | None | throw PermError | | none | return permerror | +---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+ The "include" mechanism is intended for crossing administrative The "include" mechanism is intended for crossing administrative boundaries. Although it is possible to use includes to consolidate boundaries. For example, if example.com and example.org were managed multiple domains that share the same set of designated hosts, domains by the same entity, and if the permitted set of hosts for both are encouraged to use redirects where possible, and to minimize the domains was number of includes within a single administrative domain. For example, if example.com and example.org were managed by the same entity, and if the permitted set of hosts for both domains was "mx:example.com", it would be possible for example.org to specify "mx:example.com", it would be possible for example.org to specify "include:example.com", but it would be preferable to specify "include:example.com", but it would be preferable to specify "redirect=example.com" or even "mx:example.com". "redirect=example.com" or even "mx:example.com". With the "include" mechanism an administratively external set of hosts can be authorized, but determination of sender policy is still a function of the original domain's SPF record (as determined by the "all" mechanism in that record). The redirect modifier is more suitable for consolidating both authorizations and policy into a common set to be shared within an ADMD. Redirect is much more like a common code element to be shared among records in a single ADMD. It is possible to control both authorized hosts and policy for an arbitrary number of domains from a single record. 5.3. "a" 5.3. "a" This mechanism matches if is one of the 's IP This mechanism matches if is one of the 's IP addresses. addresses. A = "a" [ ":" domain-spec ] [ dual-cidr-length ] a = "a" [ ":" domain-spec ] [ dual-cidr-length ] An address lookup is done on the . The is compared An address lookup is done on the . The is compared to the returned address(es). If any address matches, the mechanism to the returned address(es). If any address matches, the mechanism matches. matches. 5.4. "mx" 5.4. "mx" This mechanism matches if is one of the MX hosts for a domain This mechanism matches if is one of the MX hosts for a domain name. name. MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ] check_host() first performs an MX lookup on the . Then check_host() first performs an MX lookup on the . Then it performs an address lookup on each MX name returned. The is it performs an address lookup on each MX name returned. The is compared to each returned IP address. To prevent Denial of Service compared to each returned IP address. To prevent Denial of Service (DoS) attacks, more than 10 MX names MUST NOT be looked up during the (DoS) attacks, more than 10 MX names MUST NOT be looked up during the evaluation of an "mx" mechanism (see Section 10). If any address evaluation of an "mx" mechanism. If there are more than 10 MX names matches, the mechanism matches. then permerror is returned and the evaluation terminated (see Section 4.6.4). If any address matches, the mechanism matches. Note regarding implicit MXs: If the has no MX records, Note regarding implicit MXs: If the has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the directly. This NOT default to an A or AAAA lookup on the directly. behavior breaks with the legacy "implicit MX" rule. See [RFC2821], This behavior diverges from the legacy "implicit MX" rule, (See Section 5. If such behavior is desired, the publisher should specify [RFC5321], Section 5. If such behavior is desired, the publisher an "a" directive. will have to specify an "a" directive). 5.5. "ptr" 5.5. "ptr" (deprecated) This mechanism tests whether the DNS reverse-mapping for exists This mechanism tests whether the DNS reverse-mapping for exists and correctly points to a domain name within a particular domain. and correctly points to a domain name within a particular domain. This mechanism is deprecated and SHOULD NOT be used. PTR = "ptr" [ ":" domain-spec ] ptr = "ptr" [ ":" domain-spec ] First, the 's name is looked up using this procedure: perform a The 's name is looked up using this procedure: DNS reverse-mapping for , looking up the corresponding PTR record in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." if it is an IPv6 address. For each record returned, validate the domain name by looking up its IP address. To prevent DoS attacks, more than 10 PTR names MUST NOT be looked up during the evaluation of a "ptr" mechanism (see Section 10). If is among the returned IP addresses, then that domain name is validated. In pseudocode: sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 1. Perform a DNS reverse-mapping for : Look up the corresponding sending-domain_names are found, use at most 10. for each name in PTR record in "in-addr.arpa." if the address is an IPv4 one and (sending-domain_names) { in "ip6.arpa." if it is an IPv6 address. IP_addresses := a_lookup(name); if the sending-domain_IP is one of the IP_addresses { validated-sending-domain_names += name; } } Check all validated domain names to see if they end in the 2. For each record returned, validate the domain name by looking up domain. If any do, this mechanism matches. If no its IP addresses. To prevent DoS attacks, more than 10 PTR names validated domain name can be found, or if none of the validated MUST NOT be looked up during the evaluation of a "ptr" mechanism domain names end in the , this mechanism fails to match. (see Section 4.6.4). If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR 3. If is among the returned IP addresses, then that domain name lookup, then that domain name is skipped and the search continues. is validated. Check all validated domain names to see if they either match the domain or are a subdomain of the domain. If any do, this mechanism matches. If no validated domain name can be found, or if none of the validated domain names match or are a subdomain of the , this mechanism fails to match. If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues. Pseudocode: Pseudocode: sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 sending-domain_names are found, use at most 10. for each name in (sending-domain_names) { IP_addresses := a_lookup(name); if the sending-domain_IP is one of the IP_addresses { validated-sending-domain_names += name; } } for each name in (validated-sending-domain_names) { for each name in (validated-sending-domain_names) { if name ends in , return match. if name ends in , return match. if name is , return match. if name is , return match. } } return no-match. return no-match. This mechanism matches if the is either an ancestor of This mechanism matches if the is either a subdomain of a validated domain name or if the and a validated a validated domain name or if the and a validated domain name are the same. For example: "mail.example.com" is within domain name are the same. For example: "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not. the domain "example.com", but "mail.bad-example.com" is not. Note: Use of this mechanism is discouraged because it is slow, it is Note: This mechanism has been deprecated because it is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the arpa name servers. If used, proper PTR places a large burden on the .arpa name servers. If used, proper PTR records must be in place for the domain's hosts and the "ptr" records MUST be in place for the domain's hosts and the "ptr" mechanism should be one of the last mechanisms checked. mechanism SHOULD be one of the last mechanisms checked. After many years of SPF deployment experience it has been concluded it is unnecessary and more reliable alternatives used instead. It is, however, still in use and part of the SPF protocol, so compliant check_host() implementations MUST support it. 5.6. "ip4" and "ip6" 5.6. "ip4" and "ip6" These mechanisms test whether is contained within a given IP These mechanisms test whether is contained within a given IP network. network. IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255 ; as per conventional dotted quad notation. e.g., 192.0.2.0 ; as per conventional dotted quad notation. e.g., 192.0.2.0 ip6-network = ip6-network = ; e.g., 2001:DB8::CD30 ; e.g., 2001:DB8::CD30 The is compared to the given network. If CIDR-length high-order The is compared to the given network. If CIDR prefix length bits match, the mechanism matches. high-order bits match, the mechanism matches. If ip4-cidr-length is omitted, it is taken to be "/32". If If ip4-cidr-length is omitted, it is taken to be "/32". If ip6-cidr-length is omitted, it is taken to be "/128". It is not ip6-cidr-length is omitted, it is taken to be "/128". It is not permitted to omit parts of the IP address instead of using CIDR permitted to omit parts of the IP address instead of using CIDR notations. That is, use 192.0.2.0/24 instead of 192.0.2. notations. That is, use 192.0.2.0/24 instead of 192.0.2. 5.7. "exists" 5.7. "exists" This mechanism is used to construct an arbitrary domain name that is This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query. It allows for complicated schemes used for a DNS A record query. It allows for complicated schemes skipping to change at page 22, line 34 skipping to change at page 28, line 15 Domains can use this mechanism to specify arbitrarily complex Domains can use this mechanism to specify arbitrarily complex queries. For example, suppose example.com publishes the record: queries. For example, suppose example.com publishes the record: v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all The might expand to The might expand to "1.2.0.192.someuser._spf.example.com". This makes fine-grained "1.2.0.192.someuser._spf.example.com". This makes fine-grained decisions possible at the level of the user and client IP address. decisions possible at the level of the user and client IP address. This mechanism enables queries that mimic the style of tests that This mechanism enables queries that mimic the style of tests that existing anti-spam DNS blacklists (DNSBL) use. existing DNS white/black lists (DNSxLs) use, as described in [RFC5782]. The query will either return NXDOMAIN (no match), any valid answer (match), or an error. 6. Modifier Definitions 6. Modifier Definitions Modifiers are name/value pairs that provide additional information. Modifiers are name/value pairs that provide additional information. Modifiers always have an "=" separating the name and the value. Modifiers always have an "=" separating the name and the value. The modifiers defined in this document ("redirect" and "exp") MAY The modifiers defined in this document ("redirect" and "exp") MAY appear anywhere in the record, but SHOULD appear at the end, after appear anywhere in the record, but SHOULD appear at the end, after all mechanisms. Ordering of these two modifiers does not matter. all mechanisms. Ordering of these two modifiers does not matter. These two modifiers MUST NOT appear in a record more than once each. These two modifiers MUST NOT appear in a record more than once each. If they do, then check_host() exits with a result of "PermError". If they do, then check_host() exits with a result of "permerror". Unrecognized modifiers MUST be ignored no matter where in a record, Unrecognized modifiers MUST be ignored no matter where in a record, or how often. This allows implementations of this document to or how often. This allows implementations of this document to gracefully handle records with modifiers that are defined in other gracefully handle records with modifiers that are defined in other specifications. specifications. 6.1. redirect: Redirected Query 6.1. redirect: Redirected Query If all mechanisms fail to match, and a "redirect" modifier is The redirect modifier is intended for consolidating both present, then processing proceeds as follows: authorizations and policy into a common set to be shared within a single ADMD. Redirect is like a common code element to be shared among records in a single ADMD. It is possible to control both authorized hosts and policy for an arbitrary number of domains from a single record. redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec If all mechanisms fail to match, and a "redirect" modifier is present, then processing proceeds as follows: The domain-spec portion of the redirect section is expanded as per The domain-spec portion of the redirect section is expanded as per the macro rules in Section 8. Then check_host() is evaluated with the macro rules in Section 8. Then check_host() is evaluated with the resulting string as the . The and the resulting string as the . The and arguments remain the same as current evaluation of check_host(). arguments remain the same as in the current evaluation of check_host(). The result of this new evaluation of check_host() is then considered The result of this new evaluation of check_host() is then considered the result of the current evaluation with the exception that if no the result of the current evaluation with the exception that if no SPF record is found, or if the target-name is malformed, the result SPF record is found, or if the target-name is malformed, the result is a "PermError" rather than "None". is a "permerror" rather than "none". Note that the newly-queried domain may itself specify redirect Note that the newly-queried domain can itself specify redirect processing. processing. This facility is intended for use by organizations that wish to apply This facility is intended for use by organizations that wish to apply the same record to multiple domains. For example: the same record to multiple domains. For example: la.example.com. TXT "v=spf1 redirect=_spf.example.com" la.example.com. TXT "v=spf1 redirect=_spf.example.com" ny.example.com. TXT "v=spf1 redirect=_spf.example.com" ny.example.com. TXT "v=spf1 redirect=_spf.example.com" sf.example.com. TXT "v=spf1 redirect=_spf.example.com" sf.example.com. TXT "v=spf1 redirect=_spf.example.com" _spf.example.com. TXT "v=spf1 mx:example.com -all" _spf.example.com. TXT "v=spf1 mx:example.com -all" In this example, mail from any of the three domains is described by In this example, mail from any of the three domains is described by the same record. This can be an administrative advantage. the same record. This can be an administrative advantage. Note: In general, the domain "A" cannot reliably use a redirect to Note: In general, the domain "A" cannot reliably use a redirect to another domain "B" not under the same administrative control. Since another domain "B" not under the same administrative control. Since the stays the same, there is no guarantee that the record at the stays the same, there is no guarantee that the record at domain "B" will correctly work for mailboxes in domain "A", domain "B" will correctly work for mailboxes in domain "A", especially if domain "B" uses mechanisms involving localparts. An especially if domain "B" uses mechanisms involving local-parts. An "include" directive may be more appropriate. "include" directive is generally be more appropriate. For clarity, it is RECOMMENDED that any "redirect" modifier appear as For clarity, it is RECOMMENDED that any "redirect" modifier appear as the very last term in a record. the very last term in a record. 6.2. exp: Explanation 6.2. exp: Explanation explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec If check_host() results in a "Fail" due to a mechanism match (such as If check_host() results in a "fail" due to a mechanism match (such as "-all"), and the "exp" modifier is present, then the explanation "-all"), and the "exp" modifier is present, then the explanation string returned is computed as described below. If no "exp" modifier string returned is computed as described below. If no "exp" modifier is present, then either a default explanation string or an empty is present, then either a default explanation string or an empty explanation string may be returned. explanation string MUST be returned. The is macro expanded (see Section 8) and becomes the The domain-spec is macro expanded (see Section 8) and becomes the . The DNS TXT record for the is fetched. . The DNS TXT record for the is fetched. If is empty, or there are any DNS processing errors If there are any DNS processing errors (any RCODE other than 0), or (any RCODE other than 0), or if no records are returned, or if more if no records are returned, or if more than one record is returned, than one record is returned, or if there are syntax errors in the or if there are syntax errors in the explanation string, then proceed explanation string, then proceed as if no exp modifier was given. as if no exp modifier was given. The fetched TXT record's strings are concatenated with no spaces, and The fetched TXT record's strings are concatenated with no spaces, and then treated as an , which is macro-expanded. This then treated as an explain-string, which is macro-expanded. This final result is the explanation string. Implementations MAY limit final result is the explanation string. Implementations MAY limit the length of the resulting explanation string to allow for other the length of the resulting explanation string to allow for other protocol constraints and/or reasonable processing limits. Since the protocol constraints and/or reasonable processing limits. Since the explanation string is intended for an SMTP response and [RFC2821] explanation string is intended for an SMTP response and [RFC5321] Section 2.4 says that responses are in [US-ASCII], the explanation Section 2.4 says that responses are in [US-ASCII], the explanation string is also limited to US-ASCII. string MUST be limited to US-ASCII. Software evaluating check_host() can use this string to communicate Software evaluating check_host() can use this string to communicate information from the publishing domain in the form of a short message information from the publishing domain in the form of a short message or URL. Software SHOULD make it clear that the explanation string or URL. Software SHOULD make it clear that the explanation string comes from a third party. For example, it can prepend the macro comes from a third party. For example, it can prepend the macro string "%{o} explains: " to the explanation, such as shown in Section string "%{o} explains: " to the explanation, such as shown in 2.5.4. Section 2.5.4. Suppose example.com has this record: Suppose example.com has this record: v=spf1 mx -all exp=explain._spf.%{d} v=spf1 mx -all exp=explain._spf.%{d} Here are some examples of possible explanation TXT records at Here are some examples of possible explanation TXT records at explain._spf.example.com: explain._spf.example.com: "Mail from example.com should only be sent by its own servers." "Mail from example.com should only be sent by its own servers." -- a simple, constant message -- a simple, constant message "%{i} is not one of %{d}'s designated mail servers." "%{i} is not one of %{d}'s designated mail servers." -- a message with a little more information, including the IP -- a message with a little more information, including the IP address that failed the check address that failed the check "See http://%{d}/why.html?s=%{S}&i=%{I}" "See http://%{d}/why.html?s=%{S}&i=%{I}" -- a complicated example that constructs a URL with the -- a complicated example that constructs a URL with the arguments to check_host() so that a web page can be arguments to check_host() so that a web page can be generated with detailed, custom instructions generated with detailed, custom instructions Note: During recursion into an "include" mechanism, an exp= modifier Note: During recursion into an "include" mechanism, an exp= modifier from the MUST NOT be used. In contrast, when executing from the MUST NOT be used. In contrast, when executing a "redirect" modifier, an exp= modifier from the original domain MUST a "redirect" modifier, an exp= modifier from the original domain MUST NOT be used. NOT be used. 7. The Received-SPF Header Field 7. Recording The Result It is RECOMMENDED that SMTP receivers record the result of SPF To provide downstream agents, such as MUAs, with the information they processing in the message header. If an SMTP receiver chooses to do might need in terms of evaluating or representing the apparent safety so, it SHOULD use the "Received-SPF" header field defined here for of the message content, it is RECOMMENDED that SMTP receivers record each identity that was checked. This information is intended for the the result of SPF processing in the message header. For operators recipient. (Information intended for the sender is described in that choose to record SPF results in the header of the message for Section 6.2, Explanation.) processing by internal filters or MUAs, two methods are presented. Section 7.1 defines the Received-SPF field, which is the results field originally defined for SPF use. Section 7.2 discusses Authentication-Results [RFC5451] which was specified more recently and is designed for use by SPF and other authentication methods. The Received-SPF header field is a trace field (see [RFC2822] Section Both are in common use, and hence both are included here. However, it is important to note that they were designed to serve slightly different purposes. Received-SPF is intended to include enough forensic information to enable reconstruction of the SPF evaluation of the message, while Authentication-Results is designed only to relay the result itself and related output details of likely use to end users (e.g., what property of the message was actually authenticated and what it contained), leaving forensic work to the purview of system logs and the Received field contents. Also, Received-SPF relies on compliance of agents within the receiving ADMD to adhere to the header field ordering rules of [RFC5321] and [RFC5322], while Authentication-Results includes some provisions to protect against non-compliant implementations. An operator could choose to use both to serve different downstream agents. In such cases, care needs to be taken to ensure both fields are conveying the same details, or unexpected results can occur. 7.1. The Received-SPF Header Field The Received-SPF header field is a trace field (see [RFC5322] Section 3.6.7) and SHOULD be prepended to the existing header, above the 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver. It MUST Received: field that is generated by the SMTP receiver. It MUST appear above all other Received-SPF fields in the message. The appear above all other Received-SPF fields in the message. The header field has the following format: header field has the following format: header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF [ key-value-list ] CRLF result = "Pass" / "Fail" / "SoftFail" / "Neutral" / result = "pass" / "fail" / "softfail" / "neutral" / "None" / "TempError" / "PermError" "none" / "temperror" / "permerror" key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) [";"] [";"] key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / "problem" / "receiver" / "identity" / mechanism / "x-" name / name mechanism / name identity = "mailfrom" ; for the "MAIL FROM" identity identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / "helo" ; for the "HELO" identity / name ; other identities / name ; other identities dot-atom = dot-atom = quoted-string = quoted-string = comment = comment = CFWS = CFWS = FWS = FWS = CRLF = CRLF = The header field SHOULD include a "(...)" style after the The header field SHOULD include a "(...)" style comment after the result, conveying supporting information for the result, such as result, conveying supporting information for the result, such as , , and . , , and . The following key-value pairs are designed for later machine parsing. The following key-value pairs are designed for later machine parsing. SPF clients SHOULD give enough information so that the SPF results SPF verifiers SHOULD give enough information so that the SPF results can be verified. That is, at least "client-ip", "helo", and, if the can be verified. That is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from". "MAIL FROM" identity was checked, "envelope-from". client-ip the IP address of the SMTP client client-ip the IP address of the SMTP client envelope-from the envelope sender mailbox envelope-from the envelope sender mailbox helo the host name given in the HELO or EHLO command helo the host name given in the HELO or EHLO command mechanism the mechanism that matched (if no mechanisms matched, mechanism the mechanism that matched (if no mechanisms matched, substitute the word "default") substitute the word "default") problem if an error was returned, details about the error problem if an error was returned, details about the error receiver the host name of the SPF verifier receiver the host name of the SPF client identity the identity that was checked; see the ABNF identity the identity that was checked; see the ABNF rule rule Other keys may be defined by SPF clients. Until a new key name Other keys MAY be defined by SPF verifiers. becomes widely accepted, new key names should start with "x-". SPF clients MUST make sure that the Received-SPF header field does SPF verifiers MUST make sure that the Received-SPF header field does not contain invalid characters, is not excessively long, and does not not contain invalid characters, is not excessively long (See contain malicious data that has been provided by the sender. [RFC5322] Section 2.1.1), and does not contain malicious data that has been provided by the sender. Examples of various header styles that could be generated are the Examples of various header field styles that could be generated are following: the following: Received-SPF: Pass (mybox.example.org: domain of Received-SPF: pass (mybox.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from=; helo=foo.example.com; envelope-from="myname@example.com"; helo=foo.example.com; Received-SPF: Fail (mybox.example.org: domain of Received-SPF: fail (mybox.example.org: domain of myname@example.com does not designate myname@example.com does not designate 192.0.2.1 as permitted sender) 192.0.2.1 as permitted sender) identity=mailfrom; client-ip=192.0.2.1; identity=mailfrom; client-ip=192.0.2.1; envelope-from=; envelope-from="myname@example.com"; 7.2. SPF Results in the Authentication-Results Header Field As mentioned in Section 7, the Authentication-Results header field is designed to communicate lists of tests a border MTA did and their results. The specified elements of the field provide less information than the SPF-Received field: Authentication-Results: myhost.example.org; spf=pass smtp.mailfrom=example.net Received-SPF: pass (myhost.example.org: domain of myname@example.com designates 192.0.2.1 as permitted sender) receiver=mybox.example.org; client-ip=192.0.2.1; envelope-from="myname@example.com"; helo=foo.example.com; It is, however, possible to add CFWS in the "reason" part of an Authentication-Results header field and provide the equivalent information, if desired. As an example, an expanded Authentication-Results header field might look like (for a "MAIL FROM" check in this example): Authentication-Results: myhost.example.org; spf=pass reason="client-ip=192.0.2.1; smtp.helo=foo.example.com" smtp.mailfrom=user@example.net 8. Macros 8. Macros 8.1. Macro Definitions 8.1. Macro Definitions Many mechanisms and modifiers perform macro expansion on part of the Many mechanisms and modifiers perform macro expansion on a term. term. domain-spec = macro-string domain-end domain-spec = macro-string domain-end domain-end = ( "." toplabel [ "." ] ) / macro-expand domain-end = ( "." toplabel [ "." ] ) / macro-expand toplabel = ( *alphanum ALPHA *alphanum ) / toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) ; (see [RFC3696], Section 2 for background) alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT explain-string = *( macro-string / SP ) explain-string = *( macro-string / SP ) macro-string = *( macro-expand / macro-literal ) macro-string = *( macro-expand / macro-literal ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) / "%%" / "%_" / "%-" / "%%" / "%_" / "%-" macro-literal = %x21-24 / %x26-7E macro-literal = %x21-24 / %x26-7E ; visible characters except "%" ; visible characters except "%" macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / "c" / "r" / "t" "c" / "r" / "t" / "v" transformers = *DIGIT [ "r" ] transformers = *DIGIT [ "r" ] delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" A literal "%" is expressed by "%%". A literal "%" is expressed by "%%". "%_" expands to a single " " space. "%_" expands to a single " " space. "%-" expands to a URL-encoded space, viz., "%20". "%-" expands to a URL-encoded space, viz., "%20". The following macro letters are expanded in term arguments: The following macro letters are expanded in term arguments: s = s = l = local-part of l = local-part of o = domain of o = domain of d = d = i = i = p = the validated domain name of p = the validated domain name of (deprecated) v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 v = the string "in-addr" if is ipv4, or "ip6" if is ipv6 h = HELO/EHLO domain h = HELO/EHLO domain The following macro letters are allowed only in "exp" text: The following macro letters are allowed only in "exp" text: c = SMTP client IP (easily readable format) c = SMTP client IP (easily readable format) r = domain name of host performing the check r = domain name of host performing the check t = current timestamp t = current timestamp A '%' character not followed by a '{', '%', '-', or '_' character is A '%' character not followed by a '{', '%', '-', or '_' character is skipping to change at page 28, line 13 skipping to change at page 37, line 7 h = HELO/EHLO domain h = HELO/EHLO domain The following macro letters are allowed only in "exp" text: The following macro letters are allowed only in "exp" text: c = SMTP client IP (easily readable format) c = SMTP client IP (easily readable format) r = domain name of host performing the check r = domain name of host performing the check t = current timestamp t = current timestamp A '%' character not followed by a '{', '%', '-', or '_' character is A '%' character not followed by a '{', '%', '-', or '_' character is a syntax error. So a syntax error. So -exists:%(ir).sbl.spamhaus.example.org -exists:%(ir).sbl.spamhaus.example.org is incorrect and will cause check_host() to yield a "permerror". is incorrect and will cause check_host() to return a "PermError". Instead, say Instead, say -exists:%{ir}.sbl.spamhaus.example.org -exists:%{ir}.sbl.spamhaus.example.org Optional transformers are the following: Optional transformers are the following: *DIGIT = zero or more digits *DIGIT = zero or more digits 'r' = reverse value, splitting on dots by default 'r' = reverse value, splitting on dots by default If transformers or delimiters are provided, the replacement value for If transformers or delimiters are provided, the replacement value for a macro letter is split into parts. After performing any reversal a macro letter is split into parts. After performing any reversal operation and/or removal of left-hand parts, the parts are rejoined operation and/or removal of left-hand parts, the parts are rejoined skipping to change at page 28, line 32 skipping to change at page 37, line 23 *DIGIT = zero or more digits *DIGIT = zero or more digits 'r' = reverse value, splitting on dots by default 'r' = reverse value, splitting on dots by default If transformers or delimiters are provided, the replacement value for If transformers or delimiters are provided, the replacement value for a macro letter is split into parts. After performing any reversal a macro letter is split into parts. After performing any reversal operation and/or removal of left-hand parts, the parts are rejoined operation and/or removal of left-hand parts, the parts are rejoined using "." and not the original splitting characters. using "." and not the original splitting characters. By default, strings are split on "." (dots). Note that no special By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, treatment is given to leading, trailing, or consecutive delimiters in and so the list of parts may contain empty strings. Older input strings, and so the list of parts might contain empty strings. implementations of SPF prohibit trailing dots in domain names, so Some older implementations of SPF prohibit trailing dots in domain trailing dots should not be published by domain owners, although they names, so trailing dots SHOULD NOT be published by domain owners, must be accepted by implementations conforming to this document. although they MUST be accepted by implementations conforming to this Macros may specify delimiter characters that are used instead of ".". document. Macros can specify delimiter characters that are used instead of ".". The 'r' transformer indicates a reversal operation: if the client IP The 'r' transformer indicates a reversal operation: if the client IP address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" and the macro %{ir} would expand to "1.2.0.192". and the macro %{ir} would expand to "1.2.0.192". The DIGIT transformer indicates the number of right-hand parts to The DIGIT transformer indicates the number of right-hand parts to use, after optional reversal. If a DIGIT is specified, the value use, after optional reversal. If a DIGIT is specified, the value MUST be nonzero. If no DIGITs are specified, or if the value MUST be nonzero. If no DIGITs are specified, or if the value specifies more parts than are available, all the available parts are specifies more parts than are available, all the available parts are used. If the DIGIT was 5, and only 3 parts were available, the macro used. If the DIGIT was 5, and only 3 parts were available, the macro interpreter would pretend the DIGIT was 3. Implementations MUST interpreter would pretend the DIGIT was 3. Implementations MUST support at least a value of 128, as that is the maximum number of support at least a value of 128, as that is the maximum number of labels in a domain name. labels in a domain name. The "s" macro expands to the argument. It is an E-Mail The "s" macro expands to the argument. It is an email address with a localpart, an "@" character, and a domain. The "l" address with a local-part, an "@" character, and a domain. The "l" macro expands to just the localpart. The "o" macro expands to just macro expands to just the local-part. The "o" macro expands to just the domain part. Note that these values remain the same during the domain part. Note that these values remain the same during recursive and chained evaluations due to "include" and/or "redirect". recursive and chained evaluations due to "include" and/or "redirect". Note also that if the original had no localpart, the Note also that if the original had no local-part, the local- localpart was set to "postmaster" in initial processing (see Section part was set to "postmaster" in initial processing (see Section 4.3). 4.3). For IPv4 addresses, both the "i" and "c" macros expand to the For IPv4 addresses, both the "i" and "c" macros expand to the standard dotted-quad format. standard dotted-quad format. For IPv6 addresses, the "i" macro expands to a dot-format address; it For IPv6 addresses, the "i" macro expands to a dot-format address; it is intended for use in %{ir}. The "c" macro may expand to any of the is intended for use in %{ir}. The "c" macro can expand to any of the hexadecimal colon-format addresses specified in [RFC3513], Section hexadecimal colon-format addresses specified in [RFC4291], Section 2.2. It is intended for humans to read. 2.2. It is intended for humans to read. The "p" macro expands to the validated domain name of . The The "p" macro expands to the validated domain name of . The procedure for finding the validated domain name is defined in Section procedure for finding the validated domain name is defined in 5.5. If the is present in the list of validated domains, it Section 5.5. If the is present in the list of validated SHOULD be used. Otherwise, if a subdomain of the is domains, it SHOULD be used. Otherwise, if a subdomain of the present, it SHOULD be used. Otherwise, any name from the list may be is present, it SHOULD be used. Otherwise, any name from the used. If there are no validated domain names or if a DNS error list can be used. If there are no validated domain names or if a DNS occurs, the string "unknown" is used. error occurs, the string "unknown" is used. This macro is deprecated and SHOULD NOT be used. The "r" macro expands to the name of the receiving MTA. This SHOULD The "r" macro expands to the name of the receiving MTA. This SHOULD be a fully qualified domain name, but if one does not exist (as when be a fully qualified domain name, but if one does not exist (as when the checking is done by a MUA) or if policy restrictions dictate the checking is done by a MUA) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted. The domain name otherwise, the word "unknown" SHOULD be substituted. The domain name may be different from the name found in the MX record that the client can be different from the name found in the MX record that the client MTA used to locate the receiving MTA. MTA used to locate the receiving MTA. The "t" macro expands to the decimal representation of the The "t" macro expands to the decimal representation of the approximate number of seconds since the Epoch (Midnight, January 1, approximate number of seconds since the Epoch (Midnight, January 1, 1970, UTC). This is the same value as is returned by the POSIX 1970, UTC) at the time of the evaluation. This is the same value as time() function in most standards-compliant libraries. is returned by the POSIX time() function in most standards-compliant libraries. When the result of macro expansion is used in a domain name query, if When the result of macro expansion is used in a domain name query, if the expanded domain name exceeds 253 characters (the maximum length the expanded domain name exceeds 253 characters (the maximum length of a domain name), the left side is truncated to fit, by removing of a domain name), the left side is truncated to fit, by removing successive domain labels until the total length does not exceed 253 successive domain labels (and their following dots) until the total characters. length does not exceed 253 characters. Uppercased macros expand exactly as their lowercased equivalents, and Uppercased macros expand exactly as their lowercased equivalents, and are then URL escaped. URL escaping must be performed for characters are then URL escaped. URL escaping MUST be performed for characters not in the "uric" set, which is defined in [RFC3986]. not in the "unreserved" set, which is defined in [RFC3986]. Note: Care must be taken so that macro expansion for legitimate Note: Care has to be taken so that macro expansion for legitimate E-Mail does not exceed the 63-character limit on DNS labels. The email does not exceed the 63-character limit on DNS labels. The localpart of E-Mail addresses, in particular, can have more than 63 local-part of email addresses, in particular, can have more than 63 characters between dots. characters between dots. Note: Domains should avoid using the "s", "l", "o", or "h" macros in Note: Domains SHOULD avoid using the "s", "l", "o", or "h" macros in conjunction with any mechanism directive. Although these macros are conjunction with any mechanism directive. Although these macros are powerful and allow per-user records to be published, they severely powerful and allow per-user records to be published, they severely limit the ability of implementations to cache results of check_host() limit the ability of implementations to cache results of check_host() and they reduce the effectiveness of DNS caches. and they reduce the effectiveness of DNS caches. Implementations should be aware that if no directive processed during Note: If no directive processed during the evaluation of check_host() the evaluation of check_host() contains an "s", "l", "o", or "h" contains an "s", "l", "o", or "h" macro, then the results of the macro, then the results of the evaluation can be cached on the basis evaluation can be cached on the basis of and alone for of and alone for as long as the shortest Time To Live as long as the shortest Time To Live (TTL) of all the DNS records (TTL) of all the DNS records involved. involved. 8.2. Expansion Examples 8.2. Expansion Examples The is strong-bad@email.example.com. The is strong-bad@email.example.com. The IPv4 SMTP client IP is 192.0.2.3. The IPv4 SMTP client IP is 192.0.2.3. The IPv6 SMTP client IP is 2001:DB8::CB01. The IPv6 SMTP client IP is 2001:DB8::CB01. The PTR domain name of the client IP is mx.example.org. The PTR domain name of the client IP is mx.example.org. macro expansion macro expansion ------- ---------------------------- ------- ---------------------------- skipping to change at page 31, line 20 skipping to change at page 40, line 4 bad.strong.lp.3.2.0.192.in-addr._spf.example.com bad.strong.lp.3.2.0.192.in-addr._spf.example.com %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} %{ir}.%{v}.%{l1r-}.lp._spf.%{d2} 3.2.0.192.in-addr.strong.lp._spf.example.com 3.2.0.192.in-addr.strong.lp._spf.example.com %{d2}.trusted-domains.example.net %{d2}.trusted-domains.example.net example.com.trusted-domains.example.net example.com.trusted-domains.example.net IPv6: IPv6: %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 9. Implications 9. Implications This section outlines the major implications that adoption of this This section outlines the major implications that adoption of this document will have on various entities involved in Internet E-Mail. document will have on various entities involved in Internet email. It is intended to make clear to the reader where this document It is intended to make clear to the reader where this document knowingly affects the operation of such entities. This section is knowingly affects the operation of such entities. This section is not a "how-to" manual, or a "best practices" document, and it is not not a "how-to" manual, or a "best practices" document, and it is not a comprehensive list of what such entities should do in light of this a comprehensive list of what such entities SHOULD do in light of this document. document. This section is non-normative. This section is non-normative. [RFC5598] describes the Internet email architecture. This section is organized based on the different segments of the architecture. 9.1. Sending Domains 9.1. Sending Domains Domains that wish to be compliant with this specification will need Originating ADMDs (ADministrative Management Domains - [RFC5598] to determine the list of hosts that they allow to use their domain Section 2.2.1 and Section 2.3) that wish to be compliant with this name in the "HELO" and "MAIL FROM" identities. It is recognized that specification will need to determine the list of relays ([RFC5598] forming such a list is not just a simple technical exercise, but Section 2.2.2) that they allow to use their domain name in the "HELO" involves policy decisions with both technical and administrative and "MAIL FROM" identities when relaying to other ADMDs. It is considerations. recognized that forming such a list is not just a simple technical exercise, but involves policy decisions with both technical and administrative considerations. It can be helpful to publish records that include a "tracking 9.1.1. DNS Resource Considerations Minimizing the DNS resources required for SPF lookups can be done by choosing directives that require less DNS information and by placing lower-cost mechanisms earlier in the SPF record. +----------+--------+-----------------+ | term | cost | limit | +----------+--------+-----------------+ | ip4/ip6 | 0 | - | | a | 1 | 10 | | include | 1 | 10 | | redirect | 1 | 10 | | exists | 1 | 10 | | mx | 1 + N* | 10 and N* <= 10 | | ptr/%{p} | 1 + N* | 10 and N* <= 10 | | all | 0 | - | +----------+--------+-----------------+ * N is the number of RRs found during each term evaluation Section 4.6.4 specifies the limits receivers have to use. It is essential to publish records that do not exceed these requirements. It is also required to carefully weight the cost and the maintainability of licit solutions. For example, consider a domain set up as follows: example.com. IN MX 10 mx.example.com. IN MX 20 mx2.example.com. mx.example.com. IN A 192.0.2.1 mx2.example.com. IN A 192.0.2.129 Assume the administrative point is to authorize (pass) mx and mx2 while failing every other host. Compare the following solutions: Best record: example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all" Good record: $ORIGIN example.com. @ IN TXT "v=spf1 a:authorized-spf.example.com -all" authorized-spf IN A 192.0.2.1 IN A 192.0.2.129 Expensive record: example.com. IN TXT "v=spf1 mx:example.com -all" Wasteful, bad record: example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all" 9.1.2. Administrator's Considerations There might be administrative considerations: using "a" over "ip4" or "ip6" allows hosts to be renumbered easily. Using "mx" over "a" allows the set of mail hosts to be changed easily. Unless such changes are common, it is better to use the less resource intensive mechanisms like "ip4" and "ip6" over "a" or "a" or "mx". In some specific cases, standard advice on record content is appropriate. Publishing SPF records for domains that send no mail is a well established best practice. The record for a domain that sends no mail is: www.example.com. IN TXT "v=spf1 -all" Publishing SPF records for individual hosts is also best practice. The hostname is generally the identity used in the 5321.HELO/.EHLO command. In the case of messages with a null 5321.MailFrom, this is used as the domain for 5321.MailFrom SPF checks, in addition to being used in 5321.HELO/.EHLO based SPF checks. The standard SPF record for an individual host that is involved in mail processing is: relay.example.com. IN TXT "v=spf1 a -all" Validating correct deployment is difficult. [RFC6652] describes one mechanism for soliciting feedback on SPF failures. Another approach that can be helpful to publish records that include a "tracking exists:" mechanism. By looking at the name server logs, a rough list exists:" mechanism. By looking at the name server logs, a rough list may then be generated. For example: can then be generated. For example: v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all 9.2. Mailing Lists Regardless of the method used, understanding the ADMD's outbound mail architecture is essential to effective deployment. Mailing lists must be aware of how they re-inject mail that is sent 9.1.3. Bounces to the list. Mailing lists MUST comply with the requirements in [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that As explained in Section 1.3.3, [RFC5321] allows the reverse-path to be null, which is typical of some Delivery Status Notification [RFC3464], commonly called email bounces. In this case the only entity available for performing an SPF check is the "HELO" identity defined in Section 1.3.4. SPF functionality is enhanced by administrators ensuring this identity is set correctly and has an appropriate SPF record. It is normal to have the HELO identity set to hostname instead of domain. Zone file generation for significant numbers of hosts can be consolidated using the redirect modifier and scripted for initial deployment. Specific deployment advice is given above in Section 9.1.2. 9.2. Mediators Broadly speaking, there are two types of mediating ADMDs that can affect SPF deployment of other ADMDs: mailing lists (see [RFC5598] Section 5.3) and ReSenders ([RFC5598] Section 5.2). 9.2.1. Mailing Lists Mailing lists have to be aware of how they re-inject mail that is sent to the list. Mailing lists MUST comply with the requirements in [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that the reverse-path MUST be changed to be the mailbox of a person or the reverse-path MUST be changed to be the mailbox of a person or other entity who administers the list. Whereas the reasons for other entity who administers the list. Whereas the reasons for changing the reverse-path are many and long-standing, SPF adds changing the reverse-path are many and long-standing, SPF adds enforcement to this requirement. enforcement to this requirement. In practice, almost all mailing list software in use already complies In practice, almost all mailing list software in use already complies with this requirement. Mailing lists that do not comply may or may with this requirement. Mailing lists that do not comply might not encounter problems depending on how access to the list is encounter problems depending on how access to the list is restricted. restricted. Such lists that are entirely internal to a domain (only Such lists that are entirely internal to a domain (only people in the people in the domain can send to or receive from the list) are not domain can send to or receive from the list) are not affected. affected. 9.3. Forwarding Services and Aliases 9.2.2. Forwarding Services and Aliases Forwarding services take mail that is received at a mailbox and Forwarding services take mail that is received at a mailbox and direct it to some external mailbox. At the time of this writing, the direct it to some external mailbox. At the time of this writing, the near-universal practice of such services is to use the original "MAIL near-universal practice of such services is to use the original "MAIL FROM" of a message when re-injecting it for delivery to the external FROM" of a message when re-injecting it for delivery to the external mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" mailbox. [RFC1123] and [RFC5321] describe this action as an "alias" rather than a "mail list". This means that the external mailbox's rather than a "mail list". This means the external mailbox's MTA MTA sees all such mail in a connection from a host of the forwarding sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not, in general, pass service, and so the "MAIL FROM" identity will not, in general, pass authorization. authorization. There are three places that techniques can be used to ameliorate this There are three places that techniques can be used to ameliorate this problem. problem. 1. The beginning, when E-Mail is first sent. 1. The beginning, when email is first sent (Originating ADMDs). 1. "Neutral" results could be given for IP addresses that may be 1. "Neutral" results could be given for IP addresses that might forwarders, instead of "Fail" results. For example: be forwarders, instead of "fail" results based on a list of known reliable forwarders. For example: "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" "v=spf1 mx ?exists:%{ir}.whitlist.example.org -all" This would cause a lookup on an anti-spam DNS blacklist This would cause a lookup on an DNS white list (DNSWL) and (DNSBL) and cause a result of "Fail" only for E-Mail coming cause a result of "fail" only for email not either coming from listed sources. All other E-Mail, including E-Mail sent from the domain's mx host(s) (SPF pass) or white listed through forwarders, would receive a "Neutral" result. By sources (SPF neutral). This, in effect, outsources an checking the DNSBL after the known good sources, problems with element of sender policy to the maintainer of the whitelist. incorrect listing on the DNSBL are greatly reduced. 2. The "MAIL FROM" identity could have additional information in 2. The "MAIL FROM" identity could have additional information in the localpart that cryptographically identifies the mail as the local-part that cryptographically identifies the mail as coming from an authorized source. In this case, such an SPF coming from an authorized source. In this case, such an SPF record could be used: record could be used: "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" "v=spf1 mx exists:%{l}._spf_verify.%{d} -all" Then, a specialized DNS server can be set up to serve the Then, a specialized DNS server can be set up to serve the _spf_verify subdomain that validates the localpart. Although _spf_verify subdomain that validates the local-part. this requires an extra DNS lookup, this happens only when the Although this requires an extra DNS lookup, this happens only E-Mail would otherwise be rejected as not coming from a known when the email would otherwise be rejected as not coming from good source. a known good source. Note that due to the 63-character limit for domain labels, this approach only works reliably if the local-part signature scheme is guaranteed either to only produce local-parts with a maximum of 63 characters or to gracefully handle truncated local-parts. Note that due to the 63-character limit for domain labels, 3. Similarly, a specialized DNS server could be set up that will this approach only works reliably if the localpart signature rate-limit the email coming from unexpected IP addresses. scheme is guaranteed either to only produce localparts with a maximum of 63 characters or to gracefully handle truncated localparts. 3. Similarly, a specialized DNS server could be set up that will "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" rate-limit the E-Mail coming from unexpected IP addresses. "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" 4. SPF allows the creation of per-user policies for special cases. For example, the following SPF record and appropriate wildcard DNS records can be used: 4. SPF allows the creation of per-user policies for special "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" cases. For example, the following SPF record and appropriate wildcard DNS records can be used: "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" 2. The middle, when email is forwarded (Mediating ADMDs). 2. The middle, when E-Mail is forwarded. 1. Forwarding services can solve the problem by rewriting the "MAIL FROM" to be in their own domain. This means mail rejected from the external mailbox will have to be forwarded back to the original sender by the forwarding service. Various schemes to do this exist though they vary widely in complexity and resource requirements on the part of the forwarding service. 1. Forwarding services can solve the problem by rewriting the 2. Several popular MTAs can be forced from "alias" semantics to "MAIL FROM" to be in their own domain. This means that mail "mailing list" semantics by configuring an additional alias bounced from the external mailbox will have to be re-bounced with "owner-" prepended to the original alias name (e.g., an by the forwarding service. Various schemes to do this exist alias of "friends: george@example.com, fred@example.org" though they vary widely in complexity and resource would need another alias of the form "owner-friends: requirements on the part of the forwarding service. localowner"). 2. Several popular MTAs can be forced from "alias" semantics to 3. Forwarding servers could reject mail that would "fail" SPF if "mailing list" semantics by configuring an additional alias forwarded using an SMTP reply code of 551, User not local, with "owner-" prepended to the original alias name (e.g., an (see [RFC5321] section 3.4) to communicate the correct target alias of "friends: george@example.com, fred@example.org" would address to resend the mail to. need another alias of the form "owner-friends: localowner"). 3. The end, when E-Mail is received. 3. The end, when email is received (Receiving ADMDs). 1. If the owner of the external mailbox wishes to trust the 1. If the owner of the external mailbox wishes to trust the forwarding service, he can direct the external mailbox's MTA forwarding service, he can direct the external mailbox's MTA to skip SPF tests when the client host belongs to the to skip SPF tests when the client host belongs to the forwarding service. forwarding service. 2. Tests against other identities, such as the "HELO" identity, 2. Tests against other identities, such as the "HELO" identity, may be used to override a failed test against the "MAIL FROM" MAY be used to override a failed test against the "MAIL FROM" identity. identity. 3. For larger domains, it may not be possible to have a complete 3. For larger domains, it might not be possible to have a or accurate list of forwarding services used by the owners of complete or accurate list of forwarding services used by the the domain's mailboxes. In such cases, whitelists of owners of the domain's mailboxes. In such cases, whitelists generally-recognized forwarding services could be employed. of generally-recognized forwarding services could be employed. 9.4. Mail Services 9.2.3. Mail Services Service providers that offer mail services to third-party domains, MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail such as sending of bulk mail, may want to adjust their setup in light services to third-party domains, such as sending of bulk mail, might of the authorization check described in this document. If the "MAIL want to adjust their configurations in light of the authorization FROM" identity used for such E-Mail uses the domain of the service check described in this document. If the domain part of the "MAIL provider, then the provider needs only to ensure that its sending FROM" identity used for such email uses the domain of one of the MSPs host is authorized by its own SPF record, if any. domain, then the provider needs only to ensure that its sending host is authorized by its own SPF record, if any. If the "MAIL FROM" identity does not use the mail service provider's If the "MAIL FROM" identity does not use the MSP's domain, then extra domain, then extra care must be taken. The SPF record format has care has to be taken. The SPF record format has several options for several options for the third-party domain to authorize the service the third-party domain to authorize the service provider's MTAs to provider's MTAs to send mail on its behalf. For mail service send mail on its behalf. For MSPs, such as ISPs, that have a wide providers, such as ISPs, that have a wide variety of customers using variety of customers using the same MTA, steps are required to the same MTA, steps should be taken to prevent cross-customer forgery mitiate the risk of cross-customer forgery (see Section 10.4). (see Section 10.4). 9.5. MTA Relays 9.2.4. MTA Relays The authorization check generally precludes the use of arbitrary MTA Relays are described in [RFC5598] Section 2.2.2. The authorization relays between sender and receiver of an E-Mail message. check generally precludes the use of arbitrary MTA relays between sender and receiver of an email message. Within an organization, MTA relays can be effectively deployed. Within an organization, MTA relays can be effectively deployed. However, for purposes of this document, such relays are effectively However, for purposes of this document, such relays are effectively transparent. The SPF authorization check is a check between border transparent. The SPF authorization check is a check between border MTAs of different domains. MTAs of different ADMDs. For mail senders, this means that published SPF records must For mail senders, this means that published SPF records have to authorize any MTAs that actually send across the Internet. Usually, authorize any MTAs that actually send across the Internet. Usually, these are just the border MTAs as internal MTAs simply forward mail these are just the border MTAs as internal MTAs simply forward mail to these MTAs for delivery. to these MTAs for relaying. Mail receivers will generally want to perform the authorization check The receiving ADMD will generally want to perform the authorization at the border MTAs, specifically including all secondary MXs. This check at the boundary MTAs, including all secondary MXs. Internal allows mail that fails to be rejected during the SMTP session rather MTAs (including MTAs that might serve both as boundary MTAs and than bounced. Internal MTAs then do not perform the authorization internal relays from secondary MXs when they are processing the test. To perform the authorization test other than at the border, relayed mail stream) then do not perform the authorization test. To the host that first transferred the message to the organization must perform the authorization test other than at the boundary, the host be determined, which can be difficult to extract from the message that first transferred the message to the receiving ADMD have to be header. Testing other than at the border is not recommended. determined, which can be difficult to extract from the message header because (a) header fields can be forged or malformed, and (b) there's no standard way to encode that information such that it can be reliably extracted. Testing other than at the boundary is likely to produce unreliable results. 9.3. Receivers SPF results can be used in combination with other methods to determine the final local disposition (either positive or negative of a message. It can also be considered dispositive on its own. 9.3.1. Policy For SPF Pass SPF pass results can be used in combination with "white lists" of known "good" domains to bypass some or all additional pre-delivery email checks. Exactly which checks and how to determine appropriate white list entries has to be based on local conditions and requirements. 9.3.2. Policy For SPF Fail SPF fail results can be used to reject messages during the SMTP transaction based on either "MAIL FROM" or "HELO" identity results. This reduces resource requirements for various content filtering methods and conserves bandwidth since rejection can be done before the SMTP content is transferred. It also gives immediate feedback to the sender who might then be able to resolve the issue. Due to some of the issues described above in this section (Section 9), SPF based rejection does present some risk of rejecting legitimate email when rejecting based on "MAIL FROM" results. SPF fail results can alternately be used as one input into a larger set of evaluations which might, based on a combination with other evaluation techniques, result in the email being marked negatively in some way (this might be via delivery to a special spam folder, modifying subject lines, or other locally determined means). Developing the details of such an approach have to be based on local conditions and requirements. Using SPF results in this way does not have the advantages of resource conservation and immediate feedback to the sender associated with SMTP rejection, but could produce fewer undesirable rejections in a well designed system. Such an approach might result in email that was not authorized by the sending ADMD being unknowingly delivered to end users. Either general approach can be used as they both leave a clear disposition of emails. They are either delivered in some manner or the sender is notified of the failure. Other dispositions such as "dropping" or deleting email after acceptance are inappropriate because they leave uncertainty and reduce the overall reliabilility and utility of email across the Internet. 9.3.3. Policy For SPF Permerror The "permerror" result (see Section 2.5.7) indicates the SPF processing module at the receiver determined that the retrieved SPF policy record could not be interpreted. This gives no true indication about the authorized use of the data found in the envelope. As with all results, implementers have a choice to make regarding what to do with a message that yields this result. SMTP allows only a few basic options. Rejection of the message is an option, in that it is the one thing a receiver can do to draw attention to the difficulty encountered while protecting itself from messages that do not have a definite SPF result of some kind. However, if the SPF implementation is defective and returns spurious "permerror" results, only the sender is actively notified of the defect (in the form of rejected mail), and not the receiver making use of SPF. The less intrusive handling choice is to deliver the message, perhaps with some kind of annotation of the difficulty encountered and/or logging of a similar nature. However, this will not be desirable to operators that wish to implement SPF checking as strictly as possible, nor is this sort of passive problem reporting typically effective. There is of course the option placing this choice in the hands of the operator rather than the implementer since this kind of choice is often a matter of local policy rather than a condition with a universal solution, but this adds one more piece of complexity to an already non-trivial environment. Both implementers and operators need to be cautious of all choices and outcomes when handling SPF results. 10. Security Considerations 10. Security Considerations 10.1. Processing Limits 10.1. Processing Limits As with most aspects of E-Mail, there are a number of ways that As with most aspects of email, there are a number of ways that malicious parties could use the protocol as an avenue for a malicious parties could use the protocol as an avenue for a Denial-of-Service (DoS) attack. The processing limits outlined here Denial-of-Service (DoS) attack. The processing limits outlined in are designed to prevent attacks such as the following: Section 4.6.4 are designed to prevent attacks such as the following: o A malicious party could create an SPF record with many references o A malicious party could create an SPF record with many references to a victim's domain and send many E-Mails to different SPF to a victim's domain and send many emails to different SPF clients; those SPF clients would then create a DoS attack. In verifiers; those SPF verifiers would then create a DoS attack. In effect, the SPF clients are being used to amplify the attacker's effect, the SPF verifiers are being used to amplify the attacker's bandwidth by using fewer bytes in the SMTP session than are used bandwidth by using fewer bytes in the SMTP session than are used by the DNS queries. Using SPF clients also allows the attacker to by the DNS queries. Using SPF clients also allows the attacker to hide the true source of the attack. hide the true source of the attack. o Whereas implementations of check_host() are supposed to limit the o Whereas implementations of check_host() are supposed to limit the number of DNS lookups, malicious domains could publish records number of DNS lookups, malicious domains could publish records that exceed these limits in an attempt to waste computation effort that exceed these limits in an attempt to waste computation effort at their targets when they send them mail. Malicious domains at their targets when they send them mail. Malicious domains could also design SPF records that cause particular could also design SPF records that cause particular implementations to use excessive memory or CPU usage, or to implementations to use excessive memory or CPU usage, or to trigger bugs. trigger bugs. o Malicious parties could send a large volume of mail purporting to o Malicious parties could send a large volume of mail purporting to come from the intended target to a wide variety of legitimate mail come from the intended target to a wide variety of legitimate mail hosts. These legitimate machines would then present a DNS load on hosts. These legitimate machines would then present a DNS load on the target as they fetched the relevant records. the target as they fetched the relevant records. Of these, the case of a third party referenced in the SPF record is Of these, the case of a third party referenced in the SPF record is the easiest for a DoS attack to effectively exploit. As a result, the easiest for a DoS attack to effectively exploit. As a result, limits that may seem reasonable for an individual mail server can limits that might seem reasonable for an individual mail server can still allow an unreasonable amount of bandwidth amplification. still allow an unreasonable amount of bandwidth amplification. Therefore, the processing limits need to be quite low. Therefore, the processing limits need to be quite low. SPF implementations MUST limit the number of mechanisms and modifiers 10.2. SPF-Authorized Email May Contain Other False Identities that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated. When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked. SPF implementations SHOULD limit the total amount of data obtained from the DNS queries. For example, when DNS over TCP or EDNS0 are available, there may need to be an explicit limit to how much data will be accepted to prevent excessive bandwidth usage or memory usage and DoS attacks. MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "TempError". Domains publishing records SHOULD try to keep the number of "include" mechanisms and chained "redirect" modifiers to a minimum. Domains SHOULD also try to minimize the amount of other DNS information needed to evaluate a record. This can be done by choosing directives that require less DNS information and placing lower-cost mechanisms earlier in the SPF record. For example, consider a domain set up as follows: example.com. IN MX 10 mx.example.com. mx.example.com. IN A 192.0.2.1 a.example.com. IN TXT "v=spf1 mx:example.com -all" b.example.com. IN TXT "v=spf1 a:mx.example.com -all" c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all" Evaluating check_host() for the domain "a.example.com" requires the MX records for "example.com", and then the A records for the listed hosts. Evaluating for "b.example.com" requires only the A records. Evaluating for "c.example.com" requires none. However, there may be administrative considerations: using "a" over "ip4" allows hosts to be renumbered easily. Using "mx" over "a" allows the set of mail hosts to be changed easily. 10.2. SPF-Authorized E-Mail May Contain Other False Identities The "MAIL FROM" and "HELO" identity authorizations must not be Do not construe the "MAIL FROM" and "HELO" identity authorizations to construed to provide more assurance than they do. It is entirely provide more assurance than they do. It is entirely possible for a possible for a malicious sender to inject a message using his own malicious sender to inject a message using his own domain in the domain in the identities used by SPF, to have that domain's SPF identities used by SPF, to have that domain's SPF record authorize record authorize the sending host, and yet the message can easily the sending host, and yet the message can easily list other list other identities in its header. Unless the user or the MUA identities in its header. Unless the user or the MUA takes care to takes care to note that the authorized identity does not match the note that the authorized identity does not match the other more other more commonly-presented identities (such as the From: header commonly-presented identities (such as the From: header field), the field), the user may be lulled into a false sense of security. user might be lulled into a false sense of security. 10.3. Spoofed DNS and IP Data 10.3. Spoofed DNS and IP Data There are two aspects of this protocol that malicious parties could There are two aspects of this protocol that malicious parties could exploit to undermine the validity of the check_host() function: exploit to undermine the validity of the check_host() function: o The evaluation of check_host() relies heavily on DNS. A malicious o The evaluation of check_host() relies heavily on DNS. A malicious attacker could attack the DNS infrastructure and cause attacker could attack the DNS infrastructure and cause check_host() to see spoofed DNS data, and then return incorrect check_host() to see spoofed DNS data, and then return incorrect results. This could include returning "Pass" for an value results. This could include returning "pass" for an value where the actual domain's record would evaluate to "Fail". See where the actual domain's record would evaluate to "fail". See [RFC3833] for a description of DNS weaknesses. [RFC3833] for a description of DNS weaknesses. o The client IP address, , is assumed to be correct. A o The client IP address, , is assumed to be correct. In a malicious attacker could spoof TCP sequence numbers to make mail modern, correctly configured system the risk of this not being appear to come from a permitted host for a domain that the true is nil. attacker is impersonating. 10.4. Cross-User Forgery 10.4. Cross-User Forgery By definition, SPF policies just map domain names to sets of By definition, SPF policies just map domain names to sets of authorized MTAs, not whole E-Mail addresses to sets of authorized authorized MTAs, not whole email addresses to sets of authorized users. Although the "l" macro (Section 8) provides a limited way to users. Although the "l" macro (Section 8) provides a limited way to define individual sets of authorized MTAs for specific E-Mail define individual sets of authorized MTAs for specific email addresses, it is generally impossible to verify, through SPF, the use addresses, it is generally impossible to verify, through SPF, the use of specific E-Mail addresses by individual users of the same MTA. of specific email addresses by individual users of the same MTA. It is up to mail services and their MTAs to directly prevent It is up to mail services and their MTAs to directly prevent cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be cross-user forgery: based on SMTP AUTH ([RFC4954]), users have to be restricted to using only those E-Mail addresses that are actually restricted to using only those email addresses that are actually under their control (see [RFC4409], Section 6.1). Another means to under their control (see [RFC6409], Section 6.1). Another means to verify the identity of individual users is message cryptography such verify the identity of individual users is message cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851]). as PGP ([RFC4880]) or S/MIME ([RFC5751]). 10.5. Untrusted Information Sources 10.5. Untrusted Information Sources SPF uses information supplied by third parties, such as the "HELO" An SPF compliant receiver gathers information from the SMTP commands domain name, the "MAIL FROM" address, and SPF records. This it receives and from the published DNS records of the sending domain information is then passed to the receiver in the Received-SPF: trace holder, (e.g., "HELO" domain name, the "MAIL FROM" address from the fields and possibly returned to the client MTA in the form of an SMTP envelope, and SPF DNS records published by the domain holder). rejection message. This information must be checked for invalid characters and excessively long lines. When the authorization check fails, an explanation string may be 10.5.1. Recorded Results This information, passed to the receiver in the Received-SPF: or Authentication-Results: trace fields, may be returned to the client MTA as an SMTP rejection message. If such an SMTP rejection message is generated, the information from the trace fields has to be checked for such problems as invalid characters and excessively long lines. 10.5.2. External Explanations When the authorization check fails, an explanation string could be included in the reject response. Both the sender and the rejecting included in the reject response. Both the sender and the rejecting receiver need to be aware that the explanation was determined by the receiver need to be aware that the explanation was determined by the publisher of the SPF record checked and, in general, not the publisher of the SPF record checked and, in general, not the receiver. The explanation may contain malicious URLs, or it may be receiver. The explanation can contain malicious URLs, or it might be offensive or misleading. offensive or misleading. This is probably less of a concern than it may initially seem since Explanations returned to sender domains due to "exp" modifiers, such messages are returned to the sender, and the explanation strings (Section 6.2), were generated by the sender policy published by the come from the sender policy published by the domain in the identity domain holders themselves. As long as messages are only returned claimed by that very sender. As long as the DSN is not redirected to with non-delivery notification ([RFC3464]) to domains publishing the someone other than the actual sender, the only people who see explanation strings from their own DNS SPF records, the only affected malicious explanation strings are people whose messages claim to be parties are the original publishers of the domain's SPF records. from domains that publish such strings in their SPF records. In practice, DSNs can be misdirected, such as when an MTA accepts an In practice, such non-delivery notifications can be misdirected, such E-Mail and then later generates a DSN to a forged address, or when an as when an MTA accepts an email and only later generates the E-Mail forwarder does not direct the DSN back to the original sender. notification to a forged address, or when an email forwarder does not direct the bounce back to the original sender. 10.5.3. Macro Expansion Macros (Section 8) allow senders to inject arbitrary text (any non- null [US-ASCII] character) into receiver DNS queries. It is necesary to be prepared for hostile or unexpected content. 10.6. Privacy Exposure 10.6. Privacy Exposure Checking SPF records causes DNS queries to be sent to the domain Checking SPF records causes DNS queries to be sent to the domain owner. These DNS queries, especially if they are caused by the owner. These DNS queries, especially if they are caused by the "exists" mechanism, can contain information about who is sending "exists" mechanism, can contain information about who is sending E-Mail and likely to which MTA the E-Mail is being sent. This can email and likely to which MTA the email is being sent. This can introduce some privacy concerns, which may be more or less of an introduce some privacy concerns, which are more or less of an issue issue depending on local laws and the relationship between the domain depending on local laws and the relationship between the domain owner owner and the person sending the E-Mail. and the person sending the email. 11. Contributors and Acknowledgements 11. Contributors and Acknowledgements This document is largely based on the work of Meng Weng Wong and Mark This document is largely based on the work of Meng Weng Wong, Mark Lentczner. Although, as this section acknowledges, many people have Lentczner, and Wayne Schlitt. Although, as this section contributed to this document, a very large portion of the writing and acknowledges, many people have contributed to this document, a very editing are due to Meng and Mark. large portion of the writing and editing are due to Meng, Mark, and Wayne. This design owes a debt of parentage to [RMX] by Hadmut Danisch and This design owes a debt of parentage to [RMX] by Hadmut Danisch and to [DMP] by Gordon Fecyk. The idea of using a DNS record to check to [DMP] by Gordon Fecyk. The idea of using a DNS record to check the legitimacy of an E-Mail address traces its ancestry further back the legitimacy of an email address traces its ancestry further back through messages on the namedroppers mailing list by Paul Vixie through messages on the namedroppers mailing list by Paul Vixie [Vixie] (based on suggestion by Jim Miller) and by David Green [Vixie] (based on suggestion by Jim Miller) and by David Green [Green]. [Green]. Philip Gladstone contributed the concept of macros to the Philip Gladstone contributed the concept of macros to the specification, multiplying the expressiveness of the language and specification, multiplying the expressiveness of the language and making per-user and per-IP lookups possible. making per-user and per-IP lookups possible. The authors would also like to thank the literally hundreds of The authors of both this document and [RFC4408] would also like to individuals who have participated in the development of this design. thank the literally hundreds of individuals who have participated in They are far too numerous to name, but they include the following: the development of this design. They are far too numerous to name, but they include the following: The participants in the SPFbis working group. The folks on the spf-discuss mailing list. The folks on the spf-discuss mailing list. The folks on the SPAM-L mailing list. The folks on the SPAM-L mailing list. The folks on the IRTF ASRG mailing list. The folks on the IRTF ASRG mailing list. The folks on the IETF MARID mailing list. The folks on the IETF MARID mailing list. The folks on #perl. The folks on #perl. 12. IANA Considerations 12. IANA Considerations 12.1. The SPF DNS Record Type 12.1. The SPF DNS Record Type The IANA has assigned a new Resource Record Type and Qtype from the Per [RFC4408], the IANA assigned the Resource Record Type and Qtype DNS Parameters Registry for the SPF RR type with code 99. from the DNS Parameters Registry for the SPF RR type with code 99. The format of this type is identical to the TXT RR [RFC1035]. The character content of the record is encoded as [US-ASCII]. Use of this record type is obsolete for SPF Version 1. IANA is requested to add an annotation to the SPF RRTYPE saying "(OBSOLETE - use TXT)" in the DNS Parameters registry. [NOTE TO RFC EDITOR: (to be changed to " ... has added ..." upon publication)] 12.2. The Received-SPF Mail Header Field 12.2. The Received-SPF Mail Header Field Per [RFC3864], the "Received-SPF:" header field is added to the IANA Per [RFC3864], the "Received-SPF:" header field is added to the IANA Permanent Message Header Field Registry. The following is the Permanent Message Header Field Registry. The following is the registration template: registration template: Header field name: Received-SPF Header field name: Received-SPF Applicable protocol: mail ([RFC2822]) Applicable protocol: mail ([RFC5322]) Status: Experimental Status: Standards Track Author/Change controller: IETF Author/Change controller: IETF Specification document(s): RFC 4408 Specification document(s): RFC XXXX Related information: [NOTE TO RFC EDITOR: (this document)] Requesting SPF Council review of any proposed changes and additions to this field are recommended. For information about 12.3. SPF Modifier Registration the SPF Council see http://www.openspf.org/Council [RFC6652] created a new SPF Modifier Registration. IANA is requested to change the reference for the exp and redirect modifiers from [RFC4408] to this document. Their status should not be changed. 13. References 13. References 13.1. Normative References 13.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", April 2001. RFC 3463, January 2003. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. September 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, 3986, January 2005. RFC 3986, January 2005. [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Specifications: ABNF", RFC 4234, October 2005. Architecture", RFC 4291, February 2006. [US-ASCII] American National Standards Institute (formerly United [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [US-ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for Information Interchange, X3.4", 1968. Information Interchange, X3.4", 1968. ANSI X3.4-1968 has been replaced by newer versions with slight ANSI X3.4-1968 has been replaced by newer versions with modifications, but the 1968 version remains definitive for slight modifications, but the 1968 version remains the Internet. definitive for the Internet. 13.2 Informative References 13.2. Informative References [DMP] Fecyk, G., "Designated Mailers Protocol". Work In Progress [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987. [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, 1996. August 1996. [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS "OpenPGP Message Format", RFC 2440, November 1998. NCACHE)", RFC 2308, March 1998. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for RFC 2554, March 1999. specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [RFC3696] Klensin, J., "Application Techniques for Checking and [RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004. Transformation of Names", RFC 3696, February 2004. [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3834] Moore, K., "Recommendations for Automatic Responses to Extensions (S/MIME) Version 3.1 Message Specification", Electronic Mail", RFC 3834, August 2004. RFC 3851, July 2004. [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) RFC 4409, April 2006. for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. [RMX] Danish, H., "The RMX DNS RR Type for light weight sender [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing authentication", Work In Progress (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. [DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007. [Green] Green, D., "Domain-Authorized SMTP Mail", 2002. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, February 2010. [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, November 2011. [RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An Applicability Statement for SMTP", RFC 6647, June 2012. [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, June 2012. [RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework (SPF) and Sender ID Experiments", RFC 6686, July 2012. [RMX] Danisch, H., "The RMX DNS RR Type for light weight sender authentication". Work In Progress [Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. Appendix A. Collected ABNF Appendix A. Collected ABNF This section is normative and any discrepancies with the ABNF This section is normative and any discrepancies with the ABNF fragments in the preceding text are to be resolved in favor of this fragments in the preceding text are to be resolved in favor of this grammar. grammar. See [RFC4234] for ABNF notation. Please note that as per this ABNF See [RFC5234] for ABNF notation. Please note that as per this ABNF definition, literal text strings (those in quotes) are case- definition, literal text strings (those in quotes) are case- insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". record = version terms *SP record = version terms *SP version = "v=spf1" version = "v=spf1" terms = *( 1*SP ( directive / modifier ) ) terms = *( 1*SP ( directive / modifier ) ) directive = [ qualifier ] mechanism directive = [ qualifier ] mechanism qualifier = "+" / "-" / "?" / "~" qualifier = "+" / "-" / "?" / "~" skipping to change at page 42, line 38 skipping to change at page 57, line 38 MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] PTR = "ptr" [ ":" domain-spec ] PTR = "ptr" [ ":" domain-spec ] IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] exists = "exists" ":" domain-spec exists = "exists" ":" domain-spec modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string ; where name is not any known modifier ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199 / "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255 ; conventional dotted quad notation. e.g., 192.0.2.0 ; conventional dotted quad notation. e.g., 192.0.2.0 ip6-network = ip6-network = ; e.g., 2001:DB8::CD30 ; e.g., 2001:DB8::CD30 domain-spec = macro-string domain-end domain-spec = macro-string domain-end domain-end = ( "." toplabel [ "." ] ) / macro-expand domain-end = ( "." toplabel [ "." ] ) / macro-expand toplabel = ( *alphanum ALPHA *alphanum ) / toplabel = ( *alphanum ALPHA *alphanum ) / ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ; LDH rule plus additional TLD restrictions ; LDH rule plus additional TLD restrictions ; (see [RFC3696], Section 2) ; (see [RFC3696], Section 2 for background) alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT explain-string = *( macro-string / SP ) explain-string = *( macro-string / SP ) macro-string = *( macro-expand / macro-literal ) macro-string = *( macro-expand / macro-literal ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) / "%%" / "%_" / "%-" / "%%" / "%_" / "%-" macro-literal = %x21-24 / %x26-7E macro-literal = %x21-24 / %x26-7E ; visible characters except "%" ; visible characters except "%" macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / "c" / "r" / "t" "c" / "r" / "t" / "v" transformers = *DIGIT [ "r" ] transformers = *DIGIT [ "r" ] delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF [ key-value-list ] CRLF result = "Pass" / "Fail" / "SoftFail" / "Neutral" / result = "pass" / "fail" / "softfail" / "neutral" / "None" / "TempError" / "PermError" "none" / "temperror" / "permerror" key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) [";"] [";"] key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key = "client-ip" / "envelope-from" / "helo" / key = "client-ip" / "envelope-from" / "helo" / "problem" / "receiver" / "identity" / "problem" / "receiver" / identity / mechanism / "x-" name / name mechanism / name identity = "mailfrom" ; for the "MAIL FROM" identity identity = "mailfrom" ; for the "MAIL FROM" identity / "helo" ; for the "HELO" identity / "helo" ; for the "HELO" identity / name ; other identities / name ; other identities dot-atom = ALPHA = quoted-string = DIGIT = <0-9 as per [RFC5234]> comment = SP = CFWS = domain = FWS = dot-atom = CRLF = quoted-string = comment = CFWS = FWS = CRLF = authserv-id = reasonspec = Appendix B. Extended Examples Appendix B. Extended Examples These examples are based on the following DNS setup: These examples are based on the following DNS setup: ; A domain with two mail servers, two hosts ; A domain with two mail servers, two hosts ; and two servers at the domain name ; and two servers at the domain name $ORIGIN example.com. $ORIGIN example.com. @ MX 10 mail-a @ MX 10 mail-a MX 20 mail-b MX 20 mail-b skipping to change at page 44, line 46 skipping to change at page 60, line 46 ; A rogue reverse IP domain that claims to be ; A rogue reverse IP domain that claims to be ; something it's not ; something it's not $ORIGIN 0.0.10.in-addr.arpa. $ORIGIN 0.0.10.in-addr.arpa. 4 PTR bob.example.com. 4 PTR bob.example.com. B.1. Simple Examples B.1. Simple Examples These examples show various possible published records for These examples show various possible published records for example.com and which values if would cause check_host() to example.com and which values if would cause check_host() to return "Pass". Note that is "example.com". return "pass". Note that is "example.com". v=spf1 +all v=spf1 +all -- any passes -- any passes v=spf1 a -all v=spf1 a -all -- hosts 192.0.2.10 and 192.0.2.11 pass -- hosts 192.0.2.10 and 192.0.2.11 pass v=spf1 a:example.org -all v=spf1 a:example.org -all -- no sending hosts pass since example.org has no A records -- no sending hosts pass since example.org has no A records v=spf1 mx -all v=spf1 mx -all -- sending hosts 192.0.2.129 and 192.0.2.130 pass -- sending hosts 192.0.2.129 and 192.0.2.130 pass v=spf1 mx:example.org -all v=spf1 mx:example.org -all -- sending host 192.0.2.140 passes -- sending host 192.0.2.140 passes v=spf1 mx mx:example.org -all v=spf1 mx mx:example.org -all -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass v=spf1 mx/30 mx:example.org/30 -all v=spf1 mx/30 mx:example.org/30 -all -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes v=spf1 ptr -all v=spf1 ptr -all -- sending host 192.0.2.65 passes (reverse DNS is valid and is in -- sending host 192.0.2.65 passes (reverse DNS is valid and is in example.com) example.com) -- sending host 192.0.2.140 fails (reverse DNS is valid, but not -- sending host 192.0.2.140 fails (reverse DNS is valid, but not in example.com) in example.com) -- sending host 10.0.0.4 fails (reverse IP is not valid) -- sending host 10.0.0.4 fails (reverse IP is not valid) v=spf1 ip4:192.0.2.128/28 -all v=spf1 ip4:192.0.2.128/28 -all -- sending host 192.0.2.65 fails -- sending host 192.0.2.65 fails -- sending host 192.0.2.129 passes -- sending host 192.0.2.129 passes B.2. Multiple Domain Example B.2. Multiple Domain Example These examples show the effect of related records: These examples show the effect of related records: example.org: "v=spf1 include:example.com include:example.net -all" example.org: "v=spf1 include:example.com include:example.net -all" This record would be used if mail from example.org actually came This record would be used if mail from example.org actually came through servers at example.com and example.net. Example.org's through servers at example.com and example.net. Example.org's designated servers are the union of example.com's and example.net's designated servers are the union of example.com's and example.net's skipping to change at page 46, line 10 skipping to change at page 62, line 12 These records allow a set of domains that all use the same mail These records allow a set of domains that all use the same mail system to make use of that mail system's record. In this way, only system to make use of that mail system's record. In this way, only the mail system's record needs to be updated when the mail setup the mail system's record needs to be updated when the mail setup changes. These domains' records never have to change. changes. These domains' records never have to change. B.3. DNSBL Style Example B.3. DNSBL Style Example Imagine that, in addition to the domain records listed above, there Imagine that, in addition to the domain records listed above, there are these: are these: $ORIGIN _spf.example.com. mary.mobile-users A $ORIGIN _spf.example.com. 127.0.0.2 fred.mobile-users A 127.0.0.2 mary.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2 The following records describe users at example.com who mail from The following records describe users at example.com who mail from arbitrary servers, or who mail from personal servers. arbitrary servers, or who mail from personal servers. example.com: example.com: v=spf1 mx v=spf1 mx include:mobile-users._spf.%{d} include:mobile-users._spf.%{d} skipping to change at page 47, line 5 skipping to change at page 63, line 5 "-include:ip4._spf.%{d} " "-include:ip4._spf.%{d} " "-include:ptr._spf.%{d} " "-include:ptr._spf.%{d} " "+all" ) "+all" ) ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" ptr._spf.example.com. SPF "v=spf1 -ptr +all" ptr._spf.example.com. SPF "v=spf1 -ptr +all" This example shows how the "-include" mechanism can be useful, how an This example shows how the "-include" mechanism can be useful, how an SPF record that ends in "+all" can be very restrictive, and the use SPF record that ends in "+all" can be very restrictive, and the use of De Morgan's Law. of De Morgan's Law. Authors' Addresses Appendix C. Change History Meng Weng Wong Changes since RFC 4408 (to be removed prior to publication) Singapore EMail: mengwong+spf@pobox.com Moved to standards track Wayne Schlitt Authors updated 4615 Meredeth #9 Lincoln Nebraska, NE 68506 United States of America EMail: wayne@schlitt.net IESG Note regarding experimental use replaced with discussion of URI: http://www.schlitt.net/spf/ results Full Copyright Statement Process errata: Copyright (C) The Internet Society (2006). Resolved Section 2.5.7 PermError on invalid domains after macro expansion errata in favor of documenting that different clients produce different results. This document is subject to the rights, licenses and restrictions Add %v macro to ABNF grammar contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an Replace "uric" by "unreserved" "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property Recommend an SMTP reply code for optional permerror rejections The IETF takes no position regarding the validity or scope of any Correct syntax in Received-SPF examples Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any Fix unknown-modifier clause is too greedy in ABNF assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any Correct use of empty domain-spec on exp modifier copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Fix minor typo errata Funding for the RFC Editor function is provided by the IETF Convert to spfbis working group draft, Administrative Support Activity (IASA). draft-ietf-spfbis-4408bis-00 Addressed Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors by giving the option to turn repeated SERVFAIL into permerror and adding RFC 2308 reference. Clarified text about IPv4 mapped addresses to resolve test suite ambiguity Clarified ambiguity about result when more than 10 "mx" or "ptr" records are returned for lookup to specify permerror. This resolves one of the test suite ambiguities Made all references to result codes lower case per issue #7 Adjusted section 2.2 Requirement to check mail from per issue #15 Added missing "v" element in macro-letter in the collected ABNF per issue #16 - section 8.1 was already fixed in the pre-WG draft Marked ptr and "p" macro deprecated/SHOULD NOT use per issue #27 Expunged lower case may from the draft per issue #8 Expunged "x-" name as an obsolete concept Updated obslete references: RFC2821 to RFC5321, RFC2822 to RFC5322, and RFC4234 to RFC5234 Refer to RFC6647 to describe greylisting instead of trying to describe it directly. Updated informative references to the current versions. Added definition for deprecated since there are questions. Start to rework section 9 with some RFC5598 terms. Added mention of RFC 6552 feedback reports in section 9. Added draft-ietf-spfbis-experiment as an informational reference. Drop Type SPF. Try and clarify informational nature of RFC3696 Fix ABNF nits and add missing definitions per Bill's ABNF checker. Make DNS lookup time limit SHOULD instead of MAY. Reorganize and clarify processing limits. Move hard limits to new section 4.6.4, Evaluation Limits. Move advice to non-normative section 9. Removed paragraph in section 10.1 about limiting total data volumes as it is unused (and removable per the charter) and serves no purpose (it isn't something that actually can be implemented in any reasonable way). Added text and figures from Alessandro Vesely in section 9.1 to better explain DNS resource limits. Multiple editorial fixes from Murray Kucherawy's review. Also based on Murray's review, reworked SMTP identity definitions and made RFC 5598 a normative reference instead of informative. This is a downref that will have to be mentioned in the last call. Added RFC 3834 as an informative reference about backscatter. Added IDN requirements and normative reference to RFC 5890 to deal with the question "like DKIM did it.: Added informative reference to RFC 4632 for CIDR and use CIDR prefix length instead of CIDR-length to match its terminology. Added RFC 5782 informative reference on DNSxLs to support improving the exists description. Added text on creating a Authentication-Results header field that matches the Received-SPF header field information and added a normative reference to RFC 5451. Added informative reference to RFC 2782 due to SRV mention. Added informative reference to RFC 3464 due to DSN mention. Added informative reference to RFC 5617 for it's DNS wildcard use. Added informative reference to RFC 5782 to enhance the explanation of how the exists mechanism works. Clarified the intended match/ no-match method. Added new sections on Receiver policy for SPF pass, fail, and permerror. Added new section 9 discussion on treatment of bounces and the significance of HELO records. Added request to IANA to update the SPF modifier registry. Author's Address Scott Kitterman Kitterman Technical Services 3611 Scheel Dr Ellicott City, MD 21042 United States of America Email: scott@kitterman.com End of changes. 318 change blocks. 943 lines changed or deleted 1353 lines changed or added This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ --nextPart1485834.jITXE1tHj5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" Diff: rfc44= 08.txt - draft-ietf-spfbis-4408bis-08.txt = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = <= /table>

=A0rfc4408.txt=A0=

=A0draft-ietf-s= pfbis-4408bis-08.txt=A0

= Network Working Group <= /span>M. Wong

Network Working Group = S. Kitterman

Request for Comments: 4408 = W. Schlitt

Internet-Draft = Kitterman Technical Services

Category: Experimental = April 2006

Obsoletes: 4408 (if approved) = October 22, 2012

Intended status: Standar= ds Track

Sende= r Policy Framework (SPF) for

Expires: April 25, 2013

Authorizing = Use of Domains in E-Mail, Version 1

= Status of = Thi= s Memo

Sender Policy Frame= work (SPF) for Authorizing Use of Domains in Email,

= Version 1

draf= t-ietf-spfbis-4408bis-08.txt

= This memo defines an Experimental Protocol for the Internet=

Abstract

community. It does n= ot specify an Internet standard of any kind.

Discussion and sugges= tions for improvement are requested.

Distribution of this = memo is unlimited.

= Copyright Notice

Email on the Inte= rnet can be forged in a number of ways. In

particular, existing = protocols place no restriction on what a sending

host can use as the &= quot;MAIL FROM" of a message or the domain given on

the SMTP HELO/EHLO co= mmands. This document describes version 1 of

the Sender Policy Fra= mework (SPF) protocol, whereby an ADMD can

explicitly authorize = the hosts that are allowed to use its domain

names, and a receivin= g host can check such authorization.

= Copyright (C) The Internet Society (2006).

This document obs= oletes RFC4408.=

= IESG Note

Status of this Memo

= The following documents (RFC 4405, RFC 4406, RFC 4407, and= RFC 4408)

This Internet-Dra= ft is submitted in full conformance = with the

are published simulta= neously as Experimental RFCs, although there is

provisions of BCP= 78 and BCP 79.

no general techni= cal consensus and efforts to reconcile the two

approaches have faile= d. As such, these documents have not received

full IETF review and = are published "AS-IS" to document the different

approaches as they we= re considered in the <= /span>MARID working group.

= The IESG takes no position about which approach is to be pr= eferred

Internet-Drafts a= re working documents of the Internet Engineering

and cautions the reader that there are serious open issue= s for each

Task Force (IETF). N= ote that other gro= ups may also distribute

approach and concerns= about using them in tandem. The IESG believes

working documents as = Internet-Drafts. The = list of current Internet-

that documenting the = different approaches does less harm than not

Drafts is at http://d= atatracker.ietf.org/drafts/current/.

documenting them.

= Note that the Sender ID experiment may use DNS records that= may have

Internet-Drafts a= re draft documents valida maximum o= f six months

been created for the current SPF experi= ment or earlier versions in

and may be updated, replaced, or obsole= ted by other docum= ents at any

this set of experimen= ts. Depending on the content of the record,

time. It is inapprop= riate to use Internet-Drafts as reference

this may mean that Sender-ID heuristics= would be applied = incorrectly

material or to cite them other than as = "work in progress."

to a message. Depend= ing on the actions associated by the recipient

with those heuristics= , the message may not be delivered or may be

discarded on receipt.=

= Participants relying on Sender ID experiment DNS records are warned

This Internet-Dra= ft will expire on = April 25, 2013.

that they may lose va= lid messages in this set of circumstances.

aParticipants publish= ing SPF experiment DNS records should consider

the advice given in s= ection 3.4 of RFC 4406 and may wish to publish

both v=3Dspf1 and spf= 2.0 records to avoid the conflict.

= Participants in the Sender-ID experiment need to be aware t= hat the

Copyright Notice<= /p>

way Resent-* header f= ields are used will result in failure to receive

legitimate email when= interacting with standards-compliant systems

(specifically automat= ic forwarders which comply with the standards by

not adding Resent-* h= eaders, and systems which comply with RFC 822

but have not yet impl= emented RFC 2822 Resent-* semantics). It would

be inappropriate to a= dvance Sender-ID on the standards track without

resolving this intero= perability problem.

= The community is invited to observe the success or failure of the two

Copyright (c) 201= 2 IETF Trust and the <= /span>persons identified as

approaches during the= two years following publication, in order that

document authors.= All rights reserved.

a community consensus= can be reached in the future.

= Abstract

This document is = subject to BCP 78 and the IETF Trust's Legal

Provisions Relating t= o IETF Documents

(http://trustee.ietf.= org/license-info) in effect on the date of

publication of this d= ocument. Please review these documents

carefully, as they de= scribe your rights and restrictions with respect

to this document. Co= de Components extracted from this document must

include Simplified BS= D License text as described in Section 4.e of

the Trust Legal Provi= sions and are provided without warranty as

described in the Simp= lified BSD License.

= E-mail on = the Internet can be forged in a numberways. In

This document may= contain material from IETF Documents or IETF

particular, existing = protocols place no restriction on what a sending

Contributions publish= ed or made publicly available before November

host can use as the reverse-path of a m= essage or the <= span style=3D" font-family:'monospace'; background-color:#aaccff;">doma= in given on

10, 2008. The person= (s) controlling the in = som= e of this

the SMTP HELO/EHLO co= mmands. This document describes version 1 of

material may not have= granted the IETF = Trust the right to= allow

the Sender Policy= Framework (SPF) protocol, whereby a domain may

modifications<= span style=3D" font-family:'monospace';"> of such material outside = the IETF Standards Process.

explicitly author= ize the hosts that= are allowed to use its domain

Without obtaining an = adequate license from = the person(s) controlling

name, and a receiving host may check such authorization.<= /span>

the copyright in such= materials, this document may not be modified

outside the IETF Standards Process, and derivative works = of it may

not be created ou= tside the IETF Standards Process, except to format

it for publication as= an RFC or to translate it into languages other

than English.<= /p>

Table of Contents=

Table of Contents=

= 1. Introduction ...........................................= .........4

1. Introduction = . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1. Protocol Stat= us ............................................4

1.1. Protocol Stat= us . . . . . . . . . . . . . . . . . . . . . 6

1.2. Terminology <= /span>................................................5

1.2. Experimen= tal History . . . . . . . . . . . . . . . . . . . 7

2. Operation <= span style=3D" font-family:'monospace'; background-color:#aaccff;">....= ...................................................5

1.3. Terminology . . . . . . . . . = . . . . . . . . . . . . . . 7

2.1. The HELO<= /span> Identity .........= .................................5

1.3.1. Keywords = . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. The MAIL = FROM Identity <= span style=3D" font-family:'monospace'; background-color:#aaccff;">....= .................................5

1.3.2. Imported = Definitions . . . . . . . . . . . . . . . . . 7

2.3. Publishing Au= thorization ...................................6

1.3.3. Mail From= Definition . . . . . . . . . . . . . . . . . 7

2.4. Checking Auth= orization .....................................6

1.3.4. HELO Defi= nition . . . . . . . . . . . . . . . . . . . 8

2.5. Interpreting = the Result ....................................7

1.3.5. Deprecate= d . . . . . . . . . . . . . . . . . . . . . . 8

2.5.1. None <= /span>................................................8

2. Operation . = . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.2. Neutra= l .............................................8

2.1. The "= ;HELO" Identity = . . . . . . . . . . . . . . . . . . . 9

2.5.3. Pass <= /span>................................................8

2.2. The "= ;MAIL FROM" Ident= ity . . . . . . . . . . . . . . . . . 9

2.5.4. Fail <= /span>................................................8

2.3. Publishing Au= thorization . . . . . . . . . . . . . . . . . 9

2.5.5. So= ftFail ............................................9

2.4. Checking Auth= orization . . . . . . . . . . . . . . . . . . 10

2.5.6. Te= mpError ...........................................9

2.5. Interpreting = the Result . . . . . . . . . . . . . . . . . 11

2.5.7. Pe= rmError ...........................................9

2.5.1. None = . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. SPF Records ..= ...................................................9

2.5.2. Neutral = . . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Publishin= g ................................................10

2.5.3. Pass = . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1.= DNS Resource Record Type= s ..........................10

2.5.4. Fail = . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.2.= Multiple DNS Records = ...= ............................11

2.5.5. Softf= ail . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.3.= Multiple Strings in a Single= DNS record ............11

2.5.6. Tempe= rror . . . . . . . . . . . . . . . . . . . . . . 13

3.1.4.= Record Size ............= ............................11

2.5.7. Perme= rror . . . . . . . . . . . . . . . . . . . . . . 13

3.1.5.= Wildcard Records .......= ............................11

3. SPF Records = . . . . . . . . . . . . . . . . . . . . . . . . . 14

=

3.1. DNS Resource = Records . . . . . . . . . . . . . . . . . . . 14

4. The check_host() F= unction ......................................12

3.2. Multiple DNS Records . . . . . = . . . . . . . . . . . . . . 15

4.1. Arguments .................................................12

3.3. Multiple Strings in a Single DNS re= cord . . . . . . . . . 15

4.2. Results .= ..................................................13

3.4. Record Size . . . . . . . . . = . . . . . . . . . . . . . . 15

4.3. Initial Proce= ssing ........................................13

3.5. Wildcard Records . . . . . . . = . . . . . . . . . . . . . . 15

4.4. Record Lookup= .............................................13

4. The check_host() = Function . . . . . . . . . . . . . . . . . . 17

4.5. Selecting Rec= ords .........................................13

4.1. Arguments

4.6. Record Evalua= tion .........................................14

4.2. Results = . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.6.1. Term E= valuation ....................................14

4.3. Initial Proce= ssing . . . . . . . . . . . . . . . . . . . . 17

4.6.2. Mechan= isms .........................................15

4.4. Record Lookup= . . . . . . . . . . . . . . . . . . . . . . 18

4.6.3. Modifi= ers ..........................................15

4.5. Selecting Rec= ords . . . . . . . . . . . . . . . . . . . . 18

4.7. Default Resul= t ............................................16

4.6. Record Evalua= tion . . . . . . . . . . . . . . . . . . . . 18

4.8. Domain Specif= ication ......................................16

4.6.1. Term Eval= uation . . . . . . . . . . . . . . . . . . . 19

5. Mechanism Definiti= ons ..........................................16

4.6.2. Mechanism= s . . . . . . . . . . . . . . . . . . . . . . 19

5.1. "all&quo= t; .....................................................17

4.6.3. Modifiers= . . . . . . . . . . . . . . . . . . . . . . 20

5.2. "include= " .................................................18

4.6.4. DNS Looku= p Limits . . . . . . . . . . . . . . . . . . 20

5.3. "a"= .......................................................19

4.7. Default Resul= t . . . . . . . . . . . . . . . . . . . . . . 21

5.4. "mx"= ; ......................................................20

4.8. Domain Specif= ication . . . . . . . . . . . . . . . . . . . 21

5.5. "ptr&quo= t; .....................................................20

5. Mechanism Definit= ions . . . . . . . . . . . . . . . . . . . . 22

5.6. "ip4&quo= t; and "ip6" ...........................................2= 1

5.1. "all&quo= t; . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.7. "exists&= quot; ..................................................22

5.2. "include= " . . . . . . . . . . . . . . . . . . . . . . . . 23

6. Modifier Definitio= ns ...........................................22

5.3. "a"= . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1. redirect: Red= irected Query ................................23

5.4. "mx"= ; . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2. exp: Explanat= ion ..........................................23

5.5. "ptr&quo= t; (deprecated) . . . . . . . . . . . . . . . . . . . . 25

7. The Received-SPF H= eader Field ..................................25

5.6. "ip4&quo= t; and "ip6" . . . . . . . . . . . . . . . . . . . . . 2= 7

8. Macros .......= ..................................................27

5.7. "exists&= quot; . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.1. Macro Definit= ions .........................................27

6. Modifier Definiti= ons . . . . . . . . . . . . . . . . . . . . . 29

8.2. Expansion Exa= mples ........................................30

6.1. redirect: Red= irected Query . . . . . . . . . . . . . . . . 29

9. Implications .= ..................................................31

6.2. exp: Explanat= ion . . . . . . . . . . . . . . . . . . . . . 30

9.1. Sending Domai= ns ...........................................31

7. Recording The= Result . . . . . . . . . . . . . . . . . . . . . 32

9.2. Mailing Lists= .............................................32

7.1. The Received-SPF Header Field = . . . . . . . . . . . . . . 32

9.3. Forwarding Services and Aliases ...........................32

7.2. SPF Results i= n the Authentication-Results Header Field . . 34

9.4. Mail Services .................= ............................34

8. Macros . . . = . . . . . . . . . . . . . . . . . . . . . . . . . 36

9.5. MTA Relays ....................= ............................34

8.1. Macro Definit= ions . . . . . . . . . . . . . . . . . . . . 36

10. Security Consider= ations .......................................35

8.2. Expansion Exa= mples . . . . . . . . . . . . . . . . . . . . 39

10.1. Processing L= imits ........................................35

9. Implications = . . . . . . . . . . . . . . . . . . . . . . . . . 41

10.2. SPF-Authoriz= ed E-Mail May Cont= ain Other False

9.1. Sending Domai= ns . . . . . . . . . . . . . . . . . . . . . 41

Identities <= /span>...............................................37

9.1.1. DNS Resou= rce Considerations . . . . . . . . . . . . . 41

10.3. Spoofed DNS = and IP Data ..................................37

9.1.2. Administr= ator's Considerations . . . . . . . . . . . . 42

10.4. Cross-User F= orgery .......................................37

9.1.3. Bounces = . . . . . . . . . . . . . . . . . . . . . . . 43

10.5. Untrusted In= formation Sources ............................38

9.2. Mediators= . . . . . . . . . . . . . . . . . . . . . . . . 43

10.6. Privacy Expo= sure .........................................38

9.2.1. Mailing Lists . . . . . . = . . . . . . . . . . . . . . 43

11. Contributors and = Acknowledgements .............................38

9.2.2. Forwarding Services and Aliases= . . . . . . . . . . . 44

12. IANA Consideratio= ns ...........................................39

9.2.3. Mail Services . . . . . . = . . . . . . . . . . . . . . 46

12.1. The SPF DNS = Record Type ..................................39

9.2.4. MTA Relays . . . . . . . . .= . . . . . . . . . . . . . 46

12.2. The Received= -SPF Mail Header Field .......................39

9.3. Receivers . = . . . . . . . . . . . . . . . . . . . . . . . 47

13. References ..= ..................................................39

9.3.1. Policy Fo= r SPF Pass . . . . . . . . . . . . . . . . . 47

13.1. Normative Re= ferences .....................................39

9.3.2. Policy Fo= r SPF Fail . . . . . . . . . . . . . . . . . 47

13.2. Informative = References ...................................40

9.3.3. Policy Fo= r SPF Permerror . . . . . . . . . . . . . . . 48

=

10. Security Consider= ations . . . . . . . . . . . . . . . . . . . 49

Appendix A. Collecte= d ABNF .......................................42

10.1. Processing Li= mits . . . . . . . . . . . . . . . . . . . . 49

Appendix B. Extended= Examples ....................................44

10.2. SPF-Authorize= d Email May Contai= n Other False Identities B.1. Simple Examp= les ..........................................44

10.3. Spoofed DNS a= nd IP Data . . . . . . . . . . . . . . . . . 50

B.2. Multiple Dom= ain Example ..................................45

10.4. Cross-User Fo= rgery . . . . . . . . . . . . . . . . . . . . 50

B.3. DNSBL Style = Example ......................................46

10.5. Untrusted Inf= ormation Sources . . . . . . . . . . . . . . 50

B.4. Multiple Req= uirements Example ............................46

10.5.1. Recorded = Results . . . . . . . . . . . . . . . . . . . 50

10.5.2. External = Explanations . . . . . . . . . . . . . . . . 51

10.5.3. Macro Exp= ansion . . . . . . . . . . . . . . . . . . . 51

10.6. Privacy Expos= ure . . . . . . . . . . . . . . . . . . . . . 51

11. Contributors and = Acknowledgements . . . . . . . . . . . . . . 52

12. IANA Consideratio= ns . . . . . . . . . . . . . . . . . . . . . 53

12.1. The SPF DNS R= ecord Type . . . . . . . . . . . . . . . . . 53

12.2. The Received-= SPF Mail Header Field . . . . . . . . . . . . 53

12.3. SPF Modifier = Registration . . . . . . . . . . . . . . . . 53

13. References . = . . . . . . . . . . . . . . . . . . . . . . . . . 54

13.1. Normative Ref= erences . . . . . . . . . . . . . . . . . . . 54

13.2. Informative R= eferences . . . . . . . . . . . . . . . . . . 55

Appendix A. Collecte= d ABNF . . . . . . . . . . . . . . . . . . . 57

Appendix B. Extended= Examples . . . . . . . . . . . . . . . . . . 60

B.1. Simple Exampl= es . . . . . . . . . . . . . . . . . . . . . 60

B.2. Multiple Doma= in Example . . . . . . . . . . . . . . . . . 61

B.3. DNSBL Style E= xample . . . . . . . . . . . . . . . . . . . 62

B.4. Multiple Requ= irements Example . . . . . . . . . . . . . . 62

Appendix C. Change H= istory . . . . . . . . . . . . . . . . . . . 63

Author's Address . . = . . . . . . . . . . . . . . . . . . . . . . . 66

1. Introduction<= /p>

1. Introduction<= /p>

= The current E-Mail infrastructure has the property that any host

The current email= infrastructure has th= e property that any host

injecting mail into t= he mail system can= identify itself as any domain

injecting mail into t= he system can use = any DNS domain nam= e it wants

name it wants. H= osts can do this at a variety of levels: in

in each of= the various identifiers = specified by [RFC5321]= and

particular, the s= ession, the envelo= pe, and the mail h= eaders.

[RFC5322].= Although this feature is de= sirable in some circumstances,

Although this feature= is desirable in some circumstances, it is a

it is a major obstacl= e to reducing Unsolicited Bulk Email (UBE, aka

major obstacle to red= ucing Unsolicited Bulk E-Mail (UBE, aka spam).

spam). Furthermore, = many domain owning ADMDs (ADministrative

Furthermore, many dom= ain name holders a= re understandably concerned

Management Domains, s= ee [RFC5598]) are unde= rstandably concerned about

about the ease with w= hich other entities may make use of their domain

the ease with which o= ther entities can = make use of their domain

names, often with mal= icious intent.

names, often with mal= icious intent.

= This document defines a protocol by which domain owners may= authorize

<= /td>

This document defines= a protocol by which ADMDs can authorize hosts

hosts to use their do= main name in the &= quot;MAIL FROM" or "HELO" identity.

to use their domain <= /span>names in the "= MAIL FROM" or "HELO" identities.

Compliant domain = holders publish Sender= Policy Framework (SPF)

Compliant ADMDs publish Sender Policy F= ramework (SPF) records in the

records specifying wh= ich hosts are permitted to use their names, and

DNS specifying which hosts are permitted to= use their names, and

compliant mail receiv= ers use the published SPF records to test the

compliant mail receiv= ers use the published SPF records to test the

authorization of send= ing Mail Transfer Agents (MTAs) using a given

authorization of send= ing Mail Transfer Agents (MTAs) using a given

"HELO" or &= quot;MAIL FROM" identity during a mail transaction.

"HELO" or &= quot;MAIL FROM" identity during a mail transaction.

An additional benefit= to mail receivers is that after the use of an

An additional benefit= to mail receivers is that after the use of an

identity is verified,= local policy decisions about the mail can be

identity is verified,= local policy decisions about the mail can be

made based on the sen= der's domain, rather than the host's IP address.

made based on the sen= der's domain, rather than the host's IP address.

This is advantageous = because reputation of domain names is likely to

This is advantageous = because reputation of domain names is likely to

be more accurate than= reputation of host IP addresses. Furthermore,

be more accurate than= reputation of host IP addresses. Furthermore,

if a claimed identity= fails verification, local policy can take

if a claimed identity= fails verification, local policy can take

= stronger action against such E-Mail, such as rejecting it.

stronger action again= st such email, suc= h as rejecting it.

1.1. Protocol Status

1.1. Protocol Status

SPF has been in devel= opment since the summer of 2003 and has seen

SPF has been in devel= opment since the summer of 2003 and has seen

deployment beyond the= developers beginning in December 2003. The

deployment beyond the= developers beginning in December 2003. The

design of SPF slowly = evolved until the spring of 2004 and has since

design of SPF slowly = evolved until the spring of 2004 and has since

stabilized. There ha= ve been quite a number of forms of SPF, some

stabilized. There ha= ve been quite a number of forms of SPF, some

written up as documen= ts, some submitted as Internet Drafts, and many

written up as documen= ts, some submitted as Internet Drafts, and many

= discussed and debated in development forums.

discussed and debated= in development forums. The protocol was

originally defined in= [RFC4408], which this document replaces.

= The goal of this document is to clearly document the protocol defined

<= /td>

[RFC4408] was des= igned to clearly docum= ent the protocol defined by

by earlier draft spec= ifications of SPF as used in existing

earlier draft specifi= cations of SPF as used in existing

implementations. Thi= s conception of SPF is sometimes called "SPF

implementations. Thi= s updated specification is intended to clarify

Classic". It is= understood that particular implementations and

identified ambiguitie= s in [RFC4408], resolve techincal issues

deployments may diffe= r from, and build = upon, this work. It is hoped

identified in post-RF= C 4408 deplyment experience, and document widely

that we have nonetheless captured t= he common understanding of SPF

deployed extensions t= o SPF that have be= en developed since [RFC4408]

version 1.

=

was published.=

= 1.2. Terminology

1.2. Experimental H= istory

This document updates= and replaces RFC 4408 that was part of a group

of simultaneously pub= lished Experimental RFCs (RFC 4405, RFC 4406,

RFC 4407, and RFC 440= 8) in 2006. At that time the IESG requested the

community observe the= success or failure of the two approaches

documented in these R= FCs during the two years following publication,

in order that a commu= nity consensus could be reached in the future.

SPF is widely deploye= d by large and small email providers alike.

There are multiple, i= nteroperable implementations.

For SPF (as documente= d in RFC 4408) a careful effort was made to

collect and document = lessons learned and errata during the two year

period. The errata l= ist has been stable (no new submissions) and

only minor protocol l= essons learned were identified. Resolution of

the IESG's experiment= is documented in [RFC6686].

1.3. Terminology

=

1.3.1. Keywords<= /p>

The key words "M= UST", "MUST NOT", "REQUIRED", "SHALL"= ;, "SHALL NOT",

The key words "M= UST", "MUST NOT", "REQUIRED", "SHALL"= ;, "SHALL NOT",

= "SHOULD", "SHOULD NOT", "RECOMMENDED&q= uot;, "MAY", and "OPTIONAL" in this

"SHOULD", &= quot;SHOULD NOT", "RECOMMENDED", "NOT RECOMMEND= ED", "MAY&qu= ot;, and

document are to be in= terpreted as described in [RFC2119].

"OPTIONAL" = in this document are to be interpreted as described in

[RFC2119].

=

=

1.3.2. Imported Definit= ions

The ABNF tokens "= ;ALPHA", "DIGIT", and "SP" are defined in [RFC= 5234].

The token "local= -part" is defined in [RFC5321].

"dot-atom",= "quoted-string", "comment", "CFWS", &quo= t;FWS", and "CRLF" are

defined in [RFC5322].=

1.3.3. Mail From Defini= tion

This document is conc= erned with the portion of a mail message

This document is conc= erned with the portion of a mail message

commonly called "= ;envelope sender", "return path", "reverse path&quo= t;,

commonly called "= ;envelope sender", "return path", "reverse path&quo= t;,

= "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are

"bounce address&= quot;, "5321 = FROM", "MAIL FROM", or RFC5321.MailFrom.

<= /td>

either not well defin= ed or often used casually, this document defines

Since these terms are= either not well defined or often used casually,

the "MAIL FROM" identity in Section 2.2.= Note that other terms that<= /span>

this document = use= s "MAIL FROM"= ; for consistency. This means the

may superficially look like the common = terms, such as "reverse-path",

RFC5321.MailFrom as d= efined in [RFC5598= ]. Note that other te= rms that

are used only with th= e defined meanings from normative documents.

might superficially look like the commo= n terms, such as "reverse-

path", are used only with the defined = meanings from normative

documents.

=

= 2. Operation

1.3.4. HELO Definition

= 2.1. The HELO

This document als= o makes use of the HELO/EHLO identity. The "HELO"

identity derives from= either the SMTP HELO = or EHLO command (see

[RFC5321]). Since HE= LO and EHLO can, in many cases, be used

interchangeably, they= are identified commonly as "HELO" in this

document. This means= RFC5321.HELO/.EHLO as defined in [RFC5598].

These commands supply= the identity of the SMTP client (sending host)

for the SMTP session.=

= The "HELO" identity derives from either the SMTP = HELO or EHLO command

1.3.5. Deprecated

(see [RFC2821]). The= se commands supply the SMTP client (sending

host) for the SMTP se= ssion. Note that requirements for the domain

presented in the EHLO= or HELO command are not always clear to the

sending party, and SP= F clients must be prepared for the "HELO"

identity to be malfor= med or an IP address literal. At the time of

this writing, many le= gitimate E-Mails are delivered with invalid HELO

domains.

= It is RECOMMENDED that SPF clients not only check the "MAIL FROM"

There are [RFC440= 8] features that are marked "deprecated". In the

<= /td>

context of this docum= ent, deprecated means that senders SHOULD NOT

publish SPF records t= hat make use of such features because they might

be removed entirely i= n future updates to the protocol. Such features

do, however, remain p= art of the SPF protocol and receiving systems

MUST support them unl= ess this document explicitly says otherwise.

2. Operation

=

2.1. The "HELO&quo= t; Identity

=

It is RECOMMENDED tha= t SPF verifiers no= t only check the "MAIL FROM"

identity, but also se= parately check the "HELO" identity by applying

identity, but also se= parately check the "HELO" identity by applying

the check_host() func= tion (Section 4) to the "HELO" identity as the

the check_host() func= tion (Section 4) to the "HELO" identity as the

= <sender>.

<sender>. = Checking "HELO" promotes consistency of results and can

reduce DNS resource u= sage. Additionally, since SPF records published

for "HELO" = identities refer to a single host, when available, they

are a very reliable s= ource of host authorization status.

= 2.2. The MAIL FROM Identity

Note that require= ments for the domain presented in the EHLO or HELO

command are not alway= s clear to the sending party, and SPF verifiers

MUST be prepared for = the "HELO" identity to be malformed or an IP

address literal. Thi= s SPF check can only be performed when the

"HELO" stri= ng is a valid fully qualified domain.

= The "MAIL FROM" identity derives from the SMTP MA= IL command (see

2.2. The "MAIL FROM" Identity

[RFC2821]). This com= mand supplies the "reverse-path" for a message,

which generally consi= sts of the sender mailbox, and is the mailbox to

which notification me= ssages are to be sent if there are problems

delivering the messag= e.

= [RFC2821] = allows the reverse-path to be null (see Section 4.5.5 in

SPF verifiers MUS= T check the ""MAIL FROM" identity if a completed<= /p>

RFC 2821).= In this case, there is no e= xplicit sender mailbox, and

"HELO" chec= k has not reached a definitive policy result by applying

the check_host() func= tion to the "MAIL FROM" identity as the

<sender>.

[RFC5321] allows the reverse-path to be nul= l (see Section 4.5.5 in

[RFC5321]). In this case, there is no = explicit sender mailbox, and

such a message can be= assumed to be a notification message from the

such a message can be= assumed to be a notification message from the

mail system itself. = When the reverse-path is null, this document

mail system itself. = When the reverse-path is null, this document

defines the "MAI= L FROM" identity to be the mailbox composed of the

defines the "MAI= L FROM" identity to be the mailbox composed of the

= localpart = "postmaster" and the "HELO" identity (which = may= or may not

local-part= "postmaster" and t= he "HELO" identity (which might or might

have been checked sep= arately before).

not have been checked= separately before).

=

SPF clients MUST = check the "MAIL FROM" identity. SPF clients check

=

the "MAIL FROM&q= uot; identity by applying the check_host() function to the

"MAIL FROM"= identity as the <sender>.

2.3. Publishing Authori= zation

2.3. Publishing Authori= zation

= An SPF-compliant domain MUST publish a valid SPF record as described

An SPF-compliant doma= in MUST have valid= SPF records as de= scribed in

in Section 3. Th= is record authorizes t= he use of the domain name in

Section 3. These= records authorize the= use of the relevant

the "HELO" = and "MAIL FROM" identities by the MTAs it specifies.

names in the "HELO" and "= ;MAIL FROM" identities by the MTAs specified

therein.

= If domain owners choose to publish SPF records, it is RECOM= MENDED

SPF results can b= e used to make both positive (source is authorized)

that they end in "-all", or redir= ect to other records that do, so

and negative (source = is not authorized) determinations. If domain

that a definitive determination of authoriz= ation can be made.

owners choose to publ= ish SPF records and want to support receivers

making negative autho= rization determinations, then they MUST publish

records that end in "-all", or re= direct to other records that do,

otherwise, no definitive determination = of authorization can be made.

Potential issues = and mitigations associated with negative

determinations are di= scussed in Section 9.

= Domain holders may publish SPF records that explicitly authorize no

ADMDs can<= span style=3D" font-family:'monospace';"> publish SPF records that expl= icitly authorize no hosts hosts if mail sho= uld never originate using that domain.

domain names that are neither used in t= he domain part of email

addresses nor expecte= d to originate mail.

= When changing SPF records, care must be taken to ensure that there is

<= /td>

When changing SPF rec= ords, care has to = be taken to ensure that there

a transition period s= o that the old policy remains valid until all

is a transition perio= d so that the old policy remains valid until all

legitimate E-Mail= has been checked.

legitimate email = can reasonably expect to have been checked. This

can be as much as 30 = days.

2.4. Checking Authoriza= tion

2.4. Checking Authoriza= tion

A mail receiver can p= erform a set of SPF checks for each mail message

A mail receiver can p= erform a set of SPF checks for each mail message

it receives. An SPF = check tests the authorization of a client host

it receives. An SPF = check tests the authorization of a client host

to emit mail with a g= iven identity. Typically, such checks are done

to emit mail with a g= iven identity. Typically, such checks are done

by a receiving MTA, b= ut can be performed elsewhere in the mail

by a receiving MTA, b= ut can be performed elsewhere in the mail

processing chain so l= ong as the required information is available and

processing chain so l= ong as the required information is available and

reliable. At least t= he "MAIL FROM" identity MUST be checked, but it

reliable. At least t= he "MAIL FROM" identity MUST be checked, but it

is RECOMMENDED that t= he "HELO" identity also be checked beforehand.

is RECOMMENDED that t= he "HELO" identity also be checked beforehand.

Without explicit appr= oval of the domain owner, checking other

Without explicit appr= oval of the domain owner, checking other

identities against SP= F version 1 records is NOT RECOMMENDED because

identities against SP= F version 1 records is NOT RECOMMENDED because

there are cases that = are known to give incorrect results. For

there are cases that = are known to give incorrect results. For

example, almost all m= ailing lists rewrite the "MAIL FROM" identity

example, almost all m= ailing lists rewrite the "MAIL FROM" identity

= (see Section 9.2), but some do not change any other identities in the

<= /td>

(see Section <= span style=3D" font-family:'monospace'; background-color:#88ffff;">9.2.= 1), but some do not ch= ange any other identities in

message. The scenari= o described in Section 9.3, sub-section 1.2, is

the message. The sce= nario described in Section 9.2.2, sub-section

another example. Doc= uments that define other identities should

1.2, is another examp= le. Documents that define other identities will

define the method for= explicit approval.

have to define the method for explicit appr= oval.

It is possible that m= ail receivers will use the SPF check as part of

It is possible that m= ail receivers will use the SPF check as part of

a larger set of tests= on incoming mail. The results of other tests

a larger set of tests= on incoming mail. The results of other tests

= may influe= nce whether or not a particular SPF check is performed.

might influence whether or not a particu= lar SPF check is performed.

For example, finding = the sending host's IP address on a local white

For example, finding = the sending host's IP address on a local white

= list may c= ause all other tests to be skipped and all mail from that

list might= cause all other tests to be = skipped and all mail from that

host to be accepted.<= /span>

host to be accepted.<= /span>

When a mail receiver = decides to perform an SPF check, it MUST use a

When a mail receiver = decides to perform an SPF check, it MUST use a

correctly-implemented= check_host() function (Section 4) evaluated

correctly-implemented= check_host() function (Section 4) evaluated

with the correct para= meters. Although the test as a whole is

with the correct para= meters. Although the test as a whole is

= optional, once it has been decided to perform a test it = mus= t be

optional, once it has= been decided to perform a test it has to be

performed as specifie= d so that the correct semantics are preserved

performed as specifie= d so that the correct semantics are preserved

between publisher and= receiver.

between publisher and= receiver.

To make the test, the= mail receiver MUST evaluate the check_host()

To make the test, the= mail receiver MUST evaluate the check_host()

function with the arg= uments set as follows:

function with the arg= uments set as follows:

<ip> - the = IP address of the SMTP client that is emitting the

<ip> - the = IP address of the SMTP client that is emitting the

mail, eith= er IPv4 or IPv6.

mail, eith= er IPv4 or IPv6.

<domain> - the = domain portion of the "MAIL FROM" or "HELO" identit= y.

<domain> - the = domain portion of the "MAIL FROM" or "HELO" identit= y.

<sender> - the = "MAIL FROM" or "HELO" identity.

<sender> - the = "MAIL FROM" or "HELO" identity.

= Note that the <domain> argument may not be a well-formed domain name.

Note that the <dom= ain> argument might For example, if the r= everse-path was null, then the EHLO/HELO domain

name. For example, i= f the reverse-path was null, then the EHLO/HELO

is used, with its ass= ociated problems (see Section 2.1). In these

domain is used, with = its associated problems (see Section 2.1). In

cases, check_host() i= s defined in Section 4.3 to return a "None"

these cases, check_ho= st() is defined in Section 4.3 to return a

result.

"none"<= /span> result.

Although invalid, mal= formed, or non-existent domains cause SPF checks

Although invalid, mal= formed, or non-existent domains cause SPF checks

= to return "None" because no SPF record can be found, it has long been

to return "n= one" because no S= PF record can be found, it has long been

the policy of many MT= As to reject E-Mail from such domains,

the policy of many MT= As to reject email= from such domains, especially

especially in the cas= e of invalid "MAIL FROM". In order to prevent

in the case of invali= d "MAIL FROM". prevent one

the circumvention= of SPF records, r= ejecting E-Mail from invalid

method of circumventi= ng of SPF records.=

domains should be con= sidered.

= Implementations must take care to correctly extract the <domain> from

Implementations h= ave to take care to co= rrectly extract the <domain>

the data given with t= he SMTP MAIL FROM command as many MTAs will

from the data given w= ith the SMTP MAIL FROM command as many MTAs will

still accept such thi= ngs as source routes (see Appendix

still accept such thi= ngs as source routes (see Appendix

C), the %-hack (see [= RFC1123]), and bang paths (see [RFC1983]).

C), the %-hack (see [= RFC1123]), and bang paths (see [RFC1983]).

These archaic feature= s have been maliciously used to bypass security

These archaic feature= s have been maliciously used to bypass security

systems.

systems.

2.5. Interpreting the R= esult

2.5. Interpreting the R= esult

This section describe= s how software that performs the authorization

This section describe= s how software that performs the authorization

= should interpret the results of the check_host() function. The

interprets= the results of the check_hos= t() function. The

authorization check S= HOULD be performed during the processing of the

authorization check S= HOULD be performed during the processing of the

SMTP transaction that= sends the mail. This allows errors to be

SMTP transaction that= sends the mail. This allows errors to be

returned directly to = the sending MTA by way of SMTP replies.

returned directly to = the sending MTA by way of SMTP replies.

= Performing the authorization after the SMTP transaction has finished

Performing the author= ization other than using the return-path and

may cause problems, such as the following: = (1) It may be diff= icult to

client address at the= time of the MAIL command during the SMTP

accurately extract th= e required information from potentially

transaction can cause problems, such as= the following: (1) It might

deceptive headers; (2= ) legitimate E-Mail may fail because the

be difficult to accur= ately extract the required information from

sender's policy m= ay have since changed.=

potentially deceptive= headers; (2) legitimate email might fail

because the sender's = policy had since c= hanged.

Generating non-delive= ry notifications to forged identities that have

Generating non-delive= ry notifications to forged identities that have

= failed the authorization check is generally abusive and aga= inst the

failed the authorizat= ion check is a source of backscatter and SHOULD

explicit wishes of the identity owner.

be avoided. [RFC3834= ] section 2 describes backscatter and the

problems it cause= s.

2.5.1. None

<= /td>

2.5.1. None

<= /td>

= A result of "None" means that no records were published by the domain

A result of "= ;none" means = either (a) no <= span style=3D" font-family:'monospace'; background-color:#88ffff;">synt= actically valid DNS do= main

or that no checkable sender domain<= /span> could be determine= d from the given

name was extracte= d from the SMTP session that could be used as the

identity. The checki= ng software cannot ascertain whether or not the

one to be authori= zed, or (b) no TXT= records were retrieved from the

client host is au= thorized.

DNS that appeared= to be intended for use by SPF verifiers.

2.5.2. Neutral

2.5.2. Neutral

= The domain owner has explicitly stated that he cannot or does not

The domain owner has = explicitly stated that they cannot or do want to assert whethe= r or not the IP ad= dress is authorized.

want to assert whethe= r the IP address is authorized or not. A

"Neutral&quo= t; result MUST be trea= ted exactly like the "None" result; the

"neutral&quo= t; result MUST be trea= ted exactly like the "none" result; the

distinction exists on= ly for informational purposes. Treating

distinction exists on= ly for informational purposes. Treating

= "Neutral" more harshly than "None" would discourage domain ow= ners

"neutral&quo= t; more harshly than "none" would discourage domain owners

from testing the use = of SPF records (see Section 9.1).

from testing the use = of SPF records (see Section 9.1).

2.5.3. Pass

<= /td>

2.5.3. Pass

<= /td>

= A "Pa= ss" result means that the client is authorized to inject mail

A "p<= span style=3D" font-family:'monospace';">ass" result means that th= e client is authorized to inject mail

with the given identi= ty. The domain can now, in the sense of

with the given identi= ty. The domain can now, in the sense of

reputation, be consid= ered responsible for sending the message.

reputation, be consid= ered responsible for sending the message.

Further policy checks= can now proceed with confidence in the

Further policy checks= can now proceed with confidence in the

= legitimate use of the identity.

legitimate use of the= identity. This is further discussed in

Section 9.3.1.=

2.5.4. Fail

<= /td>

2.5.4. Fail

<= /td>

= A "Fail" result is an explicit statement that the client is not<= /p>

A "fail"<= /span> result is an explicit = statement that the client is not

authorized to use the= domain in the given identity. The checking

authorized to use the= domain in the given identity. Disposition of

software can choose t= o mark the mail based = on this or to reject the

SPF fail messages is = a matter of local policy. See Section 9.3.2 for

mail outright.=

considerations= on developing local poli= cy.

If the checking softw= are chooses to reject the mail during the SMTP

If the checking softw= are chooses to reject the mail during the SMTP

transaction, then it = SHOULD use an SMTP reply code of 550 (see

transaction, then it = SHOULD use an SMTP reply code of 550 (see

= [RFC2821])= and, if supported, the 5.7.1 Delivery Status Notification

[RFC5321])= and, if supported, the 5.7.1= enhanced status c= ode (see

(DSN) code (see [RFC3464]), in addition to an appropriate rep= ly text.

[RFC3463]), in addition to an appropria= te reply text. The

The check_host() func= tion may return ei= ther a default explanation

check_host() function= will return eithe= r a default explanation string

string or one from th= e domain that published the SPF records (see

or one from the domai= n that published the SPF records (see

Section 6.2). If the= information does not originate with the

Section 6.2). If the= information does not originate with the

= checking software, it should be made clear that the text is provided

checking software, it= is good to make it clear that the text is

by the sender's domai= n. For example:

provided by the sende= r's domain. For example:

550-5.7.1 SPF MAI= L FROM check failed:

550-5.7.1 SPF MAI= L FROM check failed:

550-5.7.1 The dom= ain example.com explains:

550-5.7.1 The dom= ain example.com explains:

550 5.7.1 Please = see http://www.example.com/mailpolicy.html

550 5.7.1 Please = see http://www.example.com/mailpolicy.html

= 2.5.5. SoftFail

If the checking s= oftware chooses not to reject the mail during the

SMTP transaction, the= n it SHOULD add a Received-SPF or

Authentication-Result= s header field (see Section 7) to communicate

this result to downst= ream message processors. While this is true for

all SPF results, it i= s of particular importance for "fail" results

since the message is = explicitly not authorized by the domain owner.

= A "SoftFail" result should be treated as somewhere between a "Fail"<= /p>

2.5.5. Softfail<= /p>

and a "Neutr= al". The domain = believes the host is not authorized but

=

is not willing to mak= e that strong of a= statement. Receiving

A "softfail&qu= ot; result ought t= o be treated as somewh= ere between "fail"

software SHOULD NOT r= eject the message based solely on this result,

and "neutral= "/"none".owner

but MAY subject the m= essage to closer scrutiny than normal.

authorized but is not= willing to make a strong policy statement.

Receiving software SH= OULD NOT reject the message based solely on this

result, but MAY subje= ct the message to closer scrutiny than normal.

The domain owner want= s to discourage the use of this host and thus

The domain owner want= s to discourage the use of this host and thus

= desires limited feedback when a "SoftFail" result occurs. For

desires limited feedb= ack when a "softf example, the recipien= t's Mail User Agent (MUA) could highlight the

example, the recipien= t's Mail User Agent (MUA) could highlight the

= "SoftFail" status, or the receiving MTA could give the sender a<= /p>

"softfail&qu= ot; status, or the rec= eiving MTA could give the sender a

message using = a t= echnique called "greylisting" whereby the MTA can

<= /td>

message using = gre= ylisting, [RFC6647], w= ith a note the first time the

issue an SMTP reply c= ode of 451 (4.3.0 DSN code) with a note the

message is received, = but accept it on a later attempt based on

first time the messag= e is received, but accept it the second time.

receiver policy.

= 2.5.6. TempE= rror

2.5.6. Tempe= rror

= A "TempError" result means that the SPF client encountered a

A "temperror&q= uot; result means the = SPF verifier encou= ntered a transient

transient error while= performing the check. Checking software can

(generally DNS) error while performing = the check. Checking software

choose to accept or t= emporarily reject the message. If the message

can choose to accept = or temporarily reject the message. If the

is rejected during th= e SMTP transaction for this reason, the software

message is rejected d= uring the SMTP transaction for this reason, the

SHOULD use an SMTP re= ply code of 451 and, if supported, the 4.4.3 DSN

software SHOULD use a= n SMTP reply code of 451 and, if supported, the

code.

4.4.3 enhanced st= atus code. These = errors can be caused by problems

in either the sender'= s or receiver's DNS software.

= 2.5.7. PermE= rror

2.5.7. Perme= rror

= A "PermError" result means that the domain's published records could

A "permerror&q= uot; result means the = domain's published records could not

not be correctly inte= rpreted. This signals an error condition that

be correctly interpre= ted. This signals an error condition that

requires manual inter= vention to be resolved, as opposed to the

definitely= requires manual intervention= to be resolved. If the

TempError result.= Be aware that if the= domain owner uses macros

message is rejected d= uring the SMTP transaction for this reason, the

(Section 8), it is po= ssible that this result is due to the checked

software SHOULD u= se an SMTP reply code of 550 and, if supported, the

identities having an = unexpected format.

5.5.2 enhanced status= code. Be aware that = if the domain owner uses

macros (Section 8), i= t is possible that this result is due to the

checked identities ha= ving an unexpected format. It is also possible

that this result is g= enerated by certain SPF clients due to the input

arguments having an u= nexpected format; see Section 4.8.

3. SPF Records

3. SPF Records

= An SPF record is a DNS Resource Record (RR) that declares which hosts

<= /td>

An SPF record is a DN= S record that decl= ares which hosts are, and are

are, and are not, aut= horized to use a domain name for the "HELO" and

not, authorized to us= e a domain name for the "HELO" and "MAIL FROM"

"MAIL FROM"= identities. Loosely, the record partitions all hosts

identities. Loosely,= the record partitions all hosts into permitted

into permitted and no= t-permitted sets (though some hosts might fall

and not-permitted set= s (though some hosts might fall into neither

into neither category= ).

category).

=

= The SPF record is a single string of text. An example record i= s the

The SPF record is a s= ingle string of text. The record format is

following:

=

described below in Se= ction 4. An example r= ecord is the following:

v=3Dspf1 +mx a:col= o.example.com/28 -all

v=3Dspf1 +mx a:col= o.example.com/28 -all

This record has a ver= sion of "spf1" and three directives: "+mx",<= /p>

This record has a ver= sion of "spf1" and three directives: "+mx",<= /p>

"a:colo.example.= com/28" (the + is implied), and "-all".

"a:colo.example.= com/28" (the + is implied), and "-all".

= 3.1. Publishing

Each SPF record is placed in the DNS tree at the host nam= e it

Domain owners wishing= to be SPF complia= nt must publish SPF records

for the hosts that ar= e used in the "MAIL FROM" and "HELO" identities.

The SPF records are placed in the DNS tree = at the host name it

pertains to, not a su= bdomain under it, such as is done with SRV

pertains to, not a su= bdomain under it, such as is done with SRV

= records. This is the same whether the TXT or SPF RR type (= see

records [RFC2782]= .

Section 3.1.1) is use= d.

= The example above in Section 3

The example in th= is section might be pu= blished via these lines in a

a domain zone file:

domain zone file:

example.com. = TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"

<= /td>

example.com. = TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"

<= /td>

smtp-out.example.c= om. TXT "v=3Dspf1 a -all"

smtp-out.example.c= om. TXT "v=3Dspf1 a -all"

= When publishing via TXT records,

Since TXT records have multiple use= s, beware of other TXT= records

published there for o= ther purposes. They may cause problems with

published there for o= ther purposes. They might cause problems with

size limits (see Sect= ion 3.1.4).

size limits (see Sect= ion 3.4) and c= are has to be take= n to ensure only

SPF records are used<= /span> for SPF processing= .

3.1.1. DNS Resource Rec= ord Types

This document defines= a new DNS RR of type SPF, code 99. The format

of this type is ident= ical to the TXT RR [RFC1035]. For either type,

the character content= of the record is encoded as [US-ASCII].

It is recognized that= the current practice (using a TXT record) is

not optimal, but it i= s necessary because there are a number of DNS

server and resolver implementations in = common use that cannot handle

the new RR type. The= two-record-type scheme provides a forward path

to the better sol= ution of using an RR type reserved for this purpose.

= An SPF-compliant domain name SHOULD have SPF records of both RR

ADMDs publishing<= /span> SPF records SHOULD= try to keep the number of

types. A compliant d= omain name MUST have a= record of = at = least one

"include&quo= t; mechanisms and chained "redirect" modifiers to a minimum.

type. If a domain has records of both = types, they MUST have

ADMDs SHOULD also try= to minimize the amount of other DNS information

identical content. F= or example, instead of publishing just one

needed to evaluate a record. Section 4= .6.4 and Section 9= .1.1 provide

record as in Section 3.1 above, it is b= etter to publish:<= /span>

some suggestions on h= ow to achieve this= .

= example.com. IN TXT "v=3Dspf1 +mx a:colo.example.co= m/28 -all"

3.1. DNS Resource Recor= ds

example.com. IN SP= F "v=3Dspf1 +mx a:colo.example.com/28 -all"

= Example RRs in this document are shown with the TXT record = type;

SPF records MUST<= /span> be published as a = DNS TXT (type 16) Resource Record

however, they could be published with the SPF type or with = both

(RR) [RFC1035] only. = The character content of the record is encoded

types.

as [US-ASCII]. Use o= f alternate DNS RR types was supported in SPF's

experimental phase, b= ut has been discontinued. See Appendix A of

[RFC6686] for further= information.

= 3.1.2. Multi= ple DNS Records

3.2. Multiple DNS Recor= ds

A domain name MUST NO= T have multiple records that would cause an

A domain name MUST NO= T have multiple records that would cause an

authorization check t= o select more than one record. See Section 4.5

authorization check t= o select more than one record. See Section 4.5

for the selection rul= es.

for the selection rul= es.

= 3.1.3. Multi= ple Strings in a Single DNS record

3.3. Multiple Strings i= n a Single DNS record

As defined in [RFC103= 5] sections 3.3.14 and 3.3, a single text DNS

As defined in [RFC103= 5] sections 3.3.14 and 3.3, a single text DNS

= record (either TXT or SPF RR types) can be composed of more than one

record can be compose= d of more than one string. If a published

string. If a publish= ed record contains multiple strings, then the

record contains multi= ple character-strings, record MUST be treate= d as if those strings are concatenated together

treated as if those s= trings are concatenated together without adding

without adding spaces= . For example:

spaces. For example:=

IN TXT "v=3Ds= pf1 .... first" "second string..."

IN TXT "v=3Ds= pf1 .... first" "second string..."

MUST be treated as eq= uivalent to

MUST be treated as eq= uivalent to

IN TXT "v=3Ds= pf1 .... firstsecond string..."

IN TXT "v=3Ds= pf1 .... firstsecond string..."

= SPF or TXT= records containing multiple strings are useful in

TXT records containin= g multiple strings are useful in constructing

constructing records = that would exceed the 255-byte maximum length of

records that would ex= ceed the 255-byte maximum length of a character-

a string within a sin= gle TXT or SPF RR = record.

string within a singl= e TXT record.

= 3.1.4. Recor= d Size

3.4. Record Size=

The published SPF rec= ord for a given domain name SHOULD remain small

The published SPF rec= ord for a given domain name SHOULD remain small

enough that the resul= ts of a query for it will fit within 512 octets.

enough that the resul= ts of a query for it will fit within 512 octets.

= This will keep even older DNS implementations from falling over= to

This UDP limit is= defined in [RFC1035] section 2.3.4. This will keep

TCP. Since the answe= r size is dependent on many things outside the

even older DNS implem= entations from falling over to TCP. Since the

scope of this documen= t, it is only possible to give this guideline:

answer size is depend= ent on many things outside the scope of this

If the combined lengt= h of the DNS name and the text of all the

document, it is only = possible to give this guideline: If the combined

records of a given ty= pe (TXT or SPF) is= under 450 characters, then

length of the DNS nam= e and the text of all the records of a given

DNS answers shoul= d fit in UDP packets. = Note that when computing the

type is under 450 cha= racters, then DNS answers fit in UDP

sizes for queries of = the TXT format, one must take into account any

packets. Note that w= hen computing the sizes for queries of the TXT

other TXT records pub= lished at the domain name. Records that are too

format, one has t= o take into account an= y other TXT records published

long to fit in a sing= le UDP packet MAY = be silently ignored by SPF

at the domain name. = Records that are too long to fit in a single UDP

clients.

packet could be silently ignored by SPF= verifiers due to firewall and

other issues that cau= se DNS over TCP to be less reliable than DNS

3.1.5. Wildcard Records=

over UDP.

<= /td>

= Use of wildcard records for publishing is not recommended. = Care must

3.5. Wildcard Records

be taken if wildcard = records are used. If a domain publishes

wildcard MX records, = it may want to publish wildcard declarations,

subject to the same r= equirements and problems. In particular, the

declaration must be r= epeated for any host that has any RR records at

all, and for subdomai= ns thereof. For example, the example given in

[RFC1034], Section 4.= 3.3, could be extended with the following:

= X.COM.= MX 10 A.X.COM

Use of wildcard r= ecords for publishing is discouraged and care has to

X.COM. T= XT "v=3Dspf1 a:A.X.COM -all"

be taken if they are = used. If a zone includes wildcard MX records,

it might want to publ= ish wildcard declarations, subject to the same

requirements and prob= lems. In particular, the declaration MUST be

repeated for any host= that has any RR records at all, and for

subdomains thereof. = Consider the example in [RFC1034], Section

4.3.3. Based on that= , we can do the following:

= *.X.COM.

EXAMPLE.COM.<= /span> MX 10 = A.EXAMPLE.COM

*.X.COM. TXT "v=3Dspf1 = a:A.X.COM -all&quo= t;

EXAMPLE.COM. TXT "v=3D= spf1 a:A.EXAMPLE.COM

= A.X.COM. A 1.2.3.4

*.EXAMPLE.COM= . MX 10 = A.EXAMPLE.COM

A.X.COM. MX 10 = A.X= .COM

*.EXAMPLE.COM. TXT "v=3D= spf1 a:A.EXAMPLE.COM

A.X.COM. TXT "v=3Dspf1 = a:A.X.COM -all&quo= t;

= *.A.X.COM.

A.EXAMPLE.COM= . A 203.0.113.1

*.A.X.COM.= TXT "v=3Dspf1 = a:A.X.COM -all&quo= t;

A.EXAMPLE.COM. MX 10 <= /span>A.EXAMPLE.COM

A.EXAMPLE.COM. TXT "v=3D= spf1 a:A.EXAMPLE.COM

= Notice that SPF records must be repeated twice for every na= me within

*.A.EXAMPLE.C= OM. MX 10 A.EXAMPLE.COM

the domain: once for = the name, and once with a wildcard to cover the

*.A.EXAMPLE.COM. = TXT "v=3Dspf1 a:A.EXAMPLE.COM -all"

tree under the name.<= /span>

= Use of wildcards is discouraged in general as they cause every name

SPF records have = to be listed twice for= every name within the zone:

under the domain<= /span> to exist and queries= against arbitrary names will

once for the name, an= d once with a wildcard to cover the tree under

never return RCODE 3 = (Name Error).

the name, in orde= r to cover all dom= ains in use in outgoing mail.

4. The check_host() Fun= ction

4. The check_host() Fun= ction

=

This description = is not an API (Application Program Interface)

definition, but rathe= r a function description used to illustrate the

algorithm. A complia= nt SPF implementation MUST do something

semantically equivale= nt to this description.

=

The check_host() func= tion fetches SPF records, parses them, and

The check_host() func= tion fetches SPF records, parses them, and

= interprets= them to determine whether a particular host is or is not

evaluates them to determine whether a p= articular host is or is not

permitted to send mai= l with a given identity. Mail receivers that

permitted to send mai= l with a given identity. Mail receivers that

perform this check MU= ST correctly evaluate the check_host() function

perform this check MU= ST correctly evaluate the check_host() function

as described here.

as described here.

Implementations MAY u= se a different algorithm than the canonical

Implementations MAY u= se a different algorithm than the canonical

algorithm defined her= e, so long as the results are the same in all

algorithm defined her= e, so long as the results are the same in all

cases.

cases.

4.1. Arguments

4.1. Arguments

= skipping to c= hange at pa= ge 13, line 12

= skipping to c= hange at pa= ge 17, line 40

informatio= n; initially, the domain portion of the "MAIL

informatio= n; initially, the domain portion of the "MAIL

FROM"= or "HELO" identity.

FROM"= or "HELO" identity.

<sender> - the = "MAIL FROM" or "HELO" identity.

<sender> - the = "MAIL FROM" or "HELO" identity.

The domain portion of= <sender> will usually be the same as the

The domain portion of= <sender> will usually be the same as the

<domain> argume= nt when check_host() is initially evaluated. However,

<domain> argume= nt when check_host() is initially evaluated. However,

this will generally n= ot be true for recursive evaluations (see

this will generally n= ot be true for recursive evaluations (see

Section 5.2 below).

Section 5.2 below).

= Actual implementations of the check_host() function may nee= d

additional arguments.=

=

4.2. Results

=

4.2. Results

=

The function check_ho= st() can return one of several results described

The function check_ho= st() can return one of several results described

in Section 2.5. Base= d on the result, the action to be taken is

in Section 2.5. Base= d on the result, the action to be taken is

determined by the loc= al policies of the receiver.

determined by the loc= al policies of the receiver.

4.3. Initial Processing=

4.3. Initial Processing=

= If the <domain> is malformed (label longer than 63 characters, zero-

If the <domain>= is malformed (e.g. label longer than 63 characters,

length label not at the end, etc.) or is no= t a fully qualified domain

zero-length label not at the end, etc.)= or is not a fully qualified

name, or if the DNS l= ookup returns "domain does not exist" (RCODE 3),

domain name, or if th= e DNS lookup returns "domain does not exist"

check_host() immediat= ely returns the result "None".

(RCODE 3), check_host= () immediately returns the result "none".

Properly formed domai= ns are fully qualified email domains as

described in [RFC5321= ] Section 2.3.5. Internationalized domain names

MUST be encoded as A-= labels, as described in Section 2.3 of

[RFC5890].on 2.3 of [= RFC5890].

= If the <sender> has no localpart, substitute the string "postmaster&quo= t;

If the <sender>= has no local-part, substitute the string "postmaster"

for the localpart= .

for the local-par= t.

4.4. Record Lookup

4.4. Record Lookup

= In accordance with how the records are published (see Section 3= .1

In accordance with ho= w the records are published (see Section 3

above), a DNS query n= eeds to be made for the <domain> name, querying

above), a DNS query n= eeds to be made for the <domain> name, querying

= for either RR type TXT, SPF, or both. If both SPF and TXT RRs are

for type TXT <= span style=3D" font-family:'monospace'; background-color:#88ffff;">only= .

looked up, the querie= s MAY be done in parallel.

If all DNS lookups th= at are made return a server failure (RCODE 2),

If all DNS lookups th= at are made return a server failure (RCODE 2),

or other error (RCODE= other than 0 or 3), or time out, then

or other error (RCODE= other than 0 or 3), or time out, then

= check_host() exits immediately with the result "TempError".<= /p>

check_host() <= span style=3D" font-family:'monospace'; background-color:#88ffff;">term= inates immediately wit= h the result "temperror".

Alternatively, for a = server failure (RCODE 2) result, check_host()

MAY track failures an= d treat multiple failures within 24 hours for

the same domain as &q= uot;permerror".

This alternative is i= ntended to shorten the queue time of messages

that cannot be accept= ed, by returning a permanent negative completion

reply code to the cli= ent, instead of a transient one. [RFC2308]

suggests on an algori= thm for doing such tracking and handling of

server failure codes.=

4.5. Selecting Records<= /span>

4.5. Selecting Records<= /span>

Records begin with a = version section:

Records begin with a = version section:

record =3D = version terms *SP

record =3D = version terms *SP

version =3D = "v=3Dspf1"

version =3D = "v=3Dspf1"

Starting with the set= of records that were returned by the lookup,

Starting with the set= of records that were returned by the lookup,

= record selection proceeds in two steps:

discard records that do not begin with = a version section of exactly

"v=3Dspf1&qu= ot;. Note that the ve= rsion section is terminated either by an

1. Records that do not begin with a version= section of exactly

SP character or the e= nd of the record. A record with a version

"v=3Dspf1= " are discarded. = Note that the version section is

section of "v=3D= spf10" does not match and MUST be discarded.

terminated either = by an SP character or the end of the record. A

record with a vers= ion section of "v=3Dspf10" does not match and must=

be discarded.

=

2. If any records= of type SPF are in the set, then all records of

type TXT are disca= rded.

After the above steps= , there should be exactly one record remaining

and evaluation can pr= oceed. If there are two or more records

remaining, then check= _host() exits immediately with the result of

"PermError"= .

= If no matching records are returned, an SPF client MUST ass= ume that

If the resultant = record set includes no= records, check_host()

the domain makes<= /span> no SPF declarations.= SPF processing MUST stop and

produces the "no= ne" result. If the resultant record set includes

return "None&quo= t;.

more than one record,= check_host() produces the "permerror" result.

4.6. Record Evaluation<= /span>

4.6. Record Evaluation<= /span>

= After one SPF record has been selected, the check_host() function

The check_host() function parses and in= terprets the SPF record to

parses and interprets= it to find a resu= lt for the current test. If

find a result for the= current test. If there are any syntax errors,

there are any syntax = errors, check_host() returns immediately with

check_host() returns = immediately with the result "permerror".

the result "= PermError".

Implementations MAY c= hoose to parse the entire record first and

Implementations MAY c= hoose to parse the entire record first and

= return "PermError" if the record is not syntactically well formed.

return "<= span style=3D" font-family:'monospace'; background-color:#88ffff;">perm= error" if the rec= ord is not syntactically well formed.

However, in all cases= , any syntax errors anywhere in the record MUST

However, in all cases= , any syntax errors anywhere in the record MUST

be detected.

be detected.

4.6.1. Term Evaluation<= /span>

4.6.1. Term Evaluation<= /span>

There are two types o= f terms: mechanisms and modifiers. A record

There are two types o= f terms: mechanisms and modifiers. A record

contains an ordered l= ist of these as specified in the following

contains an ordered l= ist of these as specified in the following

Augmented Backus-Naur= Form (ABNF).

Augmented Backus-Naur= Form (ABNF).

terms =3D = *( 1*SP ( directive / modifier ) )

terms =3D = *( 1*SP ( directive / modifier ) )

directive =3D = [ qualifier ] mechanism

directive =3D = [ qualifier ] mechanism

qualifier =3D = "+" / "-" / "?" / "~"

qualifier =3D = "+" / "-" / "?" / "~"

mechanism =3D = ( all / include

mechanism =3D = ( all / include

/ = A / MX / PTR / IP4 / IP6 / exists )

/ = A / MX / PTR / IP4 / IP6 / exists )

modifier =3D = redirect / explanation / unknown-modifier

modifier =3D = redirect / explanation / unknown-modifier

unknown-modifier =3D = name "=3D" macro-string

unknown-modifier =3D = name "=3D" macro-string

=

; = where name is not any known modifier

name =3D = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." = )

name =3D = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." = )

Most mechanisms allow= a ":" or "/" character after the name.

<= /td>

Most mechanisms allow= a ":" or "/" character after the name.

<= /td>

Modifiers always cont= ain an equals ('=3D') character immediately after

Modifiers always cont= ain an equals ('=3D') character immediately after

= the name, and before any ":" or "/" charact= ers that may be pa= rt of

the name, and before = any ":" or "/" characters that might be part of

the macro-string.

the macro-string.

Terms that do not con= tain any of "=3D", ":", or "/" are mechan= isms, as

Terms that do not con= tain any of "=3D", ":", or "/" are mechan= isms, as

defined in Section 5.=

defined in Section 5.=

= As per the definition of the ABNF notation in [RFC4<= span style=3D" font-family:'monospace';">234], mechanism

As per the definition= of the ABNF notation in [RFC5234], mechanism

and modifier names ar= e case-insensitive.

and modifier names ar= e case-insensitive.

4.6.2. Mechanisms

4.6.2. Mechanisms

Each mechanism is con= sidered in turn from left to right. If there

Each mechanism is con= sidered in turn from left to right. If there

are no more mechanism= s, the result is specified in Section 4.7.

are no more mechanism= s, the result is specified in Section 4.7.

When a mechanism is e= valuated, one of three things can happen: it can

When a mechanism is e= valuated, one of three things can happen: it can

= match, not match, or throw an exception.

match, not match, or = return an exceptio= n.

If it matches, proces= sing ends and the qualifier value is returned as

If it matches, proces= sing ends and the qualifier value is returned as

the result of that re= cord. If it does not match, processing

the result of that re= cord. If it does not match, processing

= continues with the next mechanism. If it throws an exception,

continues with the ne= xt mechanism. If it returns an exception,

mechanism processing = ends and the exception value is returned.

mechanism processing = ends and the exception value is returned.

= The possible qualifiers, and the results they return are as fol= lows:

The possible qualifie= rs, and the results they cause check_host() to

return are as follows= :

= "+" Pass

"+" = pass

"-" = Fail

"-" = fail

"~" = SoftFail

"~" = softfail

"?" = Neutral

"?" = neutral

The qualifier is opti= onal and defaults to "+".

The qualifier is opti= onal and defaults to "+".

= When a mechanism matches and the qualifier is "-", th= en a "Fail&qu= ot;

When a mechanism matc= hes and the qualifier is "-", then a "fail"

result is returned an= d the explanation string is computed as

result is returned an= d the explanation string is computed as

described in Section = 6.2.

described in Section = 6.2.

The specific mechanis= ms are described in Section 5.

The specific mechanis= ms are described in Section 5.

4.6.3. Modifiers=

4.6.3. Modifiers=

= Modifiers are not do not return match or not-match.

Modifiers are not mechanisms. They do = not return match or not-match.

Instead they provide additional informa= tion. Although modifiers do

Instead, they provide additional inform= ation. Although modifiers do

not directly affect t= he evaluation of the record, the "redirect"

not directly affect t= he evaluation of the record, the "redirect"

modifier has an effec= t after all the mechanisms have been evaluated.

modifier has an effec= t after all the mechanisms have been evaluated.

=

4.6.4. DNS Lookup Limit= s

SPF implementations M= UST limit the number of mechanisms and modifiers

("terms") t= hat cause any DNS query to at most 10 during SPF

evaluation. Specific= ally, the "include", "a", "mx", "ptr= ", and

"exists" me= chanisms as well as the "redirect" modifier count against

this limit. The &quo= t;all", "ip4", and "ip6" mechanisms do not cou= nt

against this limit. = If this number is exceeded during a check, a

permerror MUST be ret= urned. The "exp" modifier does not count

against this limit be= cause the DNS lookup to fetch the explanation

string occurs after t= he SPF record evaluation has been completed.

When evaluating the &= quot;mx" and "ptr" mechanisms, or the %{p} macro,=

there MUST be a limit= of no more than 10 MX or PTR RRs looked up and

checked. If more tha= n 10 "mx" or "ptr" records are returned for this

further lookup, a per= merror MUST be returned. This limit is per

mechanism or macro in= the record and in addition to the lookup limits

above.

MTAs or other process= ors SHOULD impose a limit on the maximum amount

of elapsed time to ev= aluate check_host(). Such a limit SHOULD allow

at least 20 seconds. = If such a limit is exceeded, the result of

authorization SHOULD = be "temperror".

=

4.7. Default Result

4.7. Default Result

If none of the mechan= isms match and there is no "redirect" modifier,

If none of the mechan= isms match and there is no "redirect" modifier,

= then the check_host() returns a result of "Neutral", just as if<= /p>

then the check_host()= returns a result of "neutral", just as if

"?all" were= specified as the last directive. If there is a

"?all" were= specified as the last directive. If there is a

"redirect" = modifier, check_host() proceeds as defined in Section 6.1.

"redirect" = modifier, check_host() proceeds as defined in Section 6.1.

Note that records SHO= ULD always use either a "redirect" modifier or

Note that records SHO= ULD always use either a "redirect" modifier or

= an "all" mechanism to explicitly terminate processing= .

an "all" me= chanism to explicitly terminate processing. Although the

latter has default (s= pecifically "?all"), it aids debugging efforts

if it is explicitly i= ncluded.

For example:

For example:

v=3Dspf1 +mx -all<= /span>

v=3Dspf1 +mx -all<= /span>

or

or

v=3Dspf1 +mx redir= ect=3D_spf.example.com

v=3Dspf1 +mx redir= ect=3D_spf.example.com

4.8. Domain Specificati= on

4.8. Domain Specificati= on

= Several of these mechanisms and modifiers have a <domain= -spec>

Several of these mech= anisms and modifiers have a domain-spec section.

section. The = <= ;domain-spec> strin= g is macro expanded (see Section 8).

The domain-spec string is subject t= o macro expansion<= /span> (see Section 8).

The resulting string = is the common presentation form of a fully-

The resulting string = is the common presentation form of a fully-

qualified DNS name: a= series of labels separated by periods. This

qualified DNS name: a= series of labels separated by periods. This

domain is called the = <target-name> in the rest of this document.

domain is called the = <target-name> in the rest of this document.

Note: The result of t= he macro expansion is not subject to any further

Note: The result of t= he macro expansion is not subject to any further

escaping. Hence, thi= s facility cannot produce all characters that

escaping. Hence, thi= s facility cannot produce all characters that

are legal in a DNS la= bel (e.g., the control characters). However,

are legal in a DNS la= bel (e.g., the control characters). However,

this facility is powe= rful enough to express legal host names and

this facility is powe= rful enough to express legal host names and

common utility labels= (such as "_spf") that are used in DNS.

common utility labels= (such as "_spf") that are used in DNS.

For several mechanism= s, the <domain-spec> is optional. If it is not

For several mechanism= s, the <domain-spec> is optional. If it is not

= provided, the <domain> is used as the <target-name>= .

provided, the <dom= ain> is used as the <target-name>. Domain and

<= /td>

domain-spec are synta= ctically identical after macro expansion.

Domain is an input va= lue for check_host() while domain-spec is

computed by check_hos= t().

Note: Historically, t= his document has made no provisions for how to

handle domain-specs, = or macro-expansions thereof, that are

syntactically invalid= per [RFC1035], such as names with empty labels

(e.g., "foo..exa= mple.com") or overlong labels (more than 63

characters). Some im= plementations choose to treat as a no-match

mechanisms, and ignor= e modifiers, with such names, whereas others

return a "permer= ror" exception. The outcome for an unexpected

domain-spec without m= acros might even differ from that for an

unexpected target-nam= e after macro expansion.

5. Mechanism Definition= s

5. Mechanism Definition= s

This section defines = two types of mechanisms.

This section defines = two types of mechanisms.

Basic mechanisms cont= ribute to the language framework. They do not

Basic mechanisms cont= ribute to the language framework. They do not

specify a particular = type of authorization scheme.

specify a particular = type of authorization scheme.

all

all

include

=

include

=

Designated sender mec= hanisms are used to designate a set of <ip>

Designated sender mec= hanisms are used to designate a set of <ip>

addresses as being pe= rmitted or not permitted to use the <domain> for

addresses as being pe= rmitted or not permitted to use the <domain> for

sending mail.<= /p>

sending mail.<= /p>

a

a

mx

mx

= ptr

ptr (deprecate= d)

ip4

ip4

ip6

ip6

exists

<= /td>

exists

<= /td>

The following convent= ions apply to all mechanisms that perform a

The following convent= ions apply to all mechanisms that perform a

comparison between &l= t;ip> and an IP address at any point:

comparison between &l= t;ip> and an IP address at any point:

= If no CIDR-length is given in the directive, then <ip> and the IP

If no CIDR prefix= length is given in th= e directive, then <ip> and the

address are compared = for equality. (Here, CIDR is Classless Inter-

IP address are compar= ed for equality. (Here, CIDR is Classless

Domain Routing.)

Inter-Domain Rout= ing, described in [RFC4632].)

= If a CIDR-length is specified, then only the specified number of

If a CIDR prefix = length is specified, t= hen only the specified number

high-order bits of &l= t;ip> and the IP address are compared for equality.

of high-order bits of= <ip> and the IP address are compared for

equality.

<= /td>

When any mechanism fe= tches host addresses to compare with <ip>, when

When any mechanism fe= tches host addresses to compare with <ip>, when

= <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6<= /span>

<ip> is an IPv4= address, A records are fetched; when <ip> is an IPv6

address, AAAA records= are fetched. Even if the SMTP connection is

address, AAAA records= are fetched. Even if the SMTP connection uses

via IPv6, an IPv4-mapped IPv6 IP address (s= ee [RFC3513], Sect= ion

IPv6, an IPv4-mapped = IPv6 IP address (see [RFC4291], Section 2.5.5)

2.5.5) MUST still be = considered an IPv4 address.

MUST still be conside= red an IPv4 address and MUST be evaluated using

IPv4 mechanisms (i.e.= "ip4" and "a").

= Several mechanisms rely on information fetched from DNS. For t= hese

Several mechanisms re= ly on information fetched from the DNS. For

DNS queries, except w= here noted, if the DNS server returns an error

these DNS queries, ex= cept where noted, if the DNS server returns an

(RCODE other than 0 o= r 3) or the query times out, the mechanism

error (RCODE other th= an 0 or 3) or the query times out, the mechanism

throws the exception "TempErro= r". If the serve= r returns "domain does

stops and<= span style=3D" font-family:'monospace';"> the topmost check_host() = returns "temperror". If the

not exist" (RCOD= E 3), then evaluation of the mechanism continues as

server returns "= domain does not exist" (RCODE 3), then evaluation of

if the server returne= d no error (RCODE 0) and zero answer records.

the mechanism continu= es as if the server returned no error (RCODE 0)

and zero answer recor= ds.

5.1. "all"

5.1. "all"

all =3D = "all"

all =3D = "all"

The "all" m= echanism is a test that always matches. It is used as the

The "all" m= echanism is a test that always matches. It is used as the

rightmost mechanism i= n a record to provide an explicit default.

rightmost mechanism i= n a record to provide an explicit default.

For example:

For example:

v=3Dspf1 a mx -all=

v=3Dspf1 a mx -all=

= Mechanisms after "all" will never be tested. Any &qu= ot;redirect" modifier

Mechanisms after &quo= t;all" will never be tested. Mechanisms listed after

(Section 6.1) = has= no effect when there = is an "all" mechanism.

"all" MUST = be ignored. Any "= ;redirect" modifier (Section 6.1) MUST be

ignored when there is an "all"

5.2. "include"= ;

5.2. "include"= ;

= include= =3D "include" ":" domain-spec

=

include =3D = "include" ":" domain-spec

The "include&quo= t; mechanism triggers a recursive evaluation of

The "include&quo= t; mechanism triggers a recursive evaluation of

= check_host(). The domain-spec is expanded as per Section 8. <= /span>Then

check_host().<= /p>

check_host() is evaluated with the resultin= g string as the <domain>.

=

The <ip> and &l= t;sender> arguments remain the same as in the current

1. The domain-spec is expanded as per = Section 8.

evaluation of check_h= ost().

=

2. Check_host()<= /span> is evaluated with the = resulting string as the

<domain>. = The <ip> and <sender> arguments remain the same as in

the current evalu= ation of check_host().

=

3. The recursive= evaluation returns either match, not match, or an

error. If it mat= ches, then the appropriate result for the

include: mechanis= m is used (e.g. include or +include gives a

"pass" = result and -include gives "fail).

4. If there is no ma= tch, the parent check_host() resumes processing

as per the table = below, with the previous value of <domain>

restored.<= /p>

In hindsight, the nam= e "include" was poorly chosen. Only the

In hindsight, the nam= e "include" was poorly chosen. Only the

evaluated result of t= he referenced SPF record is used, rather than

evaluated result of t= he referenced SPF record is used, rather than

acting as if the refe= renced SPF record was literally included in the

acting as if the refe= renced SPF record was literally included in the

first. For example, = evaluating a "-all" directive in the referenced

first. For example, = evaluating a "-all" directive in the referenced

record does not termi= nate the overall processing and does not

record does not termi= nate the overall processing and does not

= necessarily result in an overall "Fail". (Better names for this=

necessarily result in= an overall "fail". (Better names for this

mechanism would have = been "if-pass", "on-pass", etc.)

mechanism would have = been "if-match", "on-match", etc.)

The "include&quo= t; mechanism makes it possible for one domain to designate

The "include&quo= t; mechanism makes it possible for one domain to designate

multiple administrati= vely-independent domains. For example, a vanity

multiple administrati= vely-independent domains. For example, a vanity

domain "example.= net" might send mail using the servers of

domain "example.= net" might send mail using the servers of

administratively-inde= pendent domains example.com and example.org.

administratively-inde= pendent domains example.com and example.org.

Example.net could say=

Example.net could say=

IN TXT "v=3Ds= pf1 include:example.com include:example.org -all"

IN TXT "v=3Ds= pf1 include:example.com include:example.org -all"

This would direct che= ck_host() to, in effect, check the records of

This would direct che= ck_host() to, in effect, check the records of

= example.com and example.org for a "Pass" result. Only if the host

example.com and examp= le.org for a "p

were not permitted fo= r either of those domains would the result be

were not permitted fo= r either of those domains would the result be

= "Fail= ".

"fail".

= Whether this mechanism matches, does not match, or throws an

Whether this mechanis= m matches, does not match, or returns an

exception depends on = the result of the recursive evaluation of

exception depends on = the result of the recursive evaluation of

check_host():<= /p>

check_host():<= /p>

+--------------------= -------------+---------------------------------+

+--------------------= -------------+---------------------------------+

| A recursive check_h= ost() result | Causes the "include" mechanism |

| A recursive check_h= ost() result | Causes the "include" mechanism |

| of: = | to: |

| of: = | to: |

+--------------------= -------------+---------------------------------+

+--------------------= -------------+---------------------------------+

= | Pass = | match |

<= /td>

| pass | match= |

| = | |

| = | |

= | Fail = | not match |

<= /td>

| fail | not m= atch |

| = | |

| = | |

= | SoftFail= | not match |

<= /td>

| softfail | not m= atch |

| = | |

| = | |

= | Neutral = | not match |

<= /td>

| neutral | not m= atch |

| = | |

| = | |

= | TempError | throw TempError = |

<= /td>

| temperror = | return temperror |

| = | |

| = | |

= | PermError | throw PermError = |

<= /td>

| permerror = | return permerror |

| = | |

| = | |

= | None | throw PermError = |

<= /td>

| none = | return permerror |

+--------------------= -------------+---------------------------------+

+--------------------= -------------+---------------------------------+

The "include&quo= t; mechanism is intended for crossing administrative

The "include&quo= t; mechanism is intended for crossing administrative

= boundaries. Although it is possible to use includes to con= solidate

boundaries. For exam= ple, if example.com and example.org were managed

multiple domains that= share the same set of designated hosts, domains

by the same entity, a= nd if the permitted set of hosts for both

are encouraged to use= redirects where possible, and to minimize the

domains was

number of includes wi= thin a single administrative domain. For

example, if example.c= om and example.org were managed by the same

entity, and if the pe= rmitted set of hosts for both domains was

"mx:example.com&= quot;, it would be possible for example.org to specify

"mx:example.com&= quot;, it would be possible for example.org to specify

"include:example= .com", but it would be preferable to specify

"include:example= .com", but it would be preferable to specify

"redirect=3Dexam= ple.com" or even "mx:example.com".

"redirect=3Dexam= ple.com" or even "mx:example.com".

=

With the "in= clude" mechanism an administratively external set of

hosts can be authoriz= ed, but determination of sender policy is still

a function of the ori= ginal domain's SPF record (as determined by the

"all" mecha= nism in that record). The redirect modifier is more

suitable for consolid= ating both authorizations and policy into a

common set to be shar= ed within an ADMD. Redirect is much more like a

common code element t= o be shared among records in a single ADMD. It

is possible to contro= l both authorized hosts and policy for an

arbitrary number of d= omains from a single record.

=

5.3. "a"

5.3. "a"

This mechanism matche= s if <ip> is one of the <target-name>'s IP

This mechanism matche= s if <ip> is one of the <target-name>'s IP

addresses.

=

addresses.

=

= A = =3D "a" [ ":" domain-spec ] [ dual-cidr= -length ]

a =3D "a" = [ ":" domain-spec ] [ dual-cidr-length ]

An address lookup is = done on the <target-name>. The <ip> is compared

=

An address lookup is = done on the <target-name>. The <ip> is compared

=

to the returned addre= ss(es). If any address matches, the mechanism

to the returned addre= ss(es). If any address matches, the mechanism

matches.

matches.

5.4. "mx"

5.4. "mx"

This mechanism matche= s if <ip> is one of the MX hosts for a domain

This mechanism matche= s if <ip> is one of the MX hosts for a domain

name.

name.

= MX = =3D "mx" [ ":" domain-spec ] [ dual-cidr= -length ]

mx =3D "mx" = [ ":" domain-spec ] [ dual-cidr-length ]

check_host() first pe= rforms an MX lookup on the <target-name>. Then

check_host() first pe= rforms an MX lookup on the <target-name>. Then

it performs an addres= s lookup on each MX name returned. The <ip> is

it performs an addres= s lookup on each MX name returned. The <ip> is

compared to each retu= rned IP address. To prevent Denial of Service

compared to each retu= rned IP address. To prevent Denial of Service

(DoS) attacks, more t= han 10 MX names MUST NOT be looked up during the

(DoS) attacks, more t= han 10 MX names MUST NOT be looked up during the

= evaluation of an "mx" mechanism (see Section 10). If any address

evaluation of an &quo= t;mx" mechanism. If there are more than 10 MX names

matches, the mechanis= m matches.

then permerror is ret= urned and the evaluation terminated (see

Section 4.6.4). If any address matches= , the mechanism matches.

Note regarding implic= it MXs: If the <target-name> has no MX records,

Note regarding implic= it MXs: If the <target-name> has no MX records,

check_host() MUST NOT= pretend the target is its single MX, and MUST

check_host() MUST NOT= pretend the target is its single MX, and MUST

= NOT default to an A lookup on the <target-name> directly.= This

NOT default to an A <= /span>or AAAA lookup on t= he <target-name> directly.

behavior breaks w= ith the legacy "i= mplicit MX" rule. See [RFC2821],

This behavior = div= erges from the legacy = "implicit MX" rule, (See

Section 5. If such b= ehavior is desired, the publisher should specify

[RFC5321], Section 5. If such behavior is = desired, the publisher

an "a" = directive.

will have to specify an "a" <= /span>directive).

= 5.5. "ptr"

5.5. "ptr" (deprecated)

This mechanism tests = whether the DNS reverse-mapping for <ip> exists

This mechanism tests = whether the DNS reverse-mapping for <ip> exists

and correctly points = to a domain name within a particular domain.

and correctly points = to a domain name within a particular domain.

=

This mechanism is dep= recated and SHOULD NOT be used.

= PTR = =3D "ptr" [ ":" domain-spec ]

<= /td>

ptr =3D "ptr" = [ ":" domain-spec ]

= First, the= <ip>'s name is looked up using this procedure: perform a

The <ip>'s name is looked up usin= g this procedure:

DNS reverse-mapping f= or <ip>, looking up the corresponding PTR record

in "in-addr.arpa= ." if the address is an IPv4 one and in "ip6.arpa."

if it is an IPv6 addr= ess. For each record returned, validate the

domain name by lookin= g up its IP address. To prevent DoS attacks,

more than 10 PTR name= s MUST NOT be looked up during the evaluation of

a "ptr" mec= hanism (see Section 10). If <ip> is among the returned IP=

addresses, then that = domain name is validated. In pseudocode:

= sending-domain_names :=3D ptr_lookup(sending-host_IP); if m= ore than 10

1. Perform a DNS= reverse-mapping for <= /span><ip>: Look up the corresponding

sending-domain_names = are found, use at most 10.each name in

PTR record= in "in-addr.arpa.&q= uot; if the addres= s is an IPv4 one and

(sending-domain_n= ames) {

in "ip6.arpa= ." if it is an IPv6 address.

IP_addresses :=3D a= _lookup(name);

if the sending-= domain_IP is one o= f the IP_addresses {

validated-sending= -domain_names +=3D name;

} }

= Check all validated domain names to see if they end in the

2. For each reco= rd returned, validate the domain name by looking up

<target-name> d= omain. If any do, this mechanism matches. If no

its IP addresses.= To prevent DoS attacks, more than 10 PTR names

validated domain name= can be found, or if none of the validated

MUST NOT be looke= d up during the evaluation of a "ptr" mechanism

domain names <= span style=3D" font-family:'monospace'; background-color:#aaccff;">end = in the <target-name= >, this mechanism fails to match.

(see Section 4.6.= 4).

If a DNS error occurs= while doing the PTR RR lookup, then this

mechanism fails to ma= tch. If a DNS error occurs while doing an A RR

3. If <ip> is = among the returned IP addresses, then that domain name

lookup, then that dom= ain name is skipped and the search continues.

is validated.

=

Check all validated d= omain names to see if they either match the

<target-name> d= omain or are a subdomain of the <target-name> domain.

If any do, this mecha= nism matches. If no validated domain name can

be found, or if none = of the validated domain names match or are a

subdomain of the <target-name>, this = mechanism fails to match. If a

DNS error occurs whil= e doing the PTR RR lookup, then this mechanism

fails to match. If a= DNS error occurs while doing an A RR lookup,

then that domain name= is skipped and the search continues.

Pseudocode:

Pseudocode:

=

sending-domain_na= mes :=3D ptr_lookup(sending-host_IP);

if more than 10 sendi= ng-domain_names are found, use at most 10.

for each name in (sen= ding-domain_names) {

IP_addresses :=3D a= _lookup(name);

if the sending-doma= in_IP is one of the IP_addresses {

validated-sending= -domain_names +=3D name;

}

}

=

for each name in (val= idated-sending-domain_names) {

for each name in (val= idated-sending-domain_names) {

if name ends in <= ;domain-spec>, return match.

if name ends in <= ;domain-spec>, return match.

if name is <doma= in-spec>, return match.

if name is <doma= in-spec>, return match.

}

}

return no-match.

return no-match.

= This mechanism matches if the <target-name> is either a of=

This mechanism matche= s if the <target-name> is either a subdomain of

a validated domain na= me or if the <target-name> and a validated

a validated domain na= me or if the <target-name> and a validated

domain name are the s= ame. For example: "mail.example.com" is within

domain name are the s= ame. For example: "mail.example.com" is within

the domain "exam= ple.com", but "mail.bad-example.com" is not.

<= /td>

the domain "exam= ple.com", but "mail.bad-example.com" is not.

<= /td>

= Note: Use of this mechanism is discouraged because it is slow, it is

Note: This mechan= ism has been deprecate= d because it is slow, it is

not as reliable as ot= her mechanisms in cases of DNS errors, and it

not as reliable as ot= her mechanisms in cases of DNS errors, and it

= places a large burden on the arpa name servers. If used, proper PTR

places a large burden= on the .arpa name= servers. If used, proper PTR

records must be in place for the domain= 's hosts and the "ptr"

records MUST be in place for the domain= 's hosts and the "ptr"

mechanism should<= /span> be one of the last mec= hanisms checked.

mechanism SHOULD<= /span> be one of the last mec= hanisms checked. After many

years of SPF deployme= nt experience it has been concluded it is

unnecessary and more = reliable alternatives used instead. It is,

however, still in use= and part of the SPF protocol, so compliant

check_host() implemen= tations MUST support it.

5.6. "ip4" an= d "ip6"

5.6. "ip4" an= d "ip6"

These mechanisms test= whether <ip> is contained within a given IP

These mechanisms test= whether <ip> is contained within a given IP

network.

network.

= IP4 = =3D "ip4" ":" ip4-network [ ip4-cidr-= length ]

ip4 =3D "ip4" = ":" ip4-network [ ip4-cidr-length ]

IP6 =3D "ip6" = ":" ip6-network [ ip6-cidr-length ]

ip6 =3D "ip6" = ":" ip6-network [ ip6-cidr-length ]

ip4-cidr-length =3D = "/" 1*DIGIT

ip4-cidr-length =3D = "/" 1*DIGIT

ip6-cidr-length =3D = "/" 1*DIGIT

ip6-cidr-length =3D = "/" 1*DIGIT

dual-cidr-length =3D = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

dual-cidr-length =3D = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

ip4-network =3D = qnum "." qnum "." qnum "." qnum

ip4-network =3D = qnum "." qnum "." qnum "." qnum

qnum =3D = DIGIT ; 0-9

qnum =3D = DIGIT ; 0-9

/ = %x31-39 DIGIT ; 10-99

/ = %x31-39 DIGIT ; 10-99

/ = "1" 2DIGIT ; 100-199

/ = "1" 2DIGIT ; 100-199

/ = "2" %x30-34 DIGIT ; 200-249

/ = "2" %x30-34 DIGIT ; 200-249

/ = "25" %x30-35 ; 250-255

/ = "25" %x30-35 ; 250-255

; as per con= ventional dotted quad notation. e.g., 192.0.2.0

; as per con= ventional dotted quad notation. e.g., 192.0.2.0

= ip6-network =3D <as per [RFC 3513], section 2.2>

ip6-network =3D = <as per [RFC 4291

; e.g., 2001= :DB8::CD30

; e.g., 2001= :DB8::CD30

= The <ip> is compared to the given network. If CIDR-l= ength high-order

The <ip> is com= pared to the given network. If CIDR prefix length

bits match, the mecha= nism matches.

high-order bits match= , the mechanism matches.

If ip4-cidr-length is= omitted, it is taken to be "/32". If

If ip4-cidr-length is= omitted, it is taken to be "/32". If

ip6-cidr-length is om= itted, it is taken to be "/128". It is not

ip6-cidr-length is om= itted, it is taken to be "/128". It is not

permitted to omit par= ts of the IP address instead of using CIDR

permitted to omit par= ts of the IP address instead of using CIDR

notations. That is, = use 192.0.2.0/24 instead of 192.0.2.

notations. That is, = use 192.0.2.0/24 instead of 192.0.2.

5.7. "exists"=

5.7. "exists"=

This mechanism is use= d to construct an arbitrary domain name that is

This mechanism is use= d to construct an arbitrary domain name that is

used for a DNS A reco= rd query. It allows for complicated schemes

used for a DNS A reco= rd query. It allows for complicated schemes

= skipping to c= hange at pa= ge 22, line 34

= skipping to c= hange at pa= ge 28, line 15

Domains can use this = mechanism to specify arbitrarily complex

Domains can use this = mechanism to specify arbitrarily complex

queries. For example= , suppose example.com publishes the record:

queries. For example= , suppose example.com publishes the record:

v=3Dspf1 exists:%{= ir}.%{l1r+-}._spf.%{d} -all

v=3Dspf1 exists:%{= ir}.%{l1r+-}._spf.%{d} -all

The <target-name&g= t; might expand to

The <target-name&g= t; might expand to

"1.2.0.192.someu= ser._spf.example.com". This makes fine-grained

"1.2.0.192.someu= ser._spf.example.com". This makes fine-grained

decisions possible at= the level of the user and client IP address.

decisions possible at= the level of the user and client IP address.

This mechanism enable= s queries that mimic the style of tests that

This mechanism enable= s queries that mimic the style of tests that

= existing anti-spam DNS blacklists (DNSBL) use.

existing DNS <= span style=3D" font-family:'monospace'; background-color:#88ffff;">whit= e/black lists (DNSxLs) use, as described in

[RFC5782]. The query= will either return NXDOMAIN (no match), any

valid answer (match),= or an error.

6. Modifier Definitions=

6. Modifier Definitions=

Modifiers are name/va= lue pairs that provide additional information.

Modifiers are name/va= lue pairs that provide additional information.

Modifiers always have= an "=3D" separating the name and the value.

Modifiers always have= an "=3D" separating the name and the value.

The modifiers defined= in this document ("redirect" and "exp") MAY=

The modifiers defined= in this document ("redirect" and "exp") MAY=

appear anywhere in th= e record, but SHOULD appear at the end, after

appear anywhere in th= e record, but SHOULD appear at the end, after

all mechanisms. Orde= ring of these two modifiers does not matter.

all mechanisms. Orde= ring of these two modifiers does not matter.

These two modifiers M= UST NOT appear in a record more than once each.

These two modifiers M= UST NOT appear in a record more than once each.

= If they do, then check_host() exits with a result of "= PermError".

If they do, then chec= k_host() exits with a result of "permerror".

Unrecognized modifier= s MUST be ignored no matter where in a record,

Unrecognized modifier= s MUST be ignored no matter where in a record,

or how often. This a= llows implementations of this document to

or how often. This a= llows implementations of this document to

gracefully handle rec= ords with modifiers that are defined in other

gracefully handle rec= ords with modifiers that are defined in other

specifications.

specifications.

6.1. redirect: Redirect= ed Query

6.1. redirect: Redirect= ed Query

= If all mechanisms fail to match, and a "redirect" modifier is

The redirect modi= fier is intended for consolidating both

present, then pro= cessing proceeds as follows:

authorizations= and policy into a common set to be shared = within a

single ADMD. Redirec= t is like a common= code element to be shared

among records in a si= ngle ADMD. It is possible to control both

authorized hosts and = policy for an arbitrary number of domains from a

single record.=

redirect =3D = "redirect" "=3D" domain-spec

redirect =3D = "redirect" "=3D" domain-spec

=

If all mechanisms= fail to match, and a "redirect" modifier is

present, then process= ing proceeds as follows:

=

The domain-spec porti= on of the redirect section is expanded as per

The domain-spec porti= on of the redirect section is expanded as per

the macro rules in Se= ction 8. Then check_host() is evaluated with

the macro rules in Se= ction 8. Then check_host() is evaluated with

the resulting string = as the <domain>. The <ip> and <sender>

the resulting string = as the <domain>. The <ip> and <sender>

= arguments remain the same as current evaluation of check_host()= .

arguments remain the = same as in the cur= rent evaluation of

check_host().<= /p>

The result of this ne= w evaluation of check_host() is then considered

The result of this ne= w evaluation of check_host() is then considered

the result of the cur= rent evaluation with the exception that if no

the result of the cur= rent evaluation with the exception that if no

SPF record is found, = or if the target-name is malformed, the result

SPF record is found, = or if the target-name is malformed, the result

= is a "PermError" rather than "None".

is a "permer= ror" rather than "none".

= Note that the newly-queried domain may itself specify redirect

Note that the newly-q= ueried domain can = itself specify redirect

processing.

processing.

This facility is inte= nded for use by organizations that wish to apply

This facility is inte= nded for use by organizations that wish to apply

the same record to mu= ltiple domains. For example:

the same record to mu= ltiple domains. For example:

la.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

la.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

ny.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

ny.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

sf.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

sf.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

_spf.example.com. TXT= "v=3Dspf1 mx:example.com -all"

_spf.example.com. TXT= "v=3Dspf1 mx:example.com -all"

In this example, mail= from any of the three domains is described by

In this example, mail= from any of the three domains is described by

the same record. Thi= s can be an administrative advantage.

the same record. Thi= s can be an administrative advantage.

Note: In general, the= domain "A" cannot reliably use a redirect to

Note: In general, the= domain "A" cannot reliably use a redirect to

another domain "= B" not under the same administrative control. Since

another domain "= B" not under the same administrative control. Since

the <sender> st= ays the same, there is no guarantee that the record at

the <sender> st= ays the same, there is no guarantee that the record at

domain "B" = will correctly work for mailboxes in domain "A",

domain "B" = will correctly work for mailboxes in domain "A",

= especially if domain "B" uses mechanisms involving An

especially if domain = "B" uses mechanisms involving local-parts. An

"include" d= irective may be mo= re appropriate.

"include" d= irective is generally be more appropriate.

For clarity, it is RE= COMMENDED that any "redirect" modifier appear as

For clarity, it is RE= COMMENDED that any "redirect" modifier appear as

the very last term in= a record.

the very last term in= a record.

6.2. exp: Explanation

6.2. exp: Explanation

explanation =3D = "exp" "=3D" domain-spec

explanation =3D = "exp" "=3D" domain-spec

= If check_host() results in a "Fail" due to a mechanism match (such as

If check_host() resul= ts in a "fail= " due to a mechanism match (such as

"-all"), an= d the "exp" modifier is present, then the explanation<= /p>

"-all"), an= d the "exp" modifier is present, then the explanation<= /p>

string returned is co= mputed as described below. If no "exp" modifier

string returned is co= mputed as described below. If no "exp" modifier

is present, then eith= er a default explanation string or an empty

is present, then eith= er a default explanation string or an empty

= explanation string may be returned.

explanation string be returned.

= The <domain-spec> is macro expanded (see Section 8) and becomes the<= /p>

The domain-spec is macro expanded (see = Section 8) and becomes the

<target-name>. = The DNS TXT record for the <target-name> is fetched.

<= /td>

<target-name>. = The DNS TXT record for the <target-name> is fetched.

<= /td>

= If <domain-spec> is empty, or there are any DNS processing errors

If there are any DNS = processing errors (any RCODE other than 0), or

(any RCODE other than= 0), or if no records are returned, or if more

if no records are ret= urned, or if more than one record is returned,

than one record is re= turned, or if there are syntax errors in the

or if there are synta= x errors in the explanation string, then proceed

explanation string, t= hen proceed as if no exp modifier was given.

as if no exp modifier= was given.

The fetched TXT recor= d's strings are concatenated with no spaces, and

The fetched TXT recor= d's strings are concatenated with no spaces, and

= then treated as an <explain-string>, which is macro-expanded. This<= /p>

then treated as an , whic= h is macro-expanded. This

final result is the e= xplanation string. Implementations MAY limit

final result is the e= xplanation string. Implementations MAY limit

the length of the res= ulting explanation string to allow for other

the length of the res= ulting explanation string to allow for other

protocol constraints = and/or reasonable processing limits. Since the

protocol constraints = and/or reasonable processing limits. Since the

= explanation string is intended for an SMTP response and [RFC2821]

explanation string is= intended for an SMTP response and [RFC5321]

Section 2.4 says that= responses are in [US-ASCII], the explanation

Section 2.4 says that= responses are in [US-ASCII], the explanation

= string is also

string MUST be limited to US-ASCII.

Software evaluating c= heck_host() can use this string to communicate

Software evaluating c= heck_host() can use this string to communicate

information from the = publishing domain in the form of a short message

information from the = publishing domain in the form of a short message

or URL. Software SHO= ULD make it clear that the explanation string

or URL. Software SHO= ULD make it clear that the explanation string

comes from a third pa= rty. For example, it can prepend the macro

comes from a third pa= rty. For example, it can prepend the macro

= string "%{o} explains: " to the explanation, such as = shown in Section

string "%{o} exp= lains: " to the explanation, such as shown in

2.5.4.

Section 2.5.4.=

Suppose example.com h= as this record:

Suppose example.com h= as this record:

v=3Dspf1 mx -all e= xp=3Dexplain._spf.%{d}

v=3Dspf1 mx -all e= xp=3Dexplain._spf.%{d}

Here are some example= s of possible explanation TXT records at

Here are some example= s of possible explanation TXT records at

explain._spf.example.= com:

explain._spf.example.= com:

"Mail from ex= ample.com should only be sent by its own servers."

"Mail from ex= ample.com should only be sent by its own servers."

= -- a simple, constant message

-- = a simple, constant message

"%{i} is not = one of %{d}'s designated mail servers."

"%{i} is not = one of %{d}'s designated mail servers."

= -- a message with a little more information, including th= e IP

-- a message w= ith a little more information, including the IP

address that= failed the check

address tha= t failed the check

"See http://%= {d}/why.html?s=3D%{S}&i=3D%{I}"

"See http://%= {d}/why.html?s=3D%{S}&i=3D%{I}"

= -- a complicated example that constructs a URL with the

-- a complicat= ed example that constructs a URL with the

arguments to= check_host() so that a web page can be

arguments t= o check_host() so that a web page can be

generated wi= th detailed, custom instructions

generated w= ith detailed, custom instructions

Note: During recursio= n into an "include" mechanism, an exp=3D modifier

<= /td>

Note: During recursio= n into an "include" mechanism, an exp=3D modifier

<= /td>

from the <target-n= ame> MUST NOT be used. In contrast, when executing

from the <target-n= ame> MUST NOT be used. In contrast, when executing

a "redirect"= ; modifier, an exp=3D modifier from the original domain MUST

=

a "redirect"= ; modifier, an exp=3D modifier from the original domain MUST

=

NOT be used.

NOT be used.

= 7. The Received-SPF Header Field

7. Recording The Res= ult

= It is RECO= MMENDED that SMTP receivers record the result of SPF

To provide downst= ream agents, such as MUAs, with the information they

processing in the mes= sage header. If an SMTP receiver chooses to do

might need in terms o= f evaluating or representing the apparent safety

so, it SHOULD use the "Received-SP= F" header field d= efined here for

of the message conten= t, it is RECOMMENDED t= hat SMTP receivers record

each identity tha= t was checked. Th= is information is = intended for the

the result of SPF pro= cessing in the message header. For operators

recipient. (Informat= ion intended for t= he sender is described in

that choose to record SPF results in the header of the me= ssage for

Section 6.2, Explanat= ion.)

processing by interna= l filters or MUAs, two methods are presented.

Section 7.1 defines t= he Received-SPF field, which is the results

field originally<= /span> defined for SPF us= e. Section 7.2 discusses

Authentication-Result= s [RFC5451] which was = specified more recently

and is designed for use by SPF and other authentication m= ethods.

= The Received-SPF header field is a trace field (see [RFC282= 2] Section

<= /td>

Both are in commo= n use, and hence both are included here. However,

it is important to no= te that they were designed to serve slightly

different purposes. = Received-SPF is intended to include enough

forensic information = to enable reconstruction of the SPF evaluation

of the message, while= Authentication-Results is designed only to

relay the result itse= lf and related output details of likely use to

end users (e.g., what= property of the message was actually

authenticated and wha= t it contained), leaving forensic work to the

purview of system log= s and the Received field contents. Also,

Received-SPF relies o= n compliance of agents within the receiving ADMD

to adhere to the head= er field ordering rules of [RFC5321] and

[RFC5322], while Auth= entication-Results includes some provisions to

protect against non-c= ompliant implementations.

An operator could cho= ose to use both to serve different downstream

agents. In such case= s, care needs to be taken to ensure both fields

are conveying the sam= e details, or unexpected results can occur.

7.1. The Received-SPF H= eader Field

=

The Received-SPF head= er field is a trace field (see [RFC5322] Section

3.6.7) and SHOULD be = prepended to the existing header, above the

3.6.7) and SHOULD be = prepended to the existing header, above the

Received: field that = is generated by the SMTP receiver. It MUST

Received: field that = is generated by the SMTP receiver. It MUST

appear above all othe= r Received-SPF fields in the message. The

appear above all othe= r Received-SPF fields in the message. The

header field has the = following format:

header field has the = following format:

header-field =3D = "Received-SPF:" [CFWS] result FWS [comment FWS]

header-field =3D = "Received-SPF:" [CFWS] result FWS [comment FWS]

[ = key-value-list ] CRLF

[ = key-value-list ] CRLF

= result =3D "Pass" / "Fail" / "SoftFail" / "Neutral" /

result =3D = "pass" /= "fail" = / "softfail""neutral" /

/ <= /span>"TempError""PermError"

/ <= /span>"temperror""permerror"

key-value-list =3D = key-value-pair *( ";" [CFWS] key-value-pair )

key-value-list =3D = key-value-pair *( ";" [CFWS] key-value-pair )

[&= quot;;"]

[&= quot;;"]

key-value-pair =3D = key [CFWS] "=3D" ( dot-atom / quoted-string )

key-value-pair =3D = key [CFWS] "=3D" ( dot-atom / quoted-string )

key =3D = "client-ip" / "envelope-from" / "helo" /<= /span>

key =3D = "client-ip" / "envelope-from" / "helo" /<= /span>

&q= uot;problem" / "receiver" / "identity" /

&q= uot;problem" / "receiver" / "identity" /

= mechanism / "x-" name / name

m= echanism / name

identity =3D = "mailfrom" ; for the "MAIL FROM" identity<= /p>

identity =3D = "mailfrom" ; for the "MAIL FROM" identity<= /p>

/ = "helo" ; for the "HELO" identity

/ = "helo" ; for the "HELO" identity

/ = name ; other identities

/ = name ; other identities

= dot-atom =3D <unquoted word as per [RFC2822]>=

dot-atom =3D = <unquoted word as per [RFC5322]>

quoted-string =3D = <quoted string as per [RFC2822]>

quoted-string =3D = <quoted string as per [RFC5322]>

comment =3D = <comment string as per

comment =3D = <comment string as per CFWS =3D = <comment or folding white space as per [RFC2822]>

<= /td>

CFWS =3D = <comment or folding white space as per [RFC5322]>

<= /td>

FWS =3D = <folding white space as per [RFC2822]>

FWS =3D = <folding white space as per [RFC5322]>

CRLF =3D = <standard end-of-line token as per [RFC2822]>

CRLF =3D = <standard end-of-line token as per [RFC2532]>

= The header field SHOULD include a "(...)" style &= lt;comment> after t= he

The header field SHOU= LD include a "(...)" style comment after the

result, conveying sup= porting information for the result, such as

result, conveying sup= porting information for the result, such as

<ip>, <sende= r>, and <domain>.

<ip>, <sende= r>, and <domain>.

The following key-val= ue pairs are designed for later machine parsing.

The following key-val= ue pairs are designed for later machine parsing.

= SPF client= s SHOULD give enough information so that the SPF results

SPF verifiers SHOULD give enough inform= ation so that the SPF results

can be verified. Tha= t is, at least "client-ip", "helo", and, if the

can be verified. Tha= t is, at least "client-ip", "helo", and, if the

"MAIL FROM"= identity was checked, "envelope-from".

"MAIL FROM"= identity was checked, "envelope-from".

client-ip the IP= address of the SMTP client

client-ip the IP= address of the SMTP client

envelope-from the en= velope sender mailbox

envelope-from the en= velope sender mailbox

helo the ho= st name given in the HELO or EHLO command

helo the ho= st name given in the HELO or EHLO command

mechanism the me= chanism that matched (if no mechanisms matched,

mechanism the me= chanism that matched (if no mechanisms matched,

substi= tute the word "default")

substi= tute the word "default")

problem if an = error was returned, details about the error

problem if an = error was returned, details about the error

= =

receiver the ho= st name of the SPF verifier

receiver the ho= st name of the SPF client

identity the id= entity that was checked; see the <identity> ABNF

identity the id= entity that was checked; see the <identity> ABNF

rule

rule

= Other keys mayclients. Until a new key name

Other keys MAY be defined by SPF ve= rifiers.

becomes widely accept= ed, new key names should start with "x-".

= SPF clients MUST make sure that the Received-SPF header field does

SPF verifiers MUST make sure that the R= eceived-SPF header field does

not contain invalid c= haracters, is not excessively long, and does not

not contain invalid c= haracters, is not excessively long (See

contain malicious dat= a that has been provided by the sender.

[RFC5322] Section 2.1= .1), and does not cont= ain malicious data that

has been provided by = the sender.

= Examples of various header styles that could be generated are t= he

Examples of various h= eader field styles= that could be generated are

following:

=

the following:=

= Received-SPF: Pass (mybox.example.org: domain of

Received-SPF: = pass (mybox.example.org: = domain of

myname@example.com d= esignates 192.0.2.1 as permitted sender)

myname@example.com d= esignates 192.0.2.1 as permitted sender)

receiver=3Dmybox.= example.org; client-ip=3D192.0.2.1;

receiver=3Dmybox.= example.org; client-ip=3D192.0.2.1;

= envelope-from=3D<myname@example.com>; helo=3Dfoo.example.com;

envelope-from=3D<= /span>"myname@example.com"; helo=3Dfoo.example.com;

= Received-SPF: Fail (mybox.example.org: domain of

Received-SPF: = fail (mybox.example.org: = domain of

myn= ame@example.com does not designate

myn= ame@example.com does not designate

192= .0.2.1 as permitted sender)

192= .0.2.1 as permitted sender)

ide= ntity=3Dmailfrom; client-ip=3D192.0.2.1;

ide= ntity=3Dmailfrom; client-ip=3D192.0.2.1;

=

envelope-from=3D"myname@example.com";

7.2. SPF Results in the= Authentication-Results Header Field

As mentioned in Secti= on 7, the Authentication-Results header field is

designed to communica= te lists of tests a border MTA did and their

results. The specifi= ed elements of the field provide less

information than the = SPF-Received field:

Authentication-Result= s: myhost.example.org; spf=3Dpass

smtp.mailfrom=3Dexa= mple.net

Received-SPF: pass (m= yhost.example.org: domain of

myname@example.com d= esignates 192.0.2.1 as permitted sender)

receiver=3Dmybox.= example.org; client-ip=3D192.0.2.1;

envelope-from=3D&= quot;myname@example.com"; helo=3Dfoo.example.com;

It is, however, possi= ble to add CFWS in the "reason" part of an

Authentication-Result= s header field and provide the equivalent

information, if desir= ed.

As an example, an exp= anded Authentication-Results header field might

look like (for a &quo= t;MAIL FROM" check in this example):

Authentication-Result= s: myhost.example.org; spf=3Dpass

reason=3D"clie= nt-ip=3D192.0.2.1; smtp.helo=3Dfoo.example.com"

smtp.mailfrom=3Duse= r@example.net

8. Macros

8. Macros

8.1. Macro Definitions<= /span>

8.1. Macro Definitions<= /span>

= Many mechanisms and modifiers perform macro expansion on pa= rt of the

Many mechanisms and m= odifiers perform macro expansion on a term.

term.

domain-spec =3D = macro-string domain-end

domain-spec =3D = macro-string domain-end

domain-end =3D = ( "." toplabel [ "." ] ) / macro-expand

<= /td>

domain-end =3D = ( "." toplabel [ "." ] ) / macro-expand

<= /td>

toplabel =3D = ( *alphanum ALPHA *alphanum ) /

toplabel =3D = ( *alphanum ALPHA *alphanum ) /

( = 1*alphanum "-" *( alphanum / "-" ) alphanum )

( = 1*alphanum "-" *( alphanum / "-" ) alphanum )

; = LDH rule plus additional TLD restrictions

; = LDH rule plus additional TLD restrictions

= ; (see [RFC3696], Section 2)

; = (see [RFC3696], Section 2 for background)

alphanum =3D = ALPHA / DIGIT

alphanum =3D = ALPHA / DIGIT

explain-string =3D = *( macro-string / SP )

explain-string =3D = *( macro-string / SP )

macro-string =3D = *( macro-expand / macro-literal )

macro-string =3D = *( macro-expand / macro-literal )

macro-expand =3D = ( "%{" macro-letter transformers *delimiter "}" )

macro-expand =3D = ( "%{" macro-letter transformers *delimiter "}" )

/ = "%%" / "%_" / "%-"

/ = "%%" / "%_" / "%-"

macro-literal =3D = %x21-24 / %x26-7E

macro-literal =3D = %x21-24 / %x26-7E

; = visible characters except "%"

; = visible characters except "%"

macro-letter =3D = "s" / "l" / "o" / "d" / "i= " / "p" / "h" /

macro-letter =3D = "s" / "l" / "o" / "d" / "i= " / "p" / "h" /

= "c" / "r" / "t"= ;

&q= uot;c" / "r" / "t" / "v"<= /p>

transformers =3D = *DIGIT [ "r" ]

transformers =3D = *DIGIT [ "r" ]

delimiter =3D = "." / "-" / "+" / "," / "/= " / "_" / "=3D"

delimiter =3D = "." / "-" / "+" / "," / "/= " / "_" / "=3D"

A literal "%&quo= t; is expressed by "%%".

A literal "%&quo= t; is expressed by "%%".

"%_" exp= ands to a single " " space.

"%_" exp= ands to a single " " space.

"%-" exp= ands to a URL-encoded space, viz., "%20".

"%-" exp= ands to a URL-encoded space, viz., "%20".

The following macro l= etters are expanded in term arguments:

The following macro l= etters are expanded in term arguments:

s =3D <sender&g= t;

s =3D <sender&g= t;

l =3D local-part o= f <sender>

l =3D local-part o= f <sender>

o =3D domain of &l= t;sender>

o =3D domain of &l= t;sender>

d =3D <domain&g= t;

d =3D <domain&g= t;

i =3D <ip>

i =3D <ip>

= p =3D the validated domain name of <ip>

p =3D the validate= d domain name of <ip> (deprecated)

v =3D the string &= quot;in-addr" if <ip> is ipv4, or "ip6" if <ip&= gt; is ipv6

v =3D the string &= quot;in-addr" if <ip> is ipv4, or "ip6" if <ip&= gt; is ipv6

h =3D HELO/EHLO do= main

h =3D HELO/EHLO do= main

The following macro l= etters are allowed only in "exp" text:

The following macro l= etters are allowed only in "exp" text:

c =3D SMTP client = IP (easily readable format)

c =3D SMTP client = IP (easily readable format)

r =3D domain name = of host performing the check

r =3D domain name = of host performing the check

t =3D current time= stamp

t =3D current time= stamp

A '%' character not f= ollowed by a '{', '%', '-', or '_' character is

A '%' character not f= ollowed by a '{', '%', '-', or '_' character is

= skipping to c= hange at pa= ge 28, line 13

= skipping to c= hange at pa= ge 37, line 7

h =3D HELO/EHLO do= main

h =3D HELO/EHLO do= main

The following macro l= etters are allowed only in "exp" text:

The following macro l= etters are allowed only in "exp" text:

c =3D SMTP client = IP (easily readable format)

c =3D SMTP client = IP (easily readable format)

r =3D domain name = of host performing the check

r =3D domain name = of host performing the check

t =3D current time= stamp

t =3D current time= stamp

A '%' character not f= ollowed by a '{', '%', '-', or '_' character is

A '%' character not f= ollowed by a '{', '%', '-', or '_' character is

a syntax error. So

a syntax error. So

= =

-exists:%(ir).sbl.= spamhaus.example.org

-exists:%(ir).sbl.= spamhaus.example.org

= =

is incorrect and will= cause check_host() to yield a "permerror".

is incorrect and will= cause check_host() to return a "PermError".

Instead, say

Instead, say

= =

-exists:%{ir}.sbl.= spamhaus.example.org

-exists:%{ir}.sbl.= spamhaus.example.org

Optional transformers= are the following:

Optional transformers= are the following:

*DIGIT =3D zero or= more digits

*DIGIT =3D zero or= more digits

'r' =3D reverse= value, splitting on dots by default

'r' =3D reverse= value, splitting on dots by default

If transformers or de= limiters are provided, the replacement value for

If transformers or de= limiters are provided, the replacement value for

a macro letter is spl= it into parts. After performing any reversal

a macro letter is spl= it into parts. After performing any reversal

operation and/or remo= val of left-hand parts, the parts are rejoined

operation and/or remo= val of left-hand parts, the parts are rejoined

= skipping to c= hange at pa= ge 28, line 32

= skipping to c= hange at pa= ge 37, line 23

*DIGIT =3D zero or= more digits

*DIGIT =3D zero or= more digits

'r' =3D reverse= value, splitting on dots by default

'r' =3D reverse= value, splitting on dots by default

If transformers or de= limiters are provided, the replacement value for

If transformers or de= limiters are provided, the replacement value for

a macro letter is spl= it into parts. After performing any reversal

a macro letter is spl= it into parts. After performing any reversal

operation and/or remo= val of left-hand parts, the parts are rejoined

operation and/or remo= val of left-hand parts, the parts are rejoined

using "." a= nd not the original splitting characters.

using "." a= nd not the original splitting characters.

By default, strings a= re split on "." (dots). Note that no special

By default, strings a= re split on "." (dots). Note that no special

= treatment is given to leading, trailing, or consecutive = del= imiters,

treatment is given to= leading, trailing, or consecutive delimiters in

and so the list of pa= rts may contain em= pty strings. Older

input strings,= and so the list of parts might contain empty s= trings.

implementations of SP= F prohibit trailing dots in domain names, so

Some older= implementations of SPF prohi= bit trailing dots in domain

trailing dots = sho= uld not be published b= y domain owners, although they

names, so trailing do= ts SHOULD NOT be p= ublished by domain owners,

must be accepted by implementations con= forming to this document.

although they = MUS= T be accepted by imple= mentations conforming to this

Macros may= specify delimiter characters= that are used instead of ".".

document. Macros can specify delimiter= characters that are used

instead of ".&qu= ot;.

The 'r' transformer i= ndicates a reversal operation: if the client IP

The 'r' transformer i= ndicates a reversal operation: if the client IP

address were 192.0.2.= 1, the macro %{i} would expand to "192.0.2.1"

address were 192.0.2.= 1, the macro %{i} would expand to "192.0.2.1"

and the macro %{ir} w= ould expand to "1.2.0.192".

and the macro %{ir} w= ould expand to "1.2.0.192".

The DIGIT transformer= indicates the number of right-hand parts to

The DIGIT transformer= indicates the number of right-hand parts to

use, after optional r= eversal. If a DIGIT is specified, the value

use, after optional r= eversal. If a DIGIT is specified, the value

MUST be nonzero. If = no DIGITs are specified, or if the value

MUST be nonzero. If = no DIGITs are specified, or if the value

specifies more parts = than are available, all the available parts are

specifies more parts = than are available, all the available parts are

used. If the DIGIT w= as 5, and only 3 parts were available, the macro

used. If the DIGIT w= as 5, and only 3 parts were available, the macro

interpreter would pre= tend the DIGIT was 3. Implementations MUST

interpreter would pre= tend the DIGIT was 3. Implementations MUST

support at least a va= lue of 128, as that is the maximum number of

support at least a va= lue of 128, as that is the maximum number of

labels in a domain na= me.

labels in a domain na= me.

= The "s" macro expands to the <sender> argument.= It is an E-Mail

The "s" mac= ro expands to the <sender> argument. It is an email

address with a lo= calpart, an "@&qu= ot; character, and a domain. The "l"

address with a lo= cal-part, an "@&q= uot; character, and a domain. The "l"

macro expands to just= the localpart. T= he "o" macro expands to just

macro expands to just= the local-part. = The "o" macro expands to just

the domain part. Not= e that these values remain the same during

the domain part. Not= e that these values remain the same during

recursive and chained= evaluations due to "include" and/or "redirect".

recursive and chained= evaluations due to "include" and/or "redirect".

= Note also that if the original <sender> had no localp= art, the

Note also that if the= original <sender> had no local-part, the local-

localpart<= span style=3D" font-family:'monospace';"> was set to "postmaster&q= uot; in initial processing (see Section

part was set to "postmaster" in i= nitial processing (see Section 4.3).

4.3).

For IPv4 addresses, b= oth the "i" and "c" macros expand to the

=

For IPv4 addresses, b= oth the "i" and "c" macros expand to the

=

standard dotted-quad = format.

standard dotted-quad = format.

For IPv6 addresses, t= he "i" macro expands to a dot-format address; it

For IPv6 addresses, t= he "i" macro expands to a dot-format address; it

= is intended for use in %{ir}. The "c" macro <= span style=3D" font-family:'monospace'; background-color:#aaccff;">may<= /span> expand to any of the

is intended for use i= n %{ir}. The "c" macro can expand to any of the

hexadecimal colon-for= mat addresses specified in [RFC3513], Section

hexadecimal colon-for= mat addresses specified in [RFC4291], Section

2.2. It is intended = for humans to read.

2.2. It is intended = for humans to read.

The "p" mac= ro expands to the validated domain name of <ip>. The

<= /td>

The "p" mac= ro expands to the validated domain name of <ip>. The

<= /td>

= procedure for finding the validated domain name is defined in S= ection

procedure for finding= the validated domain name is defined in

5.5. If the <doma= in> is present in the list of validated domains, it

Section 5.5. If the = <domain> is present in the list of validated

SHOULD be used. Othe= rwise, if a subdomain of the <domain> is

domains, it SHOULD be= used. Otherwise, if a subdomain of the

present, it SHOULD be= used. Otherwise, any name from the list may be

<domain> is pre= sent, it SHOULD be used. Otherwise, any name from the

used. If there are n= o validated domain names or if a DNS error

list can be used. If there are no vali= dated domain names or if a DNS

occurs, the string &q= uot;unknown" is used.

error occurs, the str= ing "unknown" is used. This macro is deprecated

and SHOULD NOT be used.

The "r" mac= ro expands to the name of the receiving MTA. This SHOULD

The "r" mac= ro expands to the name of the receiving MTA. This SHOULD

be a fully qualified = domain name, but if one does not exist (as when

be a fully qualified = domain name, but if one does not exist (as when

the checking is done = by a MUA) or if policy restrictions dictate

the checking is done = by a MUA) or if policy restrictions dictate

otherwise, the word &= quot;unknown" SHOULD be substituted. The domain name

otherwise, the word &= quot;unknown" SHOULD be substituted. The domain name

= may be dif= ferent from the name found in the MX record that the client

<= /td>

can be different from the name found in= the MX record that the client

MTA used to locate th= e receiving MTA.

MTA used to locate th= e receiving MTA.

The "t" mac= ro expands to the decimal representation of the

The "t" mac= ro expands to the decimal representation of the

approximate number of= seconds since the Epoch (Midnight, January 1,

approximate number of= seconds since the Epoch (Midnight, January 1,

= 1970, UTC). This is the same value as is returned by the POSIX

1970, UTC) at the= time of the evaluation.

time() function in mo= st standards-compliant libraries.

is returned by the PO= SIX time() function in most standards-compliant

libraries.

=

When the result of ma= cro expansion is used in a domain name query, if

When the result of ma= cro expansion is used in a domain name query, if

the expanded domain n= ame exceeds 253 characters (the maximum length

the expanded domain n= ame exceeds 253 characters (the maximum length

of a domain name), th= e left side is truncated to fit, by removing

of a domain name), th= e left side is truncated to fit, by removing

= successive domain labels until the total length does not exceed= 253

successive domain lab= els (and their following dots) until the total

characters.

length does not excee= d 253 characters.

Uppercased macros exp= and exactly as their lowercased equivalents, and

Uppercased macros exp= and exactly as their lowercased equivalents, and

= are then URL escaped. URL escaping must be performed for characters

are then URL escaped.= URL escaping MUST be performed for characters

not in the "= uric" set, which = is defined in [RFC3986].

not in the "= unreserved" set, = which is defined in [RFC3986].

= Note: Care must be taken so that macro expansion for legitimate

Note: Care has to= be taken so that macr= o expansion for legitimate

E-Mail does not exceed the 63-character= limit on DNS labels. The

email does not exceed the 63-character = limit on DNS labels. The

localpart<= span style=3D" font-family:'monospace';"> of E-Mail addresses, in particular, can have mo= re than 63

local-part= of email addresses, in particular, can have mo= re than 63

characters between do= ts.

characters between do= ts.

= Note: Domains should avoid using the "s", "l", "o",= or "h" macros in

Note: Domains = SHO= ULD avoid using the &q= uot;s", "l", "o", or "h" macros in

conjunction with any = mechanism directive. Although these macros are

conjunction with any = mechanism directive. Although these macros are

powerful and allow pe= r-user records to be published, they severely

powerful and allow pe= r-user records to be published, they severely

limit the ability of = implementations to cache results of check_host()

limit the ability of = implementations to cache results of check_host()

and they reduce the e= ffectiveness of DNS caches.

and they reduce the e= ffectiveness of DNS caches.

= Implementations should be aware that if no directive processed during

Note: If no directive processed during = the evaluation of check_host()

the evaluation of che= ck_host() contains an "s", "l", "o", or &= quot;h"

contains an "s&q= uot;, "l", "o", or "h" macro, then the re= sults of the

macro, then the resul= ts of the evaluation can be cached on the basis

evaluation can be cac= hed on the basis of <domain> and <ip> alone for

<= /td>

of <domain> and= <ip> alone for as long as the shortest Time To Live

as long as the shorte= st Time To Live (TTL) of all the DNS records

(TTL) of all the DNS = records involved.

involved.

<= /td>

8.2. Expansion Examples=

8.2. Expansion Examples=

The <sender>= is strong-bad@email.example.com.

The <sender>= is strong-bad@email.example.com.

The IPv4 SMTP clie= nt IP is 192.0.2.3.

The IPv4 SMTP clie= nt IP is 192.0.2.3.

The IPv6 SMTP clie= nt IP is 2001:DB8::CB01.

The IPv6 SMTP clie= nt IP is 2001:DB8::CB01.

The PTR domain nam= e of the client IP is mx.example.org.

The PTR domain nam= e of the client IP is mx.example.org.

macro = expansion

macro = expansion

------- ------------= ----------------

------- ------------= ----------------

= skipping to c= hange at pa= ge 31, line 20

= skipping to c= hange at pa= ge 40, line 4

b= ad.strong.lp.3.2.0.192.in-addr._spf.example.com

b= ad.strong.lp.3.2.0.192.in-addr._spf.example.com

%{ir}.%{v}.%{l1r-}.lp= ._spf.%{d2}

%{ir}.%{v}.%{l1r-}.lp= ._spf.%{d2}

= 3.2.0.192.in-addr.strong.lp._spf.example.com

= 3.2.0.192.in-addr.strong.lp._spf.example.com

%{d2}.trusted-domains= .example.net

%{d2}.trusted-domains= .example.net

= example.com.trusted-domains.example.net

= example.com.trusted-domains.example.net

IPv6:

IPv6:

%{ir}.%{v}._spf.%{d2}= 1.0.B.C.0.0.0.0.

%{ir}.%{v}._spf.%{d2}= 1.0.B.C.0.0.0.0.

=

=

0.0.0.0.0.0.0.0.0.0.0= .0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com

0.0.0.0.0.0.0.0.0.0.0= .0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com

9. Implications<= /p>

9. Implications<= /p>

This section outlines= the major implications that adoption of this

This section outlines= the major implications that adoption of this

= document will have on various entities involved in Internet E-Mail.

document will have on= various entities involved in Internet email.

It is intended to mak= e clear to the reader where this document

It is intended to mak= e clear to the reader where this document

knowingly affects the= operation of such entities. This section is

knowingly affects the= operation of such entities. This section is

not a "how-to&qu= ot; manual, or a "best practices" document, and it is not

not a "how-to&qu= ot; manual, or a "best practices" document, and it is not

= a comprehensive list of what such entities should do in light of this

a comprehensive list = of what such entities SHOULD do in light of this

document.

<= /td>

document.

<= /td>

= This section is non-normative.

This section is non-n= ormative. [RFC5598] describes the Internet

email architecture. = This section is organized based on the different

segments of the archi= tecture.

9.1. Sending Domains

9.1. Sending Domains

= Domains that wish to be compliant with this specification will = need

Originating ADMDs= (ADministrative Management Domains - [RFC5598]

to determine the list= of hosts that the= y allow to use their domain

Section 2.2.1 and Sec= tion 2.3) that wish to= be compliant with this

name in the "HEL= O" and "MAIL FROM" identities. It is recognized that

specification will ne= ed to determine the list of relays ([RFC5598]

forming such a list i= s not just a simple technical exercise, but

Section 2.2.2)= that they allow to use their= domain name in the "HELO"

involves policy decis= ions with both technical and administrative

and "MAIL FROM&q= uot; identities when relaying to other ADMDs. It is

considerations.

recognized that formi= ng such a list is not just a simple technical

exercise, but involve= s policy decisions with both technical and

administrative consid= erations.

= It can be helpful to publish records that include a "track= ing

9.1.1. DNS Resource Con= siderations

Minimizing the DNS re= sources required for SPF lookups can be done by

choosing directives t= hat require less DNS information and by placing

lower-cost mechanisms= earlier in the SPF record.

+----------= +--------+-----------------+

| term = | cost | limit |

+----------= +--------+-----------------+

| ip4/ip6 = | 0 | - |

| a = | 1 | 10 |

| include = | 1 | 10 |

| redirect = | 1 | 10 |

| exists = | 1 | 10 |

| mx = | 1 + N* | 10 and N* <=3D 10 |

| ptr/%{p} = | 1 + N* | 10 and N* <=3D 10 |

| all = | 0 | - |

+----------= +--------+-----------------+

* N is the= number of RRs found during each term evaluation

Section 4.6.4 specifi= es the limits receivers have to use. It is

essential to publish = records that do not exceed these requirements.

It is also required t= o carefully weight the cost and the

maintainability of li= cit solutions.

For example, consider= a domain set up as follows:

example.com. I= N MX 10 mx.example.com.

I= N MX 20 mx2.example.com.

mx.example.com. I= N A 192.0.2.1

mx2.example.com. I= N A 192.0.2.129

Assume the administra= tive point is to authorize (pass) mx and mx2

while failing every o= ther host. Compare the following solutions:

Best record:

example.com. IN = TXT "v=3Dspf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"

=

Good record:

$ORIGIN example.co= m.

@ IN = TXT "v=3Dspf1 a:authorized-spf.example.com -all"

<= /td>

authorized-spf IN = A 192.0.2.1

IN = A 192.0.2.129

Expensive record:

example.com. IN = TXT "v=3Dspf1 mx:example.com -all"

Wasteful, bad record:=

example.com. IN = TXT "v=3Dspf1 ip4:192.0.2.0/24 mx -all"

9.1.2. Administrator's = Considerations

There might be admini= strative considerations: using "a" over "ip4" or

"ip6" allow= s hosts to be renumbered easily. Using "mx" over "a&quo= t;

allows the set of mai= l hosts to be changed easily. Unless such

changes are common, i= t is better to use the less resource intensive

mechanisms like "= ;ip4" and "ip6" over "a" or "a" or &= quot;mx".

In some specific case= s, standard advice on record content is

appropriate. Publish= ing SPF records for domains that send no mail is

a well established be= st practice. The record for a domain that sends

no mail is:

www.example.com. = IN TXT "v=3Dspf1 -all"

Publishing SPF record= s for individual hosts is also best practice.

The hostname is gener= ally the identity used in the 5321.HELO/.EHLO

command. In the case= of messages with a null 5321.MailFrom, this is

used as the domain fo= r 5321.MailFrom SPF checks, in addition to being

used in 5321.HELO/.EH= LO based SPF checks. The standard SPF record

for an individual hos= t that is involved in mail processing is:

relay.example.com.= IN TXT "v=3Dspf1 a -all"

Validating correct de= ployment is difficult. [RFC6652] describes one

mechanism for solicit= ing feedback on SPF failures. Another approach

that can be helpful to publish records that= include a "tracking

exists:" mechani= sm. By looking at the name server logs, a rough list

exists:" mechani= sm. By looking at the name server logs, a rough list

= may then b= e generated. For example:

can then be generated. For example:

v=3Dspf1 exists:_h= .%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all

v=3Dspf1 exists:_h= .%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all

= 9.2. Mailing Lists

Regardless of the= method used, understanding the ADMD's outbound mail

architecture is essen= tial to effective deployment.

= Mailing lists must be aware of how they re-inject mail that is sent

9.1.3. Bounces

to the list. Mailing= lists MUST comply with the requirements in

[RFC2821],= Section 3.10, and [RFC1123],= Section 5.3.6, that say that

As explained in Secti= on 1.3.3, [RFC5321] allows the reverse-path to

be null, which is typ= ical of some Delivery Status Notification

[RFC3464], commonly c= alled email bounces. In this case the only

entity available for = performing an SPF check is the "HELO" identity

defined in Section 1.= 3.4. SPF functionality is enhanced by

administrators ensuri= ng this identity is set correctly and has an

appropriate SPF recor= d. It is normal to have the HELO identity set

to hostname instead o= f domain. Zone file generation for significant

numbers of hosts can = be consolidated using the redirect modifier and

scripted for initial = deployment. Specific deployment advice is given

above in Section 9.1.= 2.

9.2. Mediators

Broadly speaking, the= re are two types of mediating ADMDs that can

affect SPF deployment= of other ADMDs: mailing lists (see [RFC5598]

Section 5.3) and ReSe= nders ([RFC5598] Section 5.2).

9.2.1. Mailing Lists

=

Mailing lists = hav= e to be aware of how t= hey re-inject mail that is

sent to the list. Ma= iling lists MUST comply with the requirements in

[RFC5321],= Section 3.10, and [RFC1123],= Section 5.3.6, that say that

the reverse-path MUST= be changed to be the mailbox of a person or

the reverse-path MUST= be changed to be the mailbox of a person or

other entity who admi= nisters the list. Whereas the reasons for

other entity who admi= nisters the list. Whereas the reasons for

changing the reverse-= path are many and long-standing, SPF adds

changing the reverse-= path are many and long-standing, SPF adds

enforcement to this r= equirement.

enforcement to this r= equirement.

In practice, almost a= ll mailing list software in use already complies

In practice, almost a= ll mailing list software in use already complies

= with this requirement. Mailing lists that do not comply ma= y or may

with this requirement= . Mailing lists that do not comply might

not encounter problems depending on how acc= ess to the list is

encounter problems de= pending on how access to the list is restricted.

restricted. Such lis= ts that are entirely internal to a domain (only

Such lists that are e= ntirely internal to a domain (only people in the

people in the domain = can send to or receive from the list) are not

domain can send to or= receive from the list) are not affected.

affected.

<= /td>

= 9.3. Forward= ing Services and Aliases

9.2.2. Forwarding Services and Aliases

Forwarding services t= ake mail that is received at a mailbox and

Forwarding services t= ake mail that is received at a mailbox and

direct it to some ext= ernal mailbox. At the time of this writing, the

direct it to some ext= ernal mailbox. At the time of this writing, the

near-universal practi= ce of such services is to use the original "MAIL

near-universal practi= ce of such services is to use the original "MAIL

FROM" of a messa= ge when re-injecting it for delivery to the external

FROM" of a messa= ge when re-injecting it for delivery to the external

= mailbox. [RFC1123] and [RFC2821] describe this action as an "alias"

mailbox. [RFC1123] a= nd [RFC5321] descr= ibe this action as an "alias"

rather than a "m= ail list". This means that the external mailbox's

rather than a "m= ail list". This means the external mailbox's MTA

MTA sees all such mai= l in a connection from a host of the forwarding

sees all such mail in= a connection from a host of the forwarding

service, and so the &= quot;MAIL FROM" identity will not, in general, pass

service, and so the &= quot;MAIL FROM" identity will not, in general, pass

authorization.=

authorization.=

There are three place= s that techniques can be used to ameliorate this

There are three place= s that techniques can be used to ameliorate this

problem.

problem.

= 1. The beginning, when E-Mail is first sent.

1. The beginning= , when email is first sent (Originating ADMDs).

= 1. "Neutral" results could be given for IP addres= ses that may be

1. "Neutral= " results could be given for IP addresses that might

<= /td>

forwarders, in= stead of "Fail" results. For example:

be forwarders= , instead of "fail" results based on a list of

=

known reliabl= e forwarders. For exa= mple:

= "v=3Dspf1 mx -exists:%{ir}.sbl.spamhaus.exam= ple.org ?all"

"= v=3Dspf1 mx ?exists:%{ir}.whitlist.example.org -all"

= This would cause a lookup on an anti-spam DNS blacklist

This would ca= use a lookup on an DNS white list (DNSWL) and

(DNSBL)= and cause a result of &q= uot;Fail" only fo= r E-Mail coming

cause a resul= t of "fail" only for email not either coming

from liste= d sources. All other E-Mail, including E-Mail sent

from the = domain's mx host(s) (SPF pass) or white listed

through forwar= ders, would receive a "Neutral" result. By

sources (SPF = neutral). This, in effect, outsources an

checking the DNSBL after<= span style=3D" font-family:'monospace';"> the known good sources, p= roblems with

element of se= nder policy to the maintainer of the whitelist.

incorrect list= ing on the DNSBL a= re greatly reduced.

= 2. The "MAIL FROM" identity could have additional= information in

2. The "MAI= L FROM" identity could have additional information in

the localp= art that cryptographic= ally identifies the mail as

the local= -part that cryptograph= ically identifies the mail as

coming from an= authorized source. In this case, such an SPF

coming from a= n authorized source. In this case, such an SPF

record could b= e used:

record could = be used:

= "v=3Dspf1 mx exists:%{l}._spf_verify.%{d} -all&q= uot;

"v=3Dspf1 mx exists:%{l= }._spf_verify.%{d} -all"

= Then, a specialized DNS server can be set up to serve th= e

Then, a speci= alized DNS server can be set up to serve the

_spf_verify su= bdomain that validates the localpart. Although

_spf_verify s= ubdomain that validates the local-part.

this requires = an extra DNS lookup, this happens only when the

Although this= requires an extra DNS lookup, this happens only

E-Mail would otherwise be reject= ed as not coming from a known

when the = email would otherwise = be rejected as not coming from

good source.

a known good = source.

Note that= due to the 63-character limit for domain labels,

this approach= only works reliably if the local-part signature

scheme is gua= ranteed either to only produce local-parts with

a maximum of = 63 characters or to gracefully handle truncated

local-parts.<= /span>

= Note that due to the 63-character limit for domain labels,

<= /td>

3. Similarly= , a specialized DNS server could be set up that this approach = only works reliably if= the localpart signature

rate-limit the email coming from= unexpected IP addresses.

scheme is guar= anteed either to only produce localparts with a

maximum of 63 = characters or to gracefully handle truncated

localparts.

= 3. Similarly, a specialized DNS server could be set up = that will

"= v=3Dspf1 mx exists:%{ir}._spf_rate.%{d} -all"

rate-limit the= E-Mail coming from unexpected IP addresses.

= "v=3Dspf1 mx exists:%{ir}._spf_rate.%{d} -al= l"

4. SPF allow= s the creation of per-user policies for special

cases. For e= xample, the following SPF record and appropriate

wildcard DNS = records can be used:

= 4. SPF allows the creation of per-user policies for spe= cial

"= v=3Dspf1 mx redirect=3D%{l1r+}._at_.%{o}._spf.%{d}"

cases. For ex= ample, the following SPF record and appropriate

wildcard DNS r= ecords can be used:

= "v=3Dspf1 mx redirect=3D%{l1r+}._at_.%{o= }._spf.%{d}"

2. The middle, w= hen email is forwarded (Mediating ADMDs).

= 2. The middle, when E-Mail is forwarded.

1. Forwardin= g services can solve the problem by rewriting the

"MAIL FR= OM" to be in their own domain. This means mail

rejected from= the external mailbox will have to be forwarded

back to the o= riginal sender by the forwarding service.

Various schem= es to do this exist though they vary widely in

complexity an= d resource requirements on the part of the

forwarding se= rvice.

= 1. Forwarding services can solve the problem by rewriting the

<= /td>

2. Several p= opular MTAs can be forced from "= ;alias" semantics= to

"MAIL FRO= M" to be <= span style=3D" font-family:'monospace'; background-color:#aaccff;">in t= heir own domain. This means that mail

"mai= ling list" semantics by configuring an additional alias

bounced= from the external mailbo= x will have to = be = re-bounced

with "ow= ner-" prepended t= o the original alias name (e.g., an

by the for= warding service. Various schemes to do this exist

alias of &quo= t;friends: george@example.com, fred@example.org"

though they va= ry widely in complexity and resource

would need an= other alias of the form "owner-friends:

requirements o= n the part<= span style=3D" font-family:'monospace';"> of the forwarding service= .

localowner&qu= ot;).

= 2. Several popular MTAs can be forced from "alias&= quot; semantics to

3. Forwardin= g servers could reject mail that would "fail" SPF if

"mailing = list" semantics by configuring an additional alias

forwarded usi= ng an SMTP reply c= ode of 551, User not local,

with "own= er-" prepended to= the original alias name (e.g., an

(see [RFC5321= ] section 3.4) to = communicate the co= rrect target

alias of "= ;friends: george@example.com, fred@example.org" would

address to re= send the mail to.<= /span>

need another a= lias of the form &= quot;owner-friends: localowner").

= 3. The end, when E-Mail is received.

3. The end, when= email is received (Receiving ADMDs).

= 1. If the owner of the external mailbox wishes to trust the=

1. If the owner = of the external mailbox wishes to trust the

forwarding ser= vice, he can direct the external mailbox's MTA

forwarding se= rvice, he can direct the external mailbox's MTA

to skip SPF te= sts when the client host belongs to the

to skip SPF t= ests when the client host belongs to the

forwarding ser= vice.

forwarding se= rvice.

= 2. Tests against other identities, such as the "HELO&q= uot; identity,

2. Tests against= other identities, such as the "HELO" identity,

may= be used to override a failed= test against the "MAIL FROM"

MAY be used to override a faile= d test against the "MAIL FROM"

identity.

identity.

= 3. For larger domains, it may not be possible to have a complete

3. For larger do= mains, it might no= t be possible to have a

or accurate li= st of forwarding services used by the owners of

complete or a= ccurate list of forwarding services used by the

the domain's m= ailboxes. In such cases, whitelists of

owners of the= domain's mailboxes. In such cases, whitelists

generally-reco= gnized forwarding services could be employed.

of generally-= recognized forwarding services could be

employed.

= 9.4. Mail Se= rvices

9.2.3. Mail Services

= Service providers that offer mail services to third-party domains,

MSPs (Mail= Service Providers - [RFC5= 598] Section 2.3) that= offer mail

such as sending of bu= lk mail, may want = to adjust their setup in light

services to third-par= ty domains, such as sending of bulk mail, might

of the authorization = check described in this document. If the "MAIL

want to adjust their = configurations in = light of the authorization

FROM" identity u= sed for such E-Mail uses the domain of the service

check described in th= is document. If the domain part of the "MAIL

provider, then the provider needs only to e= nsure that its sending

FROM" identity u= sed for such email= uses the domain of one of the MSPs

host is authorized by= its own SPF record, if any.

domain, then the provider needs only to ens= ure that its sending host

is authorized by its = own SPF record, if any.

= If the "MAIL FROM" identity does not use the <= span style=3D" font-family:'monospace'; background-color:#aaccff;">mail= service provider's

If the "MAIL FRO= M" identity does not use the MSP's domain, then extra

domain, then extra ca= re must be taken. = The SPF record format has

care has to be taken. The SPF record f= ormat has several options for

several options for t= he third-party domain to authorize the service

the third-party domai= n to authorize the service provider's MTAs to

provider's MTAs to se= nd mail on its behalf. For mail service

send mail on its beha= lf. For MSPs, suc= h as ISPs, that have a wide

providers, such as ISPs, that have a wide v= ariety of customers using

variety of customers = using the same MTA, steps to

the same MTA, steps <= /span>should be taken to = prevent cross-cust= omer forgery

mitiate the risk = of cross-customer forg= ery (see Section 10.4).

(see Section 10.4).

= 9.5. MTA Rel= ays

9.2.4. MTA Relays

= The authorization check generally precludes the use of arbitrar= y MTA

Relays are descri= bed in [RFC5598] Section 2.2.2. The authorization

relays between sender= and receiver of an E-Mail message.

check generally precl= udes the use of arbitrary MTA relays between

sender and receiver o= f an email message= .

Within an organizatio= n, MTA relays can be effectively deployed.

Within an organizatio= n, MTA relays can be effectively deployed.

However, for purposes= of this document, such relays are effectively

However, for purposes= of this document, such relays are effectively

transparent. The SPF= authorization check is a check between border

transparent. The SPF= authorization check is a check between border

= MTAs of different s.

MTAs of different ADMDs.

= For mail senders, this means that published SPF records = mus= t

For mail senders, thi= s means that published SPF records have to

authorize any MTAs th= at actually send across the Internet. Usually,

authorize any MTAs th= at actually send across the Internet. Usually,

these are just the bo= rder MTAs as internal MTAs simply forward mail

these are just the bo= rder MTAs as internal MTAs simply forward mail

= to these MTAs for .

to these MTAs for relaying.

<= /td>

= Mail receivers

The receiving ADM= D will generally want = to perform the authorization

at the border MTAs, specifically including all secondary MX= s. This

check at the <= span style=3D" font-family:'monospace'; background-color:#88ffff;">boun= dary MTAs, including a= ll secondary MXs. Internal

allows mail that fail= s to be rejected during the SMTP session rather

MTAs (including M= TAs that might serve both as boundary MTAs and

than bounced.<= span style=3D" font-family:'monospace';"> Internal MTAs then do not pe= rform the authorization

internal relays from = secondary MXs when they are processing the

test. To perform the= authorization test other than at the border,

relayed mail stream)<= /span> then do not perform th= e authorization test. To

the host that first t= ransferred the message to the organization must

perform the authoriza= tion test other than at the boundary, the host

be determined, which = can be difficult to extract from the message

that first transferre= d the message to the receiving ADMD have to be

header. Testing other than at the = border is not <= span style=3D" font-family:'monospace'; background-color:#aaccff;">reco= mmended.

determined, which can= be difficult to extract from the message header

because (a) header fi= elds can be forged or malformed, and (b) there's

no standard way to en= code that information such that it can be

reliably extracted. Testing other than at = the boundary is likely to

produce unreliable re= sults.

9.3. Receivers

SPF results can be us= ed in combination with other methods to

determine the final l= ocal disposition (either positive or negative of

a message. It can al= so be considered dispositive on its own.

9.3.1. Policy For SPF P= ass

SPF pass results can = be used in combination with "white lists" of

known "good"= ; domains to bypass some or all additional pre-delivery

email checks. Exactl= y which checks and how to determine appropriate

white list entries ha= s to be based on local conditions and

requirements.<= /p>

9.3.2. Policy For SPF F= ail

SPF fail results can = be used to reject messages during the SMTP

transaction based on = either "MAIL FROM" or "HELO" identity results.

This reduces resource= requirements for various content filtering

methods and conserves= bandwidth since rejection can be done before

the SMTP content is t= ransferred. It also gives immediate feedback to

the sender who might = then be able to resolve the issue. Due to some

of the issues describ= ed above in this section (Section 9), SPF based

rejection does presen= t some risk of rejecting legitimate email when

rejecting based on &q= uot;MAIL FROM" results.

SPF fail results can = alternately be used as one input into a larger

set of evaluations wh= ich might, based on a combination with other

evaluation techniques= , result in the email being marked negatively in

some way (this might = be via delivery to a special spam folder,

modifying subject lin= es, or other locally determined means).

Developing the detail= s of such an approach have to be based on local

conditions and requir= ements. Using SPF results in this way does not

have the advantages o= f resource conservation and immediate feedback

to the sender associa= ted with SMTP rejection, but could produce fewer

undesirable rejection= s in a well designed system. Such an approach

might result in email= that was not authorized by the sending ADMD

being unknowingly del= ivered to end users.

Either general approa= ch can be used as they both leave a clear

disposition of emails= . They are either delivered in some manner or

the sender is notifie= d of the failure. Other dispositions such as

"dropping" = or deleting email after acceptance are inappropriate

because they leave un= certainty and reduce the overall reliabilility

and utility of email = across the Internet.

9.3.3. Policy For SPF P= ermerror

The "permerror&q= uot; result (see Section 2.5.7) indicates the SPF

processing module at = the receiver determined that the retrieved SPF

policy record could n= ot be interpreted. This gives no true

indication about the = authorized use of the data found in the

envelope.

<= /td>

As with all results, = implementers have a choice to make regarding

what to do with a mes= sage that yields this result. SMTP allows only

a few basic options.<= /span>

Rejection of the mess= age is an option, in that it is the one thing a

receiver can do to dr= aw attention to the difficulty encountered while

protecting itself fro= m messages that do not have a definite SPF

result of some kind. = However, if the SPF implementation is defective

and returns spurious = "permerror" results, only the sender is actively

notified of the defec= t (in the form of rejected mail), and not the

receiver making use o= f SPF.

The less intrusive ha= ndling choice is to deliver the message, perhaps

with some kind of ann= otation of the difficulty encountered and/or

logging of a similar = nature. However, this will not be desirable to

operators that wish t= o implement SPF checking as strictly as

possible, nor is this= sort of passive problem reporting typically

effective.

=

There is of course th= e option placing this choice in the hands of the

operator rather than = the implementer since this kind of choice is

often a matter of loc= al policy rather than a condition with a

universal solution, b= ut this adds one more piece of complexity to an

already non-trivial e= nvironment.

Both implementers and= operators need to be cautious of all choices

and outcomes when han= dling SPF results.

10. Security Considerat= ions

10. Security Considerat= ions

10.1. Processing Limits=

10.1. Processing Limits=

= As with most aspects of E-Mail, there are a number of ways that

As with most aspects = of email, there ar= e a number of ways that

malicious parties cou= ld use the protocol as an avenue for a

malicious parties cou= ld use the protocol as an avenue for a

= Denial-of-Service (DoS) attack. The processing limits outlined= here

Denial-of-Service (Do= S) attack. The processing limits outlined in

are designed to preve= nt attacks such as the following:

Section 4.6.4<= span style=3D" font-family:'monospace';"> are designed to prevent attac= ks such as the following:

o A malicious party = could create an SPF record with many references

o A malicious party = could create an SPF record with many references

= to a victim's domain and send many E-Mails to different SPF

to a victim's doma= in and send many emails to different SPF

clients; those SPF clients would then create a DoS att= ack. In

verifiers; those SPF verifiers would then create a DoS= attack. In

effect, the SPF are being us= ed to amplify the attacker's

effect, the SPF are being = used to amplify the attacker's

bandwidth by using= fewer bytes in the SMTP session than are used

bandwidth by using= fewer bytes in the SMTP session than are used

by the DNS queries= . Using SPF clients also allows the attacker to

by the DNS queries= . Using SPF clients also allows the attacker to

hide the true sour= ce of the attack.

hide the true sour= ce of the attack.

o Whereas implementa= tions of check_host() are supposed to limit the

o Whereas implementa= tions of check_host() are supposed to limit the

number of DNS look= ups, malicious domains could publish records

number of DNS look= ups, malicious domains could publish records

that exceed these = limits in an attempt to waste computation effort

that exceed these = limits in an attempt to waste computation effort

at their targets w= hen they send them mail. Malicious domains

at their targets w= hen they send them mail. Malicious domains

could also design = SPF records that cause particular

could also design = SPF records that cause particular

implementations to= use excessive memory or CPU usage, or to

implementations to= use excessive memory or CPU usage, or to

trigger bugs.

trigger bugs.

o Malicious parties = could send a large volume of mail purporting to

o Malicious parties = could send a large volume of mail purporting to

come from the inte= nded target to a wide variety of legitimate mail

come from the inte= nded target to a wide variety of legitimate mail

hosts. These legi= timate machines would then present a DNS load on

hosts. These legi= timate machines would then present a DNS load on

the target as they= fetched the relevant records.

the target as they= fetched the relevant records.

Of these, the case of= a third party referenced in the SPF record is

Of these, the case of= a third party referenced in the SPF record is

the easiest for a DoS= attack to effectively exploit. As a result,

the easiest for a DoS= attack to effectively exploit. As a result,

= limits that may seem reasonable for an individual mail server can

limits that m<= span style=3D" font-family:'monospace'; background-color:#88ffff;">ight= seem reasonable for a= n individual mail server can

still allow an unreas= onable amount of bandwidth amplification.

still allow an unreas= onable amount of bandwidth amplification.

Therefore, the proces= sing limits need to be quite low.

Therefore, the proces= sing limits need to be quite low.

= SPF implementations MUST limit the number of mechanisms and= modifiers

10.2. SPF-Authorized May Contain Ot= her False Identities

that do DNS lookups t= o at most 10 per SPF check, including any

lookups caused by the= use of the "include" mechanism or the

"redirect" = modifier. If this number is exceeded during a check, a

PermError MUST be ret= urned. The "include", "a", "mx", "p= tr", and

"exists" me= chanisms as well as the "redirect" modifier do count

against this limit. = The "all", "ip4", and "ip6" mechanisms do= not

require DNS lookups a= nd therefore do not count against this limit.

The "exp" m= odifier does not count against this limit because the DNS

lookup to fetch the e= xplanation string occurs after the SPF record

has been evaluated.

When evaluating the &= quot;mx" and "ptr" mechanisms, or the %{p} macro,=

there MUST be a limit= of no more than 10 MX or PTR RRs looked up and

checked.

SPF implementations S= HOULD limit the total amount of data obtained

from the DNS queries.= For example, when DNS over TCP or EDNS0 are

available, there may = need to be an explicit limit to how much data

will be accepted to p= revent excessive bandwidth usage or memory usage

and DoS attacks.

MTAs or other process= ors MAY also impose a limit on the maximum

amount of elapsed tim= e to evaluate check_host(). Such a limit SHOULD

allow at least 20 sec= onds. If such a limit is exceeded, the result

of authorization SHOU= LD be "TempError".

Domains publishing re= cords SHOULD try to keep the number of "include"

mechanisms and chaine= d "redirect" modifiers to a minimum. Domains

SHOULD also try to mi= nimize the amount of other DNS information

needed to evaluate a = record. This can be done by choosing directives

that require less DNS= information and placing lower-cost mechanisms

earlier in the SPF re= cord.

For example, consider= a domain set up as follows:

example.com. IN = MX 10 mx.example.com.

mx.example.com. IN = A 192.0.2.1

a.example.com. IN = TXT "v=3Dspf1 mx:example.com -all"

b.example.com. IN = TXT "v=3Dspf1 a:mx.example.com -all"

c.example.com. IN = TXT "v=3Dspf1 ip4:192.0.2.1 -all"

Evaluating check_host= () for the domain "a.example.com" requires the

MX records for "= example.com", and then the A records for the listed

hosts. Evaluating fo= r "b.example.com" requires only the A records.

Evaluating for "= c.example.com" requires none.

However, there may be= administrative considerations: using "a" over

"ip4" allow= s hosts to be renumbered easily. Using "mx" over "a&quo= t;

allows the set of mai= l hosts to be changed easily.

=

10.2. SPF-Authorized May Contain O= ther False Identities

= The "= MAIL FROM" and "HELO" identity authorizations must n= ot be

Do not construe t= he "MAIL FROM&quo= t; and "HELO" identity authorizations to

construed to provide more assurance than th= ey do. It is entirely

provide more assuranc= e than they do. It is entirely possible for a

possible for a malici= ous sender to inject a message using his own

malicious sender to i= nject a message using his own domain in the

domain in the identit= ies used by SPF, to have that domain's SPF

identities used by SP= F, to have that domain's SPF record authorize

record authorize the = sending host, and yet the message can easily

the sending host, and= yet the message can easily list other

list other identities= in its header. Unless the user or the MUA

identities in its hea= der. Unless the user or the MUA takes care to

takes care to note th= at the authorized identity does not match the

note that the authori= zed identity does not match the other more

other more commonly-p= resented identities (such as the From: header

commonly-presented id= entities (such as the From: header field), the

field), the user = may be lulled into a f= alse sense of security.

user might= be lulled into a false sense= of security.

10.3. Spoofed DNS and I= P Data

10.3. Spoofed DNS and I= P Data

There are two aspects= of this protocol that malicious parties could

There are two aspects= of this protocol that malicious parties could

exploit to undermine = the validity of the check_host() function:

exploit to undermine = the validity of the check_host() function:

o The evaluation of = check_host() relies heavily on DNS. A malicious

o The evaluation of = check_host() relies heavily on DNS. A malicious

attacker could att= ack the DNS infrastructure and cause

attacker could att= ack the DNS infrastructure and cause

check_host() to se= e spoofed DNS data, and then return incorrect

check_host() to se= e spoofed DNS data, and then return incorrect

= results. This could include returning "Pass"<= /span> for an <ip> valu= e

results. This cou= ld include returning "pass" for an <ip> value

where the actual d= omain's record would evaluate to "Fail". See

where the actual d= omain's record would evaluate to "fail". See

[RFC3833] for a de= scription of DNS weaknesses.

[RFC3833] for a de= scription of DNS weaknesses.

= o The client IP address, <ip>, is assumed to be correct.= A

o The client IP addr= ess, <ip>, is assumed to be correct. In a

malicious attacker= could spoof TCP sequence numbers to make mail

modern, correc= tly configured system = the risk of this not being

appear to come fro= m a permitted host= for a domain that the=

true is nil.

attacker is impersonating.

10.4. Cross-User Forger= y

10.4. Cross-User Forger= y

By definition, SPF po= licies just map domain names to sets of

By definition, SPF po= licies just map domain names to sets of

= authorized MTAs, not whole E-Mail addresses to sets of authorized

authorized MTAs, not = whole email addres= ses to sets of authorized

users. Although the = "l" macro (Section 8) provides a limited way to

users. Although the = "l" macro (Section 8) provides a limited way to

= define individual sets of authorized MTAs for specific <= span style=3D" font-family:'monospace'; background-color:#aaccff;">E-M<= /span>ail

define individual set= s of authorized MTAs for specific email

addresses, it is gene= rally impossible to verify, through SPF, the use

addresses, it is gene= rally impossible to verify, through SPF, the use

= of specific E-Mail addresses by individual users of the same MTA.

of specific email addresses by individu= al users of the same MTA.

It is up to mail serv= ices and their MTAs to directly prevent

It is up to mail serv= ices and their MTAs to directly prevent

= cross-user forgery: based on SMTP AUTH ([RFC2554]),<= span style=3D" font-family:'monospace';"> users should be

cross-user forgery: b= ased on SMTP AUTH ([RFC4954]), users have to be

restricted to using o= nly those E-Mail a= ddresses that are actually

restricted to using o= nly those email ad= dresses that are actually

under their control (= see [RFC4409], Sec= tion 6.1). Another means to

under their control (= see [RFC6409], Sec= tion 6.1). Another means to

verify the identity o= f individual users is message cryptography such

verify the identity o= f individual users is message cryptography such

= as PGP ([RFC2440]) or S/MIME ([RFC3851]).

as PGP ([RFC4880]= ) or S/MIME ([RFC5751]= ).

10.5. Untrusted Informa= tion Sources

10.5. Untrusted Informa= tion Sources

= SPF uses i= nformation supplied by third parties, such as the "HELO"

An SPF compliant receiver gathers information from th= e SMTP commands

domain name, the &quo= t;MAIL FROM" address, and SPF records. This

it receives and from<= /span> the published DNS = records of the sending domain

information is then p= assed to the receiver inReceived-SPF: trace

holder, (e.g.,= "HELO" domain name= , the "MAIL FROM" address from the

fields and possibly returned to the cli= ent MTA in the = for= m of an SMTP

envelope,<= span style=3D" font-family:'monospace';"> and SPF DNS records publi= shed by the domain= holder).

rejection message. T= his information must be checked for invalid

characters and excess= ively long lines.

= When the authorization check fails, an explanation string m= ay be

10.5.1. Recorded Result= s

This information, pas= sed to the receiver in the Received-SPF: or

Authentication-Result= s: trace fields, may be returned to the client

MTA as an SMTP reject= ion message. If such an SMTP rejection message

is generated, the inf= ormation from the trace fields has to be checked

for such problems as = invalid characters and excessively long lines.

10.5.2. External Explan= ations

=

When the authorizatio= n check fails, an explanation string could be

included in the rejec= t response. Both the sender and the rejecting

included in the rejec= t response. Both the sender and the rejecting

receiver need to be a= ware that the explanation was determined by the

receiver need to be a= ware that the explanation was determined by the

publisher of the SPF = record checked and, in general, not the

publisher of the SPF = record checked and, in general, not the

= receiver. The explanation may contain malicious URLs, or i= t may be

receiver. The explan= ation can contain malicious URLs, or it might be

offensive or misleadi= ng.

offensive or misleadi= ng.

= This is probably less of a concern than it may initially se= em since

Explanations returned to sender dom= ains due to "exp" modifiers,

such messages are returned to the sende= r, and the explanation strings

(Section 6.2), were g= enerated by the sender= policy published by the

come from the sender policy published by th= e domain in the identity

domain holders th= emselves. As long as = messages are only returned

claimed by that very = sender. As long as to

with non-delivery not= ification ([RFC3464]) = to domains publishing the

someone other tha= n the actual sender, t= he only people who see

explanation strings f= rom their own DNS SPF records, the only affected

malicious explanation strings are peopl= e whose messages claim to be

parties are the origi= nal publishers of the domain's SPF records.

from domains that= publish such strings in

=

practice, DSNs can be misdirected, such= as when an MTA accepts an

In practice, <= span style=3D" font-family:'monospace'; background-color:#88ffff;">such= non-delivery notifications can be misdirected, such

E-Mail and then later generates a DSN to a forged address, or when an=

as when an MTA accept= s an email and only later generates = the

E-Mail forwarder does not direct the back to the orig= inal sender.

notification to a forged address, or when a= n email forwarder = does not

direct the bounce= back to the original = sender.

=

10.5.3. Macro Expansion=

Macros (Section 8) al= low senders to inject arbitrary text (any non-

null [US-ASCII] chara= cter) into receiver DNS queries. It is necesary

to be prepared for ho= stile or unexpected content.

10.6. Privacy Exposure<= /span>

10.6. Privacy Exposure<= /span>

Checking SPF records = causes DNS queries to be sent to the domain

Checking SPF records = causes DNS queries to be sent to the domain

owner. These DNS que= ries, especially if they are caused by the

owner. These DNS que= ries, especially if they are caused by the

"exists" me= chanism, can contain information about who is sending

"exists" me= chanism, can contain information about who is sending

= E-Mail and= likely to which MTA the E-Mail is being sent. This can

email and likely to which MTA the e= mail is being sent. T= his can

introduce some privac= y concerns, which may be more or less of an

introduce some privac= y concerns, which are more or less of an issue

issue depending on lo= cal laws and the relationship between the domain

depending on local la= ws and the relationship between the domain owner

owner and the person = sending the E-Mail.

and the person sendin= g the email.

11. Contributors and Ac= knowledgements

11. Contributors and Ac= knowledgements

= This document is largely based on the work of Meng Weng = Won= g and Mark

<= /td>

This document is larg= ely based on the work of Meng Weng Wong, Mark

Lentczner.= Although, as this section a= cknowledges, many people have

Lentczner, and Wa= yne Schlitt. Although= , as this section

contributed to this d= ocument, a very large portion of the writing and

acknowledges, many pe= ople have contributed to this document, a very

editing are due to and Mark.

large portion of the = writing and editing are due to Meng, Mark, and

Wayne.

=

This design owes a de= bt of parentage to [RMX] by Hadmut Danisch and

This design owes a de= bt of parentage to [RMX] by Hadmut Danisch and

to [DMP] by Gordon Fe= cyk. The idea of using a DNS record to check

to [DMP] by Gordon Fe= cyk. The idea of using a DNS record to check

= the legitimacy of an E-Mail address traces its ancestry further back

the legitimacy of an = email address trac= es its ancestry further back

through messages on t= he namedroppers mailing list by Paul Vixie

through messages on t= he namedroppers mailing list by Paul Vixie

= =

[Vixie] (based on sug= gestion by Jim Miller) and by David Green

[Vixie] (based on sug= gestion by Jim Miller) and by David Green

[Green].

[Green].

Philip Gladstone cont= ributed the concept of macros to the

Philip Gladstone cont= ributed the concept of macros to the

specification, multip= lying the expressiveness of the language and

specification, multip= lying the expressiveness of the language and

making per-user and p= er-IP lookups possible.

making per-user and p= er-IP lookups possible.

= The authors would also like to thank the literally hundreds of<= /span>

The authors of bo= th this document and [RFC4408] would also like to

individuals who have = participated in the development of this design.

thank the literally h= undreds of individuals who have participated in

They are far too nume= rous to name, but they include the following:

the development of th= is design. They are far too numerous to name,

but they include the = following:

=

The participants i= n the SPFbis working group.

The folks on the s= pf-discuss mailing list.

The folks on the s= pf-discuss mailing list.

The folks on the S= PAM-L mailing list.

The folks on the S= PAM-L mailing list.

The folks on the I= RTF ASRG mailing list.

The folks on the I= RTF ASRG mailing list.

The folks on the I= ETF MARID mailing list.

The folks on the I= ETF MARID mailing list.

The folks on #perl= .

The folks on #perl= .

12. IANA Considerations=

12. IANA Considerations=

12.1. The SPF DNS Recor= d Type

12.1. The SPF DNS Recor= d Type

= The IANA <= /span>has assigned a = new Resource Record Ty= pe and Qtype from the

Per [RFC4408], th= e IANA assigned th= e Resource Record Type= and Qtype

DNS Parameters Regist= ry for the SPF RR type with code 99.

from the DNS Paramete= rs Registry for the SPF RR type with code 99.

The format of thi= s type is identical to the TXT RR [RFC1035]. The

character content of = the record is encoded as [US-ASCII]. Use of

this record type is o= bsolete for SPF Version 1.

IANA is requested to = add an annotation to the SPF RRTYPE saying

"(OBSOLETE - use= TXT)" in the DNS Parameters registry.

[NOTE TO RFC EDITOR: = (to be changed to " ... has added ..." upon

publication)]<= /p>

12.2. The Received-SPF = Mail Header Field

12.2. The Received-SPF = Mail Header Field

Per [RFC3864], the &q= uot;Received-SPF:" header field is added to the IANA

Per [RFC3864], the &q= uot;Received-SPF:" header field is added to the IANA

Permanent Message Hea= der Field Registry. The following is the

Permanent Message Hea= der Field Registry. The following is the

registration template= :

registration template= :

Header field name:= Received-SPF

Header field name:= Received-SPF

= Applicable protocol: mail ([RFC2822])

Applicable protoco= l: mail ([RFC5322])

Status: Experi= mental

Status: Standa= rds Track

Author/Change cont= roller: IETF

Author/Change cont= roller: IETF

= Specification document(s): RFC 4408

Specification docu= ment(s): RFC XXXX

Related informatio= n:

[NOTE TO RFC EDITO= R: (this document)]

Requesting<= span style=3D" font-family:'monospace';"> SPF Council review of any= proposed changes and<= /span>

additions to this field are reco= mmended. For information about

12.3. SPF Modifier Registration

<= /td>

the SPF Council se= e http://www.openspf.org/Council

[RFC6652] created a n= ew SPF Modifier Registration. IANA is requested

to change the referen= ce for the exp and redirect modifiers from

[RFC4408] to this document. Their stat= us should not be changed.

13. References

13. References

13.1. Normative Referen= ces

13.1. Normative Referen= ces

[RFC1035] Mockapetri= s, P., "Domain names - implementation and

[RFC1035] Mockapetri= s, P., "Domain names - implementation and

specificat= ion", STD 13, RFC 1035, November 1987.

specificat= ion", STD 13, RFC 1035, November 1987.

[RFC1123] Braden, R.= , "Requirements for Internet Hosts - Application

[RFC1123] Braden, R.= , "Requirements for Internet Hosts - Application

and Suppor= t", STD 3, RFC 1123, October 1989.

and Suppor= t", STD 3, RFC 1123, October 1989.

[RFC2119] Bradner, S= ., "Key words for use in RFCs to Indicate

[RFC2119] Bradner, S= ., "Key words for use in RFCs to Indicate

Requiremen= t Levels", BCP 14, RFC 2119, March 1997.

Requiremen= t Levels", BCP 14, RFC 2119, March 1997.

= [RFC2821] Klensin, J., "Simple Mail Transfer Protocol= ", RFC 2821,

[RFC3463]<= span style=3D" font-family:'monospace';"> Vaudreuil, G., "Enh= anced Mail System Stat= us Codes",

April 2001= .

RFC 34= 63, January 2003.

[RFC2822] Resnick, P= ., "Internet Message Format", RFC 2822, April

2001.

[RFC3464] Moore, K. = and G. Vaudreuil, = "An Extensible Message Format

for Delive= ry Status Notifica= tions", RFC 3= 464, January

2003.<= /span>

[RFC3513] Hinden, R.= and S. Deering, "Internet Protocol Version 6

(IPv6) Add= ressing Architecture", RFC 3513, April 2003.

[RFC3864] Klyne, G.,= Nottingham, M., and J. Mogul, "Registration

[RFC3864] Klyne, G.,= Nottingham, M., and J. Mogul, "Registration

Procedures= for Message Header Fields", BCP 90, RFC 3864,

Procedures= for Message Header Fields", BCP 90, RFC 3864,

September = 2004.

September = 2004.

[RFC3986] Berners-Le= e, T., Fielding, R., and L. Masinter, "Uniform

[RFC3986] Berners-Le= e, T., Fielding, R., and L. Masinter, "Uniform

= Resource Identifier (URI): Generic Syntax", STD= 66, RFC

Resource I= dentifier (URI): Generic Syntax", STD 66,

3986, Janu= ary 2005.

RFC 3986, = January 2005.

= [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax<= /p>

[RFC4291] Hinden= , R. and S. Deerin= g, "IP Version 6 Addressing

Specificat= ions: ABNF", RFC = 4234, October 2005.

Architectu= re", RFC <= span style=3D" font-family:'monospace'; background-color:#88ffff;">4291= , February 2006.

= [US-ASCII] American National Standards Institute (formerly Unit= ed

[RFC5234] Crocke= r, D. and P. Overell, "Augmented BNF for Syntax

Specificat= ions: ABNF", STD 68, RFC 5234, January 2008.

[RFC5321] Klensin, J= ., "Simple Mail Transfer Protocol", RFC 5321,

October 20= 08.

[RFC5322] Resnick, P= ., Ed., "Internet Message Format", RFC 5322,

October 20= 08.

[RFC5451] Kucherawy,= M., "Message Header Field for Indicating

Message Au= thentication Status", RFC 5451, April 2009.

[RFC5598] Crocker, D= ., "Internet Mail Architecture", RFC 5598,

July 2009.=

[RFC5890] Klensin, J= ., "Internationalized Domain Names for

Applicatio= ns (IDNA): Definitions and Document Framework",

RFC 5890, = August 2010.

=

[US-ASCII]

=

American N= ational Standards Institute (formerly United

States of = America Standards Institute), "USA Code for

States of = America Standards Institute), "USA Code for

Informatio= n Interchange, X3.4", 1968.

Informatio= n Interchange, X3.4", 1968.

= ANSI X3.4-1968 has been replaced by newer versions with slight<= /span>

ANSI X3.4-= 1968 has been replaced by newer versions with

modificati= ons, but the 1968 version remains definitive for

slight mod= ifications, but the 1968 version remains

the Intern= et.

definitive= for the Internet.

= 13.2 Informative= References

13.2. Informative References

=

[DMP] Fecyk,= G., "Designated Mailers Protocol".

Work In Pr= ogress

[Green] Green, D.,= "Domain-Authorized SMTP Mail", 2002.

[RFC1034] Mockapetri= s, P., "Domain names - concepts and facilities",

[RFC1034] Mockapetri= s, P., "Domain names - concepts and facilities",

STD 13, RF= C 1034, November 1987.

STD 13, RF= C 1034, November 1987.

= [RFC1983] Malkin, G., "Internet Users' Glossary", RF= C 1983, August

[RFC1983] Malkin, G.= , "Internet Users' Glossary", RFC 1983,

1996.

August 199= 6.

= [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. = Thayer,

[RFC2308] Andrew= s, M., "Negative Caching of DNS Queries (DNS

"Open= PGP Message Format", RFC 2440, November

NCACHE)&qu= ot;, RFC 2308, Mar= ch 1998.

= [RFC2554] Myers, J., "SMTP Service Extension for Authentication",<= /span>

[RFC2782] Gulbra= ndsen, A., Vixie, P., and L. Esibov, "A DNS RR for

RFC 25= 54, March 1999.

specif= ying the location of services (DNS SRV)", RFC 2782,

February 2= 000.

[RFC3464] Moore, K. = and G. Vaudreuil, "An Extensible Message Format

for Delive= ry Status Notifications", RFC 3464,

January 20= 03.

[RFC3696] Klensin, J= ., "Application Techniques for Checking and

[RFC3696] Klensin, J= ., "Application Techniques for Checking and

Transforma= tion of Names", RFC 3696, February 2004.

Transforma= tion of Names", RFC 3696, February 2004.

[RFC3833] Atkins, D.= and R. Austein, "Threat Analysis of the Domain

[RFC3833] Atkins, D.= and R. Austein, "Threat Analysis of the Domain

Name Syste= m (DNS)", RFC 3833, August 2004.

Name Syste= m (DNS)", RFC 3833, August 2004.

= [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet= Mail

[RFC3834] Moore,= K., "Recommendations for Automatic Responses to

Extensions= (S/MIME) Version 3.1 Message Specification",

Electronic= Mail", RFC 3= 834, August 2004.

RFC 38= 51, July 2004.<= /p>

= [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",

[RFC4408] Wong, = M. and W. Schlitt,= "Sender Policy Framework (SPF)

RFC 44= 09, April 2006.=

for Au= thorizing Use of Domains in E-Mail, Version 1",

RFC 44= 08, April 2006.=

= [RMX] Danish, H., "The RMX DNS RR Type for light = weight sender

[RFC4632] Fuller= , V. and T. Li, "Classless Inter-domain Routing

authentica= tion", Work In Progress

(CIDR): Th= e Internet Address Assignment and Aggregation

Plan"= , BCP 122, RFC 4632, August 2006.

= [DMP] Fecyk, G., "Designated Mailers Protocol&quo= t;, Work In Progress

[RFC4880] Callas= , J., Donnerhacke, L., Finney, H., Shaw, D., and R.

Thayer, &q= uot;OpenPGP Message Format", RFC 4880, November 2007.

= [Vixie] Vixie, P., "Repudiating MAIL FROM", 20= 02.

[RFC4954] Siembo= rski, R. and A. Melnikov, "SMTP Service Extension

for Authen= tication", RFC 4954, July 2007.

= [Green] Green, D., "Domain-Authorized SMTP Mail", 2002.

[RFC5751] Ramsde= ll, B. and S. Turner, "Secure/Multipurpose Internet

Mail Exten= sions (S/MIME) Version 3.2 Message

Specificat= ion", RFC 5751, January 2010.

[RFC5782] Levine, J.= , "DNS Blacklists and Whitelists", RFC 5782,

February 2= 010.

[RFC6409] Gellens, R= . and J. Klensin, "Message Submission for Mail",

STD 72= , RFC 6409, November 2011.

[RFC6647] Kucherawy,= M. and D. Crocker, "Email Greylisting: An

Applicabil= ity Statement for SMTP", RFC 6647, June 2012.

[RFC6652] Kitterman,= S., "Sender Policy Framework (SPF)

Authentica= tion Failure Reporting Using the Abuse Reporting

Format&quo= t;, RFC 6652, June 2012.

[RFC6686] Kucherawy,= M., "Resolution of the Sender Policy Framework

(SPF) and = Sender ID Experiments", RFC 6686, July 2012.

[RMX] Danisch, H= ., "The RMX DNS RR Type for light weight sender

authentica= tion".

Work In Pr= ogress

[Vixie] Vixie, P.,= "Repudiating MAIL FROM", 2002.

Appendix A. Collected A= BNF

Appendix A. Collected A= BNF

This section is norma= tive and any discrepancies with the ABNF

This section is norma= tive and any discrepancies with the ABNF

fragments in the prec= eding text are to be resolved in favor of this

fragments in the prec= eding text are to be resolved in favor of this

grammar.

grammar.

= See [RFC42= 34] for ABNF notation. Please note that as per this ABNF

See [RFC5<= span style=3D" font-family:'monospace';">234] for ABNF notation. Pleas= e note that as per this ABNF

definition, literal t= ext strings (those in quotes) are case-

definition, literal t= ext strings (those in quotes) are case-

insensitive. Hence, = "mx" matches "mx", "MX", "mX", = and "Mx".

insensitive. Hence, = "mx" matches "mx", "MX", "mX", = and "Mx".

record =3D = version terms *SP

record =3D = version terms *SP

version =3D = "v=3Dspf1"

version =3D = "v=3Dspf1"

terms =3D = *( 1*SP ( directive / modifier ) )

terms =3D = *( 1*SP ( directive / modifier ) )

directive =3D = [ qualifier ] mechanism

directive =3D = [ qualifier ] mechanism

qualifier =3D = "+" / "-" / "?" / "~"

qualifier =3D = "+" / "-" / "?" / "~"

= skipping to c= hange at pa= ge 42, line 38

= skipping to c= hange at pa= ge 57, line 38

MX =3D = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

MX =3D = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

PTR =3D = "ptr" [ ":" domain-spec ]

PTR =3D = "ptr" [ ":" domain-spec ]

IP4 =3D = "ip4" ":" ip4-network [ ip4-cidr-length ]

IP4 =3D = "ip4" ":" ip4-network [ ip4-cidr-length ]

IP6 =3D = "ip6" ":" ip6-network [ ip6-cidr-length ]

IP6 =3D = "ip6" ":" ip6-network [ ip6-cidr-length ]

exists =3D = "exists" ":" domain-spec

exists =3D = "exists" ":" domain-spec

modifier =3D = redirect / explanation / unknown-modifier

modifier =3D = redirect / explanation / unknown-modifier

redirect =3D = "redirect" "=3D" domain-spec

redirect =3D = "redirect" "=3D" domain-spec

explanation =3D = "exp" "=3D" domain-spec

explanation =3D = "exp" "=3D" domain-spec

unknown-modifier =3D = name "=3D" macro-string

unknown-modifier =3D = name "=3D" macro-string

=

; = where name is not any known modifier

ip4-cidr-length =3D = "/" 1*DIGIT

ip4-cidr-length =3D = "/" 1*DIGIT

ip6-cidr-length =3D = "/" 1*DIGIT

ip6-cidr-length =3D = "/" 1*DIGIT

dual-cidr-length =3D = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

dual-cidr-length =3D = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

ip4-network =3D = qnum "." qnum "." qnum "." qnum

ip4-network =3D = qnum "." qnum "." qnum "." qnum

qnum =3D = DIGIT ; 0-9

qnum =3D = DIGIT ; 0-9

/ = %x31-39 DIGIT ; 10-99

/ = %x31-39 DIGIT ; 10-99

/ = "1" 2DIGIT ; 100-199

/ = "1" 2DIGIT ; 100-199

/ = "2" %x30-34 DIGIT ; 200-249

/ = "2" %x30-34 DIGIT ; 200-249

/ = "25" %x30-35 ; 250-255

/ = "25" %x30-35 ; 250-255

= ; conventional dotted quad notation. e.g., 192.0.2.0=

; convention= al dotted quad notation. e.g., 192.0.2.0

ip6-network =3D = <as per [RFC 3513],

ip6-network =3D = <as per [RFC 4291], ; e.g., 200= 1:DB8::CD30

; e.g., 2001= :DB8::CD30

domain-spec =3D = macro-string domain-end

domain-spec =3D = macro-string domain-end

domain-end =3D = ( "." toplabel [ "." ] ) / macro-expand

<= /td>

domain-end =3D = ( "." toplabel [ "." ] ) / macro-expand

<= /td>

=

=

toplabel =3D = ( *alphanum ALPHA *alphanum ) /

toplabel =3D = ( *alphanum ALPHA *alphanum ) /

( = 1*alphanum "-" *( alphanum / "-" ) alphanum )

( = 1*alphanum "-" *( alphanum / "-" ) alphanum )

; = LDH rule plus additional TLD restrictions

; = LDH rule plus additional TLD restrictions

= ; (see [RFC3696], Section 2)

<= /td>

; = (see [RFC3696], Section 2 for background)

=

alphanum =3D = ALPHA / DIGIT

alphanum =3D = ALPHA / DIGIT

explain-string =3D = *( macro-string / SP )

explain-string =3D = *( macro-string / SP )

macro-string =3D = *( macro-expand / macro-literal )

macro-string =3D = *( macro-expand / macro-literal )

macro-expand =3D = ( "%{" macro-letter transformers *delimiter "}" )

macro-expand =3D = ( "%{" macro-letter transformers *delimiter "}" )

/ = "%%" / "%_" / "%-"

/ = "%%" / "%_" / "%-"

macro-literal =3D = %x21-24 / %x26-7E

macro-literal =3D = %x21-24 / %x26-7E

; = visible characters except "%"

; = visible characters except "%"

macro-letter =3D = "s" / "l" / "o" / "d" / "i= " / "p" / "h" /

macro-letter =3D = "s" / "l" / "o" / "d" / "i= " / "p" / "h" /

= "c" / "r" / "t"= ;

&q= uot;c" / "r" / "t" / "v"<= /p>

transformers =3D = *DIGIT [ "r" ]

transformers =3D = *DIGIT [ "r" ]

delimiter =3D = "." / "-" / "+" / "," / "/= " / "_" / "=3D"

delimiter =3D = "." / "-" / "+" / "," / "/= " / "_" / "=3D"

name =3D = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." = )

name =3D = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." = )

header-field =3D = "Received-SPF:" [CFWS] result FWS [comment FWS]

header-field =3D = "Received-SPF:" [CFWS] result FWS [comment FWS]

[ = key-value-list ] CRLF

[ = key-value-list ] CRLF

= result =3D "Pass" / "Fail" / "SoftFail" / "Neutral" /

result =3D = "pass" /= "fail" = / "softfail""neutral" /

/ <= /span>"TempError""PermError"

/ <= /span>"temperror""permerror"

key-value-list =3D = key-value-pair *( ";" [CFWS] key-value-pair )

key-value-list =3D = key-value-pair *( ";" [CFWS] key-value-pair )

[&= quot;;"]

[&= quot;;"]

key-value-pair =3D = key [CFWS] "=3D" ( dot-atom / quoted-string )

key-value-pair =3D = key [CFWS] "=3D" ( dot-atom / quoted-string )

key =3D = "client-ip" / "envelope-from" / "helo" /<= /span>

key =3D = "client-ip" / "envelope-from" / "helo" /<= /span>

= "problem" / "receiver" /= "identity" /

&q= uot;problem" / "receiver" / identity /

m= echanism / "x-" name / name

m= echanism / name

identity =3D = "mailfrom" ; for the "MAIL FROM" identity<= /p>

identity =3D = "mailfrom" ; for the "MAIL FROM" identity<= /p>

/ = "helo" ; for the "HELO" identity

/ = "helo" ; for the "HELO" identity

/ = name ; other identities

/ = name ; other identities

= dot-atom =3D <unquoted word as per [RFC2822]>=

ALPHA = =3D <A-Z / a-z as per [RFC5234]>

quoted-string =3D = <quoted string as per [RFC2822]>

DIGIT =3D = <0-9 as per [RFC5234]>

comment =3D = <comment string as per

SP =3D = <space character as per [RFC5234]>

CFWS =3D = <comment or folding white space as per [RFC2822]>

<= /td>

domain =3D = <fully qualified domain as per [RFC5321]>

FWS =3D = <folding white space as per [RFC2822]>

dot-atom =3D = <unquoted word as per [RFC5322]>

CRLF =3D = <standard end-of-line token as per [RFC2822]>

quoted-string =3D = <quoted string as per [RFC5322]>

comment =3D = <comment string as per

CFWS =3D = <comment or folding white space as per [RFC5322]>

<= /td>

FWS =3D = <folding white space as per [RFC5322]>

CRLF =3D = <standard end-of-line token as per [RFC5322]>

authserv-id =3D = <authserv-id per [RFC5451]>

reasonspec =3D = <reason per [RFC5451]>

Appendix B. Extended Ex= amples

Appendix B. Extended Ex= amples

These examples are ba= sed on the following DNS setup:

These examples are ba= sed on the following DNS setup:

; A domain with two m= ail servers, two hosts

; A domain with two m= ail servers, two hosts

; and two servers at = the domain name

; and two servers at = the domain name

$ORIGIN example.com.<= /span>

$ORIGIN example.com.<= /span>

@ MX 10 ma= il-a

@ MX 10 ma= il-a

MX 20 ma= il-b

MX 20 ma= il-b

= skipping to c= hange at pa= ge 44, line 46

= skipping to c= hange at pa= ge 60, line 46

; A rogue reverse IP = domain that claims to be

; A rogue reverse IP = domain that claims to be

; something it's not<= /span>

; something it's not<= /span>

$ORIGIN 0.0.10.in-add= r.arpa.

$ORIGIN 0.0.10.in-add= r.arpa.

4 PTR bob.e= xample.com.

4 PTR bob.e= xample.com.

B.1. Simple Examples

B.1. Simple Examples

These examples show v= arious possible published records for

These examples show v= arious possible published records for

example.com and which= values if <ip> would cause check_host() to

example.com and which= values if <ip> would cause check_host() to

= return "P

return "<= span style=3D" font-family:'monospace'; background-color:#88ffff;">pass". Note that <= ;domain> is "example.com".

v=3Dspf1 +all<= /p>

v=3Dspf1 +all<= /p>

= -- any <ip> passes

-- any <ip> passes

=

v=3Dspf1 a -all

v=3Dspf1 a -all

= -- hosts 192.0.2.10 and 192.0.2.11 pass

-- hosts 192.0.2.10 and 192.0.2.11 = pass

v=3Dspf1 a:example.or= g -all

v=3Dspf1 a:example.or= g -all

= -- no sending hosts pass since example.org has no A records<= /span>

-- no sending hosts pass since exam= ple.org has no A records

v=3Dspf1 mx -all

v=3Dspf1 mx -all

= -- sending hosts 192.0.2.129 and 192.0.2.130 pass

=

-- sending hosts 192.0.2.129 and 19= 2.0.2.130 pass

v=3Dspf1 mx:example.o= rg -all

v=3Dspf1 mx:example.o= rg -all

= -- sending host 192.0.2.140 passes

-- sending host 192.0.2.140 passes<= /span>

v=3Dspf1 mx mx:exampl= e.org -all

v=3Dspf1 mx mx:exampl= e.org -all

= -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 p= ass

-- sending hosts 192.0.2.129, 192.0= .2.130, and 192.0.2.140 pass

v=3Dspf1 mx/30 mx:exa= mple.org/30 -all

v=3Dspf1 mx/30 mx:exa= mple.org/30 -all

= -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 pass= es

-- any sending host in 192.0.2.128/= 30 or 192.0.2.140/30 passes

v=3Dspf1 ptr -all

v=3Dspf1 ptr -all

= -- sending host 192.0.2.65 passes (reverse DNS is valid and = is in

-- sending host 1= 92.0.2.65 passes (reverse DNS is valid and is in

example.com)

example.com)

-- sending host 19= 2.0.2.140 fails (reverse DNS is valid, but not

-- sending host 1= 92.0.2.140 fails (reverse DNS is valid, but not

in example.com)=

in example.com= )

-- sending host 10= .0.0.4 fails (reverse IP is not valid)

-- sending host 1= 0.0.0.4 fails (reverse IP is not valid)

v=3Dspf1 ip4:192.0.2.= 128/28 -all

v=3Dspf1 ip4:192.0.2.= 128/28 -all

= -- sending host 192.0.2.65 fails

-- sending host 1= 92.0.2.65 fails

-- sending host 19= 2.0.2.129 passes

-- sending host 1= 92.0.2.129 passes

B.2. Multiple Domain Ex= ample

B.2. Multiple Domain Ex= ample

These examples show t= he effect of related records:

These examples show t= he effect of related records:

example.org: "= ;v=3Dspf1 include:example.com include:example.net -all"

=

example.org: "= ;v=3Dspf1 include:example.com include:example.net -all"

=

This record would be = used if mail from example.org actually came

This record would be = used if mail from example.org actually came

through servers at ex= ample.com and example.net. Example.org's

through servers at ex= ample.com and example.net. Example.org's

designated servers ar= e the union of example.com's and example.net's

designated servers ar= e the union of example.com's and example.net's

= skipping to c= hange at pa= ge 46, line 10

= skipping to c= hange at pa= ge 62, line 12

These records allow a= set of domains that all use the same mail

These records allow a= set of domains that all use the same mail

system to make use of= that mail system's record. In this way, only

system to make use of= that mail system's record. In this way, only

the mail system's rec= ord needs to be updated when the mail setup

the mail system's rec= ord needs to be updated when the mail setup

changes. These domai= ns' records never have to change.

changes. These domai= ns' records never have to change.

B.3. DNSBL Style Exampl= e

B.3. DNSBL Style Exampl= e

Imagine that, in addi= tion to the domain records listed above, there

Imagine that, in addi= tion to the domain records listed above, there

are these:

=

are these:

=

= $ORIGIN _spf.example.com. mary.mobile-users = A

$ORIGIN _spf.example.= com.

127.0.0.2 fred.mobile= -users A 127.0.0.2

mary.mobile-users = A 127.0.0.2

fred.mobile-users = A 127.0.0.2

15.15.168.192.joel.re= mote-users A 127.0.0.2

15.15.168.192.joel.re= mote-users A 127.0.0.2

16.15.168.192.joel.re= mote-users A 127.0.0.2

16.15.168.192.joel.re= mote-users A 127.0.0.2

The following records= describe users at example.com who mail from

The following records= describe users at example.com who mail from

arbitrary servers, or= who mail from personal servers.

arbitrary servers, or= who mail from personal servers.

example.com:

example.com:

v=3Dspf1 mx

v=3Dspf1 mx

include:mobile= -users._spf.%{d}

include:mobile= -users._spf.%{d}

skipping to = change at p= age 47, line 5

skipping to = change at p= age 63, line 5

= "-include:ip4._spf.%{d} "

= "-include:ip4._spf.%{d} "

= "-include:ptr._spf.%{d} "

= "-include:ptr._spf.%{d} "

= "+all" )

= "+all" )

ip4._spf.example.com.= SPF "v=3Dspf1 -ip4:192.0.2.0/24 +all"

ip4._spf.example.com.= SPF "v=3Dspf1 -ip4:192.0.2.0/24 +all"

ptr._spf.example.com.= SPF "v=3Dspf1 -ptr +all"

ptr._spf.example.com.= SPF "v=3Dspf1 -ptr +all"

This example shows ho= w the "-include" mechanism can be useful, how an

This example shows ho= w the "-include" mechanism can be useful, how an

SPF record that ends = in "+all" can be very restrictive, and the use

SPF record that ends = in "+all" can be very restrictive, and the use

of De Morgan's Law.

of De Morgan's Law.

= Authors' Addresses

Appendix C. Change = History

= Meng Weng Wong

Changes since RFC= 4408 (to be removed prior to publication)

Singapore

<= /td>

= EMail: mengwong+spf@pobox.com

Moved to stand= ards track

= Wayne Schlitt

Authors update= d

4615 Meredeth #9

Lincoln Nebraska, NE = 68506

United States of Amer= ica

= EMail: wayne@schlitt.net

IESG Note rega= rding experimental use replaced with discussion of

URI: http://www.sch= litt.net/spf/

results

=

= Full Copyright Statement

Process errata:

= Copyright (C) The Internet Society (2006).

Resolved Secti= on 2.5.7 PermError on invalid domains after macro

expansion errata i= n favor of documenting that different clients

produce different = results.

= This document is subject to the rights, licenses and restrictions

<= /td>

Add %v macro to ABNF grammar

contained in BCP 78, = and except as set forth therein, the authors

retain all their righ= ts.

= This document and the information contained herein are prov= ided on an

Replace "= uric" by "unreserved"

"AS IS" bas= is and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

OR IS SPONSORED BY (I= F ANY), THE INTERNET SOCIETY AND THE INTERNET

ENGINEERING TASK FORC= E DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIM= ITED TO ANY WARRANTY THAT THE USE OF THE

INFORMATION HEREIN WI= LL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

WARRANTIES OF MERCHAN= TABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

= Intellectual Property

Recommend an SMTP = reply code for optional permerror rejections

= The IETF takes no position regarding the validity or scope = of any

Correct syntax= in Received-SPF e= xamples

Intellectual Property= Rights or other rights that might be claimed to

pertain to the implem= entation or use of the technology described in

this document or = the extent to which any license under such rights

might or might not be= available; nor does it represent that it has

made any independent = effort to identify any such rights. Information

on the procedures wit= h respect to rights in RFC documents can be

found in BCP 78 and B= CP 79.

= Copies of IPR disclosures made to the IETF Secretariat and = any

Fix unknown-mo= difier clause is too greedy in ABNF

assurances of license= s to be made available, or the result of an

attempt made to obtai= n a general license or permission for the use of

such proprietary righ= ts by implementers or users of this

specification can be = obtained from the IETF on-line IPR repository at

http://www.ietf.org/i= pr.

= The IETF invites any interested party to bring to its atten= tion any

Correct use of= empty domain-spec on exp modifier

copyrights, patents o= r patent applications, or other proprietary

rights that may cover= technology that may be required to implement

this standard. Pleas= e address the information to the IETF at

ietf-ipr@ietf.org.

= Acknowledgement

Fix minor typo err= ata

= Funding fo= r the RFC Editor function is provided byIETF

Convert to spf= bis working group draft,

Administrative Suppor= t Activity (IASA).

draft-ietf-spfbis-= 4408bis-00

Addressed Ticket #= 1, RFC 4408 Section 2.5.6 - Temporary errors by

giving the option = to turn repeated SERVFAIL into permerror and

adding RFC 2308 re= ference.

Clarified text abo= ut IPv4 mapped addresses to resolve test suite

ambiguity

Clarified ambiguit= y about result when more than 10 "mx" or "ptr"

records are return= ed for lookup to s= pecify permerror. This

resolves one of th= e test suite ambiguities

Made all reference= s to result codes lower case per issue #7

Adjusted section 2= .2 Requirement to check mail from per issue #15

Added missing &quo= t;v" element in macro-letter in the collected ABNF

per issue #16 - se= ction 8.1 was already fixed in the pre-WG draft

Marked ptr and &qu= ot;p" macro deprecated/SHOULD NOT use per issue #27

Expunged lower cas= e may from the draft per issue #8

Expunged "x-&= quot; name as an obsolete concept

Updated obslete re= ferences: RFC2821 to RFC5321, RFC2822 to

RFC5322, and RFC42= 34 to RFC5234

Refer to RFC6647 t= o describe greylisting instead of trying to

describe it direct= ly.

Updated informativ= e references to the current versions.

Added definition f= or deprecated since there are questions.

Start to rework se= ction 9 with some RFC5598 terms.

Added mention of RFC 6552 feedback rep= orts in section 9.

Added draft-ietf-s= pfbis-experiment as an informational reference.

Drop Type SPF.

Try and clarify in= formational nature of RFC3696

Fix ABNF nits and = add missing definitions per Bill's ABNF checker.

Make DNS lookup ti= me limit SHOULD instead of MAY.

Reorganize and cla= rify processing limits. Move hard limits to new

section 4.6.4, Eva= luation Limits. Move advice to non-normative

section 9.<= /p>

Removed paragraph = in section 10.1 about limiting total data

volumes as it is unused (and removab= le per the charter) and serves

no purpose (it isn= 't something that actually can be implemented in

any reasonable way= ).

Added text and fig= ures from Alessandro Vesely in section 9.1 to

better explain DNS= resource limits.

Multiple editorial= fixes from Murray Kucherawy's review.

Also based on Murr= ay's review, reworked SMTP identity definitions

and made RFC 5598 = a normative reference instead of informative.

This is a downref = that will have to be mentioned in the last call.

Added RFC 3834 as = an informative reference about backscatter.

Added IDN requirem= ents and normative reference to RFC 5890 to deal

with the question = "like DKIM did it.:

Added informative = reference to RFC 4632 for CIDR and use CIDR

prefix length inst= ead of CIDR-length to match its terminology.

Added RFC 5782 inf= ormative reference on DNSxLs to support

improving the exis= ts description.

Added text on crea= ting a Authentication-Results header field that

matches the Receiv= ed-SPF header field information and added a

normative referenc= e to RFC 5451.

Added informative = reference to RFC 2782 due to SRV mention.

Added informative = reference to RFC 3464 due to DSN mention.

Added informative = reference to RFC 5617 for it's DNS wildcard use.

Added informative = reference to RFC 5782 to enhance the explanation

of how the exists = mechanism works. Clarified the intended match/

no-match method.

Added new sections= on Receiver policy for SPF pass, fail, and

permerror.<= /p>

Added new section = 9 discussion on treatment of bounces and the

significance of HE= LO records.

Added request to I= ANA to update the = SPF modifier registry.

Author's Address<= /p>

Scott Kitterman

Kitterman Technical S= ervices

3611 Scheel Dr=

Ellicott City, MD 21= 042

United States of Amer= ica

Email: scott@kitterma= n.com

=A0End of changes. 318 change blocks.=A0

=

943 lines changed or d= eleted

1353 lines changed or = added


This html diff was produced by rfcdiff 1.41. The latest vers= ion is available from http://t= ools.ietf.org/tools/rfcdiff/

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

=A0rfc4408.txt=A0=

=A0draft-ietf-s= pfbis-4408bis-08.txt=A0

=

Network Working Group = M. Wong

Network Working Group = S. Kitterman

Request for Comments: 4408 = W. Schlitt

Internet-Draft = Kitterman Technical Services

Category: Experimental = April 2006

Obsoletes: 4408 (if approved) = October 22, 2012

Intended status: Standar= ds Track

Sende= r Policy Framework (SPF) for

Expires: April 25, 2013

Authorizing = Use of Domains in E-Mail, Version 1

=

Status of This Memo

Sender Policy Frame= work (SPF) for Authorizing Use of Domains in Email,

= Version 1

draf= t-ietf-spfbis-4408bis-08.txt

=

This memo defines= an Experimental Protocol for the Internet

Abstract

community. It does n= ot specify an Internet standard of any kind.

Discussion and sugges= tions for improvement are requested.

Distribution of this = memo is unlimited.

=

Copyright Notice<= /p>

Email on the Inte= rnet can be forged in a number of ways. In

particular, existing = protocols place no restriction on what a sending

host can use as the &= quot;MAIL FROM" of a message or the domain given on

the SMTP HELO/EHLO co= mmands. This document describes version 1 of

the Sender Policy Fra= mework (SPF) protocol, whereby an ADMD can

explicitly authorize = the hosts that are allowed to use its domain

names, and a receivin= g host can check such authorization.

=

Copyright (C) The= Internet Society (2006)

This document obs= oletes RFC4408.=

=

IESG Note

Status of this Memo

=

The following doc= uments (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)

This Internet-Dra= ft is submitted in full conformance = with the

are published simulta= neously as Experimental RFCs, although there is

provisions of BCP= 78 and BCP 79.

no general techni= cal consensus and efforts to reconcile the two

approaches have faile= d. As such, these documents have not received

full IETF review and = are published "AS-IS" to document the different

approaches as they we= re considered in the <= /span>MARID working group.

=

The IESG takes no= position about which approach is to be preferred

Internet-Drafts a= re working documents of the Internet Engineering

and cautions the reader that there are serious open issue= s for each

Task Force (IETF). N= ote that other gro= ups may also distribute

approach and concerns= about using them in tandem. The IESG believes

working documents as = Internet-Drafts. The = list of current Internet-

that documenting the = different approaches does less harm than not

Drafts is at http://d= atatracker.ietf.org/drafts/current/.

documenting them.

=

Note that the Sen= der ID experiment may use DNS records that may have

Internet-Drafts a= re draft documents valida maximum o= f six months

been created for the current SPF experi= ment or earlier versions in

and may be updated, replaced, or obsole= ted by other docum= ents at any

this set of experimen= ts. Depending on the content of the record,

time. It is inapprop= riate to use Internet-Drafts as reference

this may mean that Sender-ID heuristics= would be applied = incorrectly

material or to cite them other than as = "work in progress."

to a message. Depend= ing on the actions associated by the recipient

with those heuristics= , the message may not be delivered or may be

discarded on receipt.=

=

Participants rely= ing on Sender ID e= xperiment DNS records are warned

This Internet-Dra= ft will expire on = April 25, 2013.

that they may lose va= lid messages in this set of circumstances.

aParticipants publish= ing SPF experiment DNS records should consider

the advice given in s= ection 3.4 of RFC 4406 and may wish to publish

both v=3Dspf1 and spf= 2.0 records to avoid the conflict.

=

Participants in t= he Sender-ID experiment need to be aware that the

Copyright Notice<= /p>

way Resent-* header f= ields are used will result in failure to receive

legitimate email when= interacting with standards-compliant systems

(specifically automat= ic forwarders which comply with the standards by

not adding Resent-* h= eaders, and systems which comply with RFC 822

but have not yet impl= emented RFC 2822 Resent-* semantics). It would

be inappropriate to a= dvance Sender-ID on the standards track without

resolving this intero= perability problem.

=

The community is = invited to observe the= success or failure oftwo

Copyright (c) 201= 2 IETF Trust and the <= /span>persons identified as

approaches during the= two years following publication, in order that

document authors.= All rights reserved.

a community consensus= can be reached in the future.

=

Abstract

This document is = subject to BCP 78 and the IETF Trust's Legal

Provisions Relating t= o IETF Documents

(http://trustee.ietf.= org/license-info) in effect on the date of

publication of this d= ocument. Please review these documents

carefully, as they de= scribe your rights and restrictions with respect

to this document. Co= de Components extracted from this document must

include Simplified BS= D License text as described in Section 4.e of

the Trust Legal Provi= sions and are provided without warranty as

described in the Simp= lified BSD License.

=

E-mail on<= span style=3D" font-family:'monospace';"> the Internet can be forge= d in a number of ways. In

This document may= contain material from IETF Documents or IETF

particular, existing = protocols place no restriction on what a sending

Contributions publish= ed or made publicly available before November

host can use as the reverse-path of a m= essage or the <= span style=3D" font-family:'monospace'; background-color:#aaccff;">doma= in given on

10, 2008. The person= (s) controlling the in = som= e of this

the SMTP HELO/EHLO co= mmands. This document describes version 1 of

material may not have= granted the IETF = Trust the right to= allow

the Sender Policy= Framework (SPF) protocol, whereby a domain may

modifications<= span style=3D" font-family:'monospace';"> of such material outside = the IETF Standards Process.

explicitly author= ize the hosts that= are allowed to use its domain

Without obtaining an = adequate license from = the person(s) controlling

name, and a receiving host may check such authorization.<= /span>

the copyright in such= materials, this document may not be modified

outside the IETF Standards Process, and derivative works = of it may

not be created ou= tside the IETF Standards Process, except to format

it for publication as= an RFC or to translate it into languages other

than English.<= /p>

Table of Contents=

Table of Contents=

=

1. Introduction .= ...................................................4

1. Introduction = . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.1. Protocol Stat= us ............................................4

1.1. Protocol Stat= us . . . . . . . . . . . . . . . . . . . . . 6

1.2. Terminology <= /span>................................................5

1.2. Experimen= tal History . . . . . . . . . . . . . . . . . . . 7

2. Operation <= span style=3D" font-family:'monospace'; background-color:#aaccff;">....= ...................................................5

1.3. Terminology . . . . . . . . . = . . . . . . . . . . . . . . 7

2.1. The HELO<= /span> Identity .........= .................................5

1.3.1. Keywords = . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. The MAIL = FROM Identity <= span style=3D" font-family:'monospace'; background-color:#aaccff;">....= .................................5

1.3.2. Imported = Definitions . . . . . . . . . . . . . . . . . 7

2.3. Publishing Au= thorization ...................................6

1.3.3. Mail From= Definition . . . . . . . . . . . . . . . . . 7

2.4. Checking Auth= orization .....................................6

1.3.4. HELO Defi= nition . . . . . . . . . . . . . . . . . . . 8

2.5. Interpreting = the Result ....................................7

1.3.5. Deprecate= d . . . . . . . . . . . . . . . . . . . . . . 8

2.5.1. None <= /span>................................................8

2. Operation . = . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.2. Neutra= l .............................................8

2.1. The "= ;HELO" Identity = . . . . . . . . . . . . . . . . . . . 9

2.5.3. Pass <= /span>................................................8

2.2. The "= ;MAIL FROM" Ident= ity . . . . . . . . . . . . . . . . . 9

2.5.4. Fail <= /span>................................................8

2.3. Publishing Au= thorization . . . . . . . . . . . . . . . . . 9

2.5.5. So= ftFail ............................................9

2.4. Checking Auth= orization . . . . . . . . . . . . . . . . . . 10

2.5.6. Te= mpError ...........................................9

2.5. Interpreting = the Result . . . . . . . . . . . . . . . . . 11

2.5.7. Pe= rmError ...........................................9

2.5.1. None = . . . . . . . . . . . . . . . . . . . . . . . . . 12

3. SPF Records ..= ...................................................9

2.5.2. Neutral = . . . . . . . . . . . . . . . . . . . . . . . 12

3.1. Publishin= g ................................................10

2.5.3. Pass = . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.1.= DNS Resource Record Type= s ..........................10

2.5.4. Fail = . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.1.2.= Multiple DNS Records = ...= ............................11

2.5.5. Softf= ail . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.3.= Multiple Strings in a Single= DNS record ............11

2.5.6. Tempe= rror . . . . . . . . . . . . . . . . . . . . . . 13

3.1.4.= Record Size ............= ............................11

2.5.7. Perme= rror . . . . . . . . . . . . . . . . . . . . . . 13

3.1.5.= Wildcard Records .......= ............................11

3. SPF Records = . . . . . . . . . . . . . . . . . . . . . . . . . 14

=

3.1. DNS Resource = Records . . . . . . . . . . . . . . . . . . . 14

4. The check_host() F= unction ......................................12

3.2. Multiple DNS Records . . . . . = . . . . . . . . . . . . . . 15

4.1. Arguments .................................................12

3.3. Multiple Strings in a Single DNS re= cord . . . . . . . . . 15

4.2. Results .= ..................................................13

3.4. Record Size . . . . . . . . . = . . . . . . . . . . . . . . 15

4.3. Initial Proce= ssing ........................................13

3.5. Wildcard Records . . . . . . . = . . . . . . . . . . . . . . 15

4.4. Record Lookup= .............................................13

4. The check_host() = Function . . . . . . . . . . . . . . . . . . 17

4.5. Selecting Rec= ords .........................................13

4.1. Arguments

4.6. Record Evalua= tion .........................................14

4.2. Results = . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.6.1. Term E= valuation ....................................14

4.3. Initial Proce= ssing . . . . . . . . . . . . . . . . . . . . 17

4.6.2. Mechan= isms .........................................15

4.4. Record Lookup= . . . . . . . . . . . . . . . . . . . . . . 18

4.6.3. Modifi= ers ..........................................15

4.5. Selecting Rec= ords . . . . . . . . . . . . . . . . . . . . 18

4.7. Default Resul= t ............................................16

4.6. Record Evalua= tion . . . . . . . . . . . . . . . . . . . . 18

4.8. Domain Specif= ication ......................................16

4.6.1. Term Eval= uation . . . . . . . . . . . . . . . . . . . 19

5. Mechanism Definiti= ons ..........................................16

4.6.2. Mechanism= s . . . . . . . . . . . . . . . . . . . . . . 19

5.1. "all&quo= t; .....................................................17

4.6.3. Modifiers= . . . . . . . . . . . . . . . . . . . . . . 20

5.2. "include= " .................................................18

4.6.4. DNS Looku= p Limits . . . . . . . . . . . . . . . . . . 20

5.3. "a"= .......................................................19

4.7. Default Resul= t . . . . . . . . . . . . . . . . . . . . . . 21

5.4. "mx"= ; ......................................................20

4.8. Domain Specif= ication . . . . . . . . . . . . . . . . . . . 21

5.5. "ptr&quo= t; .....................................................20

5. Mechanism Definit= ions . . . . . . . . . . . . . . . . . . . . 22

5.6. "ip4&quo= t; and "ip6" ...........................................2= 1

5.1. "all&quo= t; . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.7. "exists&= quot; ..................................................22

5.2. "include= " . . . . . . . . . . . . . . . . . . . . . . . . 23

6. Modifier Definitio= ns ...........................................22

5.3. "a"= . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.1. redirect: Red= irected Query ................................23

5.4. "mx"= ; . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2. exp: Explanat= ion ..........................................23

5.5. "ptr&quo= t; (deprecated) . . . . . . . . . . . . . . . . . . . . 25

7. The Received-SPF H= eader Field ..................................25

5.6. "ip4&quo= t; and "ip6" . . . . . . . . . . . . . . . . . . . . . 2= 7

8. Macros .......= ..................................................27

5.7. "exists&= quot; . . . . . . . . . . . . . . . . . . . . . . . . . 27

8.1. Macro Definit= ions .........................................27

6. Modifier Definiti= ons . . . . . . . . . . . . . . . . . . . . . 29

8.2. Expansion Exa= mples ........................................30

6.1. redirect: Red= irected Query . . . . . . . . . . . . . . . . 29

9. Implications .= ..................................................31

6.2. exp: Explanat= ion . . . . . . . . . . . . . . . . . . . . . 30

9.1. Sending Domai= ns ...........................................31

7. Recording The= Result . . . . . . . . . . . . . . . . . . . . . 32

9.2. Mailing Lists= .............................................32

7.1. The Received-SPF Header Field = . . . . . . . . . . . . . . 32

9.3. Forwarding Services and Aliases ...........................32

7.2. SPF Results i= n the Authentication-Results Header Field . . 34

9.4. Mail Services .................= ............................34

8. Macros . . . = . . . . . . . . . . . . . . . . . . . . . . . . . 36

9.5. MTA Relays ....................= ............................34

8.1. Macro Definit= ions . . . . . . . . . . . . . . . . . . . . 36

10. Security Consider= ations .......................................35

8.2. Expansion Exa= mples . . . . . . . . . . . . . . . . . . . . 39

10.1. Processing L= imits ........................................35

9. Implications = . . . . . . . . . . . . . . . . . . . . . . . . . 41

10.2. SPF-Authoriz= ed E-Mail May Cont= ain Other False

9.1. Sending Domai= ns . . . . . . . . . . . . . . . . . . . . . 41

Identities <= /span>...............................................37

9.1.1. DNS Resou= rce Considerations . . . . . . . . . . . . . 41

10.3. Spoofed DNS = and IP Data ..................................37

9.1.2. Administr= ator's Considerations . . . . . . . . . . . . 42

10.4. Cross-User F= orgery .......................................37

9.1.3. Bounces = . . . . . . . . . . . . . . . . . . . . . . . 43

10.5. Untrusted In= formation Sources ............................38

9.2. Mediators= . . . . . . . . . . . . . . . . . . . . . . . . 43

10.6. Privacy Expo= sure .........................................38

9.2.1. Mailing Lists . . . . . . = . . . . . . . . . . . . . . 43

11. Contributors and = Acknowledgements .............................38

9.2.2. Forwarding Services and Aliases= . . . . . . . . . . . 44

12. IANA Consideratio= ns ...........................................39

9.2.3. Mail Services . . . . . . = . . . . . . . . . . . . . . 46

12.1. The SPF DNS = Record Type ..................................39

9.2.4. MTA Relays . . . . . . . . .= . . . . . . . . . . . . . 46

12.2. The Received= -SPF Mail Header Field .......................39

9.3. Receivers . = . . . . . . . . . . . . . . . . . . . . . . . 47

13. References ..= ..................................................39

9.3.1. Policy Fo= r SPF Pass . . . . . . . . . . . . . . . . . 47

13.1. Normative Re= ferences .....................................39

9.3.2. Policy Fo= r SPF Fail . . . . . . . . . . . . . . . . . 47

13.2. Informative = References ...................................40

9.3.3. Policy Fo= r SPF Permerror . . . . . . . . . . . . . . . 48

=

10. Security Consider= ations . . . . . . . . . . . . . . . . . . . 49

Appendix A. Collecte= d ABNF .......................................42

10.1. Processing Li= mits . . . . . . . . . . . . . . . . . . . . 49

Appendix B. Extended= Examples ....................................44

10.2. SPF-Authorize= d Email May Contai= n Other False Identities B.1. Simple Examp= les ..........................................44

10.3. Spoofed DNS a= nd IP Data . . . . . . . . . . . . . . . . . 50

B.2. Multiple Dom= ain Example ..................................45

10.4. Cross-User Fo= rgery . . . . . . . . . . . . . . . . . . . . 50

B.3. DNSBL Style = Example ......................................46

10.5. Untrusted Inf= ormation Sources . . . . . . . . . . . . . . 50

B.4. Multiple Req= uirements Example ............................46

10.5.1. Recorded = Results . . . . . . . . . . . . . . . . . . . 50

10.5.2. External = Explanations . . . . . . . . . . . . . . . . 51

10.5.3. Macro Exp= ansion . . . . . . . . . . . . . . . . . . . 51

10.6. Privacy Expos= ure . . . . . . . . . . . . . . . . . . . . . 51

11. Contributors and = Acknowledgements . . . . . . . . . . . . . . 52

12. IANA Consideratio= ns . . . . . . . . . . . . . . . . . . . . . 53

12.1. The SPF DNS R= ecord Type . . . . . . . . . . . . . . . . . 53

12.2. The Received-= SPF Mail Header Field . . . . . . . . . . . . 53

12.3. SPF Modifier = Registration . . . . . . . . . . . . . . . . 53

13. References . = . . . . . . . . . . . . . . . . . . . . . . . . . 54

13.1. Normative Ref= erences . . . . . . . . . . . . . . . . . . . 54

13.2. Informative R= eferences . . . . . . . . . . . . . . . . . . 55

Appendix A. Collecte= d ABNF . . . . . . . . . . . . . . . . . . . 57

Appendix B. Extended= Examples . . . . . . . . . . . . . . . . . . 60

B.1. Simple Exampl= es . . . . . . . . . . . . . . . . . . . . . 60

B.2. Multiple Doma= in Example . . . . . . . . . . . . . . . . . 61

B.3. DNSBL Style E= xample . . . . . . . . . . . . . . . . . . . 62

B.4. Multiple Requ= irements Example . . . . . . . . . . . . . . 62

Appendix C. Change H= istory . . . . . . . . . . . . . . . . . . . 63

Author's Address . . = . . . . . . . . . . . . . . . . . . . . . . . 66

1. Introduction<= /p>

1. Introduction<= /p>

=

The current E-Mai= l infrastructure has t= he property that any host

The current email= infrastructure has th= e property that any host

injecting mail into t= he mail system can= identify itself as any domain

injecting mail into t= he system can use = any DNS domain nam= e it wants

name it wants. H= osts can do this at a variety of levels: in

in each of= the various identifiers = specified by [RFC5321]= and

particular, the s= ession, the envelo= pe, and the mail h= eaders.

[RFC5322].= Although this feature is de= sirable in some circumstances,

Although this feature= is desirable in some circumstances, it is a

it is a major obstacl= e to reducing Unsolicited Bulk Email (UBE, aka

major obstacle to red= ucing Unsolicited Bulk E-Mail (UBE, aka spam).

spam). Furthermore, = many domain owning ADMDs (ADministrative

Furthermore, many dom= ain name holders a= re understandably concerned

Management Domains, s= ee [RFC5598]) are unde= rstandably concerned about

about the ease with w= hich other entities may make use of their domain

the ease with which o= ther entities can = make use of their domain

names, often with mal= icious intent.

names, often with mal= icious intent.

=

This document defines= a protocol by which domain owners may authorize

This document defines= a protocol by which ADMDs can authorize hosts

hosts to use their do= main name in the &= quot;MAIL FROM" or "HELO" identity.

to use their domain <= /span>names in the "= MAIL FROM" or "HELO" identities.

Compliant domain = holders publish Sender= Policy Framework (SPF)

Compliant ADMDs publish Sender Policy F= ramework (SPF) records in the

records specifying wh= ich hosts are permitted to use their names, and

DNS specifying which hosts are permitted to= use their names, and

compliant mail receiv= ers use the published SPF records to test the

compliant mail receiv= ers use the published SPF records to test the

authorization of send= ing Mail Transfer Agents (MTAs) using a given

authorization of send= ing Mail Transfer Agents (MTAs) using a given

"HELO" or &= quot;MAIL FROM" identity during a mail transaction.

"HELO" or &= quot;MAIL FROM" identity during a mail transaction.

An additional benefit= to mail receivers is that after the use of an

An additional benefit= to mail receivers is that after the use of an

identity is verified,= local policy decisions about the mail can be

identity is verified,= local policy decisions about the mail can be

made based on the sen= der's domain, rather than the host's IP address.

made based on the sen= der's domain, rather than the host's IP address.

This is advantageous = because reputation of domain names is likely to

This is advantageous = because reputation of domain names is likely to

be more accurate than= reputation of host IP addresses. Furthermore,

be more accurate than= reputation of host IP addresses. Furthermore,

if a claimed identity= fails verification, local policy can take

if a claimed identity= fails verification, local policy can take

=

stronger action again= st such E-Mail, su= ch as rejecting it.

stronger action again= st such email, suc= h as rejecting it.

1.1. Protocol Status

1.1. Protocol Status

SPF has been in devel= opment since the summer of 2003 and has seen

SPF has been in devel= opment since the summer of 2003 and has seen

deployment beyond the= developers beginning in December 2003. The

deployment beyond the= developers beginning in December 2003. The

design of SPF slowly = evolved until the spring of 2004 and has since

design of SPF slowly = evolved until the spring of 2004 and has since

stabilized. There ha= ve been quite a number of forms of SPF, some

stabilized. There ha= ve been quite a number of forms of SPF, some

written up as documen= ts, some submitted as Internet Drafts, and many

written up as documen= ts, some submitted as Internet Drafts, and many

=

discussed and debated= in development forums.

discussed and debated= in development forums. The protocol was

originally defined in= [RFC4408], which this document replaces.

=

The goal of this = document is to clearly= document the protocol defined

[RFC4408] was des= igned to clearly docum= ent the protocol defined by

by earlier draft spec= ifications of SPF as used in existing

earlier draft specifi= cations of SPF as used in existing

implementations. Thi= s conception of SPF is sometimes called "SPF

implementations. Thi= s updated specification is intended to clarify

Classic". It is= understood that particular implementations and

identified ambiguitie= s in [RFC4408], resolve techincal issues

deployments may diffe= r from, and build = upon, this work. It is hoped

identified in post-RF= C 4408 deplyment experience, and document widely

that we have nonetheless captured t= he common understanding of SPF

deployed extensions t= o SPF that have be= en developed since [RFC4408]

version 1.

=

was published.=

=

1.2. Terminology=

1.2. Experimental H= istory

This document updates= and replaces RFC 4408 that was part of a group

of simultaneously pub= lished Experimental RFCs (RFC 4405, RFC 4406,

RFC 4407, and RFC 440= 8) in 2006. At that time the IESG requested the

community observe the= success or failure of the two approaches

documented in these R= FCs during the two years following publication,

in order that a commu= nity consensus could be reached in the future.

SPF is widely deploye= d by large and small email providers alike.

There are multiple, i= nteroperable implementations.

For SPF (as documente= d in RFC 4408) a careful effort was made to

collect and document = lessons learned and errata during the two year

period. The errata l= ist has been stable (no new submissions) and

only minor protocol l= essons learned were identified. Resolution of

the IESG's experiment= is documented in [RFC6686].

1.3. Terminology

=

1.3.1. Keywords<= /p>

The key words "M= UST", "MUST NOT", "REQUIRED", "SHALL"= ;, "SHALL NOT",

The key words "M= UST", "MUST NOT", "REQUIRED", "SHALL"= ;, "SHALL NOT",

=

"SHOULD", &= quot;SHOULD NOT", "RECOMMENDED", "MAY", and &q= uot;OPTIONAL" in this

"SHOULD", &= quot;SHOULD NOT", "RECOMMENDED", "NOT RECOMMEND= ED", "MAY&qu= ot;, and

document are to be in= terpreted as described in [RFC2119].

"OPTIONAL" = in this document are to be interpreted as described in

[RFC2119].

=

=

1.3.2. Imported Definit= ions

The ABNF tokens "= ;ALPHA", "DIGIT", and "SP" are defined in [RFC= 5234].

The token "local= -part" is defined in [RFC5321].

"dot-atom",= "quoted-string", "comment", "CFWS", &quo= t;FWS", and "CRLF" are

defined in [RFC5322].=

1.3.3. Mail From Defini= tion

This document is conc= erned with the portion of a mail message

This document is conc= erned with the portion of a mail message

commonly called "= ;envelope sender", "return path", "reverse path&quo= t;,

commonly called "= ;envelope sender", "return path", "reverse path&quo= t;,

=

"bounce address&= quot;, "2821 = FROM", or &qu= ot;MAIL FROM". Since these terms are

"bounce address&= quot;, "5321 = FROM", "MAIL FROM", or RFC5321.MailFrom.

<= /td>

either not well defin= ed or often used casually, this document defines

Since these terms are= either not well defined or often used casually,

the "MAIL FROM" identity in Section 2.2.= Note that other terms that<= /span>

this document = use= s "MAIL FROM"= ; for consistency. This means the

may superficially look like the common = terms, such as "reverse-path",

RFC5321.MailFrom as d= efined in [RFC5598= ]. Note that other te= rms that

are used only with th= e defined meanings from normative documents.

might superficially look like the commo= n terms, such as "reverse-

path", are used only with the defined = meanings from normative

documents.

=

=

2. Operation

1.3.4. HELO Definition

=

2.1. The HELO Identity

This document als= o makes use of the HELO/EHLO identity. The "HELO"

identity derives from= either the SMTP HELO = or EHLO command (see

[RFC5321]). Since HE= LO and EHLO can, in many cases, be used

interchangeably, they= are identified commonly as "HELO" in this

document. This means= RFC5321.HELO/.EHLO as defined in [RFC5598].

These commands supply= the identity of the SMTP client (sending host)

for the SMTP session.=

=

The "HELO&qu= ot; identity derives from either the SMTP HELO or EHLO command

1.3.5. Deprecated

(see [RFC2821]). The= se commands supply the SMTP client (sending

host) for the SMTP se= ssion. Note that requirements for the domain

presented in the EHLO= or HELO command are not always clear to the

sending party, and SP= F clients must be prepared for the "HELO"

identity to be malfor= med or an IP address literal. At the time of

this writing, many le= gitimate E-Mails are delivered with invalid HELO

domains.

=

It is RECOMMENDED tha= t SPF clients not = only check the "MAIL FROM"

There are [RFC440= 8] features that are marked "deprecated". In the

<= /td>

context of this docum= ent, deprecated means that senders SHOULD NOT

publish SPF records t= hat make use of such features because they might

be removed entirely i= n future updates to the protocol. Such features

do, however, remain p= art of the SPF protocol and receiving systems

MUST support them unl= ess this document explicitly says otherwise.

2. Operation

=

2.1. The "HELO&quo= t; Identity

=

It is RECOMMENDED tha= t SPF verifiers no= t only check the "MAIL FROM"

identity, but also se= parately check the "HELO" identity by applying

identity, but also se= parately check the "HELO" identity by applying

the check_host() func= tion (Section 4) to the "HELO" identity as the

the check_host() func= tion (Section 4) to the "HELO" identity as the

=

<sender>.

<sender>. = Checking "HELO" promotes consistency of results and can

reduce DNS resource u= sage. Additionally, since SPF records published

for "HELO" = identities refer to a single host, when available, they

are a very reliable s= ource of host authorization status.

=

2.2. The MAIL FROM Iden= tity

Note that require= ments for the domain presented in the EHLO or HELO

command are not alway= s clear to the sending party, and SPF verifiers

MUST be prepared for = the "HELO" identity to be malformed or an IP

address literal. Thi= s SPF check can only be performed when the

"HELO" stri= ng is a valid fully qualified domain.

=

The "MAIL FROM&q= uot; identity derives from the SMTP MAIL command (see

2.2. The "MAIL FROM" Identity

[RFC2821]). This com= mand supplies the "reverse-path" for a message,

which generally consi= sts of the sender mailbox, and is the mailbox to

which notification me= ssages are to be sent if there are problems

delivering the messag= e.

=

[RFC2821]<= span style=3D" font-family:'monospace';"> allows the reverse-path to be= null (see Section 4.5.5 in

SPF verifiers MUS= T check the ""MAIL FROM" identity if a completed<= /p>

RFC 2821).= In this case, there is no e= xplicit sender mailbox, and

"HELO" chec= k has not reached a definitive policy result by applying

the check_host() func= tion to the "MAIL FROM" identity as the

<sender>.

[RFC5321] allows the reverse-path to be nul= l (see Section 4.5.5 in

[RFC5321]). In this case, there is no = explicit sender mailbox, and

such a message can be= assumed to be a notification message from the

such a message can be= assumed to be a notification message from the

mail system itself. = When the reverse-path is null, this document

mail system itself. = When the reverse-path is null, this document

defines the "MAI= L FROM" identity to be the mailbox composed of the

defines the "MAI= L FROM" identity to be the mailbox composed of the

=

localpart<= span style=3D" font-family:'monospace';"> "postmaster" and th= e "HELO" identity (which may or may not

local-part= "postmaster" and t= he "HELO" identity (which might or might

have been checked sep= arately before).

not have been checked= separately before).

=

SPF clients MUST = check the "MAIL FROM" identity. SPF clients check

=

the "MAIL FROM&q= uot; identity by applying the check_host() function to the

"MAIL FROM"= identity as the <sender>.

2.3. Publishing Authori= zation

2.3. Publishing Authori= zation

=

An SPF-compliant doma= in MUST publish a = valid SPF record a= s described

An SPF-compliant doma= in MUST have valid= SPF records as de= scribed in

in Section 3. Th= is record authorizes t= he use of the domain name in

Section 3. These= records authorize the= use of the relevant

the "HELO" = and "MAIL FROM" identities by the MTAs it specifies.

names in the "HELO" and "= ;MAIL FROM" identities by the MTAs specified

therein.

=

If domain owners choo= se to publish SPF records, it is RECOMMENDED

SPF results can b= e used to make both positive (source is authorized)

that they end in "-all", or redir= ect to other records that do, so

and negative (source = is not authorized) determinations. If domain

that a definitive determination of authoriz= ation can be made.

owners choose to publ= ish SPF records and want to support receivers

making negative autho= rization determinations, then they MUST publish

records that end in "-all", or re= direct to other records that do,

otherwise, no definitive determination = of authorization can be made.

Potential issues = and mitigations associated with negative

determinations are di= scussed in Section 9.

=

Domain holders ma= y publish SPF records = that explicitly authorize no

ADMDs can<= span style=3D" font-family:'monospace';"> publish SPF records that expl= icitly authorize no hosts hosts if mail sho= uld never originate using that domain.

domain names that are neither used in t= he domain part of email

addresses nor expecte= d to originate mail.

=

When changing SPF rec= ords, care must be= taken to ensure that there is

When changing SPF rec= ords, care has to = be taken to ensure that there

a transition period s= o that the old policy remains valid until all

is a transition perio= d so that the old policy remains valid until all

legitimate E-Mail= has been checked.

legitimate email = can reasonably expect to have been checked. This

can be as much as 30 = days.

2.4. Checking Authoriza= tion

2.4. Checking Authoriza= tion

A mail receiver can p= erform a set of SPF checks for each mail message

A mail receiver can p= erform a set of SPF checks for each mail message

it receives. An SPF = check tests the authorization of a client host

it receives. An SPF = check tests the authorization of a client host

to emit mail with a g= iven identity. Typically, such checks are done

to emit mail with a g= iven identity. Typically, such checks are done

by a receiving MTA, b= ut can be performed elsewhere in the mail

by a receiving MTA, b= ut can be performed elsewhere in the mail

processing chain so l= ong as the required information is available and

processing chain so l= ong as the required information is available and

reliable. At least t= he "MAIL FROM" identity MUST be checked, but it

reliable. At least t= he "MAIL FROM" identity MUST be checked, but it

is RECOMMENDED that t= he "HELO" identity also be checked beforehand.

is RECOMMENDED that t= he "HELO" identity also be checked beforehand.

Without explicit appr= oval of the domain owner, checking other

Without explicit appr= oval of the domain owner, checking other

identities against SP= F version 1 records is NOT RECOMMENDED because

identities against SP= F version 1 records is NOT RECOMMENDED because

there are cases that = are known to give incorrect results. For

there are cases that = are known to give incorrect results. For

example, almost all m= ailing lists rewrite the "MAIL FROM" identity

example, almost all m= ailing lists rewrite the "MAIL FROM" identity

=

(see Section <= span style=3D" font-family:'monospace'; background-color:#aaccff;">9.2)= , but some do not chan= ge any other identities in the

(see Section <= span style=3D" font-family:'monospace'; background-color:#88ffff;">9.2.= 1), but some do not ch= ange any other identities in

message. The scenari= o described in Section 9.3, sub-section 1.2, is

the message. The sce= nario described in Section 9.2.2, sub-section

another example. Doc= uments that define other identities should

1.2, is another examp= le. Documents that define other identities will

define the method for= explicit approval.

have to define the method for explicit appr= oval.

It is possible that m= ail receivers will use the SPF check as part of

It is possible that m= ail receivers will use the SPF check as part of

a larger set of tests= on incoming mail. The results of other tests

a larger set of tests= on incoming mail. The results of other tests

=

may influence whether or not a particula= r SPF check is performed.

might influence whether or not a particu= lar SPF check is performed.

For example, finding = the sending host's IP address on a local white

For example, finding = the sending host's IP address on a local white

=

list may cause all other tests to be sk= ipped and all mail from that

list might= cause all other tests to be = skipped and all mail from that

host to be accepted.<= /span>

host to be accepted.<= /span>

When a mail receiver = decides to perform an SPF check, it MUST use a

When a mail receiver = decides to perform an SPF check, it MUST use a

correctly-implemented= check_host() function (Section 4) evaluated

correctly-implemented= check_host() function (Section 4) evaluated

with the correct para= meters. Although the test as a whole is

with the correct para= meters. Although the test as a whole is

=

optional, once it has= been decided to perform a test it must be

optional, once it has= been decided to perform a test it has to be

performed as specifie= d so that the correct semantics are preserved

performed as specifie= d so that the correct semantics are preserved

between publisher and= receiver.

between publisher and= receiver.

To make the test, the= mail receiver MUST evaluate the check_host()

To make the test, the= mail receiver MUST evaluate the check_host()

function with the arg= uments set as follows:

function with the arg= uments set as follows:

<ip> - the = IP address of the SMTP client that is emitting the

<ip> - the = IP address of the SMTP client that is emitting the

mail, eith= er IPv4 or IPv6.

mail, eith= er IPv4 or IPv6.

<domain> - the = domain portion of the "MAIL FROM" or "HELO" identit= y.

<domain> - the = domain portion of the "MAIL FROM" or "HELO" identit= y.

<sender> - the = "MAIL FROM" or "HELO" identity.

<sender> - the = "MAIL FROM" or "HELO" identity.

=

Note that the <dom= ain> argument may

Note that the <dom= ain> argument might For example, if the r= everse-path was null, then the EHLO/HELO domain

name. For example, i= f the reverse-path was null, then the EHLO/HELO

is used, with its ass= ociated problems (see Section 2.1). In these

domain is used, with = its associated problems (see Section 2.1). In

cases, check_host() i= s defined in Section 4.3 to return a "None"

these cases, check_ho= st() is defined in Section 4.3 to return a

result.

"none"<= /span> result.

Although invalid, mal= formed, or non-existent domains cause SPF checks

Although invalid, mal= formed, or non-existent domains cause SPF checks

=

to return "N= one" because no S= PF record can be found, it has long been

to return "n= one" because no S= PF record can be found, it has long been

the policy of many MT= As to reject E-Mail from such domains,

the policy of many MT= As to reject email= from such domains, especially

especially in the cas= e of invalid "MAIL FROM". In order to prevent

in the case of invali= d "MAIL FROM". prevent one

the circumvention= of SPF records, r= ejecting E-Mail from invalid

method of circumventi= ng of SPF records.=

domains should be con= sidered.

=

Implementations m= ust take care to corre= ctly extract the <domain> from

Implementations h= ave to take care to co= rrectly extract the <domain>

the data given with t= he SMTP MAIL FROM command as many MTAs will

from the data given w= ith the SMTP MAIL FROM command as many MTAs will

still accept such thi= ngs as source routes (see Appendix

still accept such thi= ngs as source routes (see Appendix

C), the %-hack (see [= RFC1123]), and bang paths (see [RFC1983]).

C), the %-hack (see [= RFC1123]), and bang paths (see [RFC1983]).

These archaic feature= s have been maliciously used to bypass security

These archaic feature= s have been maliciously used to bypass security

systems.

systems.

2.5. Interpreting the R= esult

2.5. Interpreting the R= esult

This section describe= s how software that performs the authorization

This section describe= s how software that performs the authorization

=

should interpret<= /span> the results of the che= ck_host() function. The

interprets= the results of the check_hos= t() function. The

authorization check S= HOULD be performed during the processing of the

authorization check S= HOULD be performed during the processing of the

SMTP transaction that= sends the mail. This allows errors to be

SMTP transaction that= sends the mail. This allows errors to be

returned directly to = the sending MTA by way of SMTP replies.

returned directly to = the sending MTA by way of SMTP replies.

=

Performing the author= ization after the = SMTP transaction has finished

Performing the author= ization other than using the return-path and

may cause problems, such as the following: = (1) It may be diff= icult to

client address at the= time of the MAIL command during the SMTP

accurately extract th= e required information from potentially

transaction can cause problems, such as= the following: (1) It might

deceptive headers; (2= ) legitimate E-Mail may fail because the

be difficult to accur= ately extract the required information from

sender's policy m= ay have since changed.=

potentially deceptive= headers; (2) legitimate email might fail

because the sender's = policy had since c= hanged.

Generating non-delive= ry notifications to forged identities that have

Generating non-delive= ry notifications to forged identities that have

=

failed the authorizat= ion check is generally abusive and against the

failed the authorizat= ion check is a source of backscatter and SHOULD

explicit wishes of the identity owner.

be avoided. [RFC3834= ] section 2 describes backscatter and the

problems it cause= s.

2.5.1. None

<= /td>

2.5.1. None

<= /td>

=

A result of "= ;None" means = that no records we= re published by the do= main

A result of "= ;none" means = either (a) no <= span style=3D" font-family:'monospace'; background-color:#88ffff;">synt= actically valid DNS do= main

or that no checkable sender domain<= /span> could be determine= d from the given

name was extracte= d from the SMTP session that could be used as the

identity. The checki= ng software cannot ascertain whether or not the

one to be authori= zed, or (b) no TXT= records were retrieved from the

client host is au= thorized.

DNS that appeared= to be intended for use by SPF verifiers.

2.5.2. Neutral

2.5.2. Neutral

=

The domain owner has = explicitly stated that he cannot or does

The domain owner has = explicitly stated that they cannot or do want to assert whethe= r or not the IP ad= dress is authorized.

want to assert whethe= r the IP address is authorized or not. A

"Neutral&quo= t; result MUST be trea= ted exactly like the "None" result; the

"neutral&quo= t; result MUST be trea= ted exactly like the "none" result; the

distinction exists on= ly for informational purposes. Treating

distinction exists on= ly for informational purposes. Treating

=

"Neutral&quo= t; more harshly than "None" would discourage domain owners

"neutral&quo= t; more harshly than "none" would discourage domain owners

from testing the use = of SPF records (see Section 9.1).

from testing the use = of SPF records (see Section 9.1).

2.5.3. Pass

<= /td>

2.5.3. Pass

<= /td>

=

A "P<= span style=3D" font-family:'monospace';">ass" result means that th= e client is authorized to inject mail

A "p<= span style=3D" font-family:'monospace';">ass" result means that th= e client is authorized to inject mail

with the given identi= ty. The domain can now, in the sense of

with the given identi= ty. The domain can now, in the sense of

reputation, be consid= ered responsible for sending the message.

reputation, be consid= ered responsible for sending the message.

Further policy checks= can now proceed with confidence in the

Further policy checks= can now proceed with confidence in the

=

legitimate use of the= identity.

legitimate use of the= identity. This is further discussed in

Section 9.3.1.=

2.5.4. Fail

<= /td>

2.5.4. Fail

<= /td>

=

A "Fail"<= /span> result is an explicit = statement that the client is not

A "fail"<= /span> result is an explicit = statement that the client is not

authorized to use the= domain in the given identity. The checking

authorized to use the= domain in the given identity. Disposition of

software can choose t= o mark the mail based = on this or to reject the

SPF fail messages is = a matter of local policy. See Section 9.3.2 for

mail outright.=

considerations= on developing local poli= cy.

If the checking softw= are chooses to reject the mail during the SMTP

If the checking softw= are chooses to reject the mail during the SMTP

transaction, then it = SHOULD use an SMTP reply code of 550 (see

transaction, then it = SHOULD use an SMTP reply code of 550 (see

=

[RFC2821])= and, if supported, the 5.7.1= Delivery Status Notification

[RFC5321])= and, if supported, the 5.7.1= enhanced status c= ode (see

(DSN) code (see [RFC3464]), in addition to an appropriate rep= ly text.

[RFC3463]), in addition to an appropria= te reply text. The

The check_host() func= tion may return ei= ther a default explanation

check_host() function= will return eithe= r a default explanation string

string or one from th= e domain that published the SPF records (see

or one from the domai= n that published the SPF records (see

Section 6.2). If the= information does not originate with the

Section 6.2). If the= information does not originate with the

=

checking software, it= should be made cl= ear that the text is provided

checking software, it= is good to make it clear that the text is

by the sender's domai= n. For example:

provided by the sende= r's domain. For example:

550-5.7.1 SPF MAI= L FROM check failed:

550-5.7.1 SPF MAI= L FROM check failed:

550-5.7.1 The dom= ain example.com explains:

550-5.7.1 The dom= ain example.com explains:

550 5.7.1 Please = see http://www.example.com/mailpolicy.html

550 5.7.1 Please = see http://www.example.com/mailpolicy.html

=

2.5.5. SoftFail<= /p>

If the checking s= oftware chooses not to reject the mail during the

SMTP transaction, the= n it SHOULD add a Received-SPF or

Authentication-Result= s header field (see Section 7) to communicate

this result to downst= ream message processors. While this is true for

all SPF results, it i= s of particular importance for "fail" results

since the message is = explicitly not authorized by the domain owner.

=

A "SoftFail&qu= ot; result should<= /span> be treated as somewher= e between a "Fail"

2.5.5. Softfail<= /p>

and a "Neutr= al". The domain = believes the host is not authorized but

=

is not willing to mak= e that strong of a= statement. Receiving

A "softfail&qu= ot; result ought t= o be treated as somewh= ere between "fail"

software SHOULD NOT r= eject the message based solely on this result,

and "neutral= "/"none".owner

but MAY subject the m= essage to closer scrutiny than normal.

authorized but is not= willing to make a strong policy statement.

Receiving software SH= OULD NOT reject the message based solely on this

result, but MAY subje= ct the message to closer scrutiny than normal.

The domain owner want= s to discourage the use of this host and thus

The domain owner want= s to discourage the use of this host and thus

=

desires limited feedb= ack when a "SoftF

desires limited feedb= ack when a "softf example, the recipien= t's Mail User Agent (MUA) could highlight the

example, the recipien= t's Mail User Agent (MUA) could highlight the

=

"SoftFail&qu= ot; status, or the rec= eiving MTA could give the sender a

"softfail&qu= ot; status, or the rec= eiving MTA could give the sender a

message using = a t= echnique called "greylisting" whereby the MTA can

<= /td>

message using = gre= ylisting, [RFC6647], w= ith a note the first time the

issue an SMTP reply c= ode of 451 (4.3.0 DSN code) with a note the

message is received, = but accept it on a later attempt based on

first time the messag= e is received, but accept it the second time.

receiver policy.

=

2.5.6. TempE= rror

2.5.6. Tempe= rror

=

A "TempError&q= uot; result means = that the SPF clien= t encountered a=

A "temperror&q= uot; result means the = SPF verifier encou= ntered a transient

transient error while= performing the check. Checking software can

(generally DNS) error while performing = the check. Checking software

choose to accept or t= emporarily reject the message. If the message

can choose to accept = or temporarily reject the message. If the

is rejected during th= e SMTP transaction for this reason, the software

message is rejected d= uring the SMTP transaction for this reason, the

SHOULD use an SMTP re= ply code of 451 and, if supported, the 4.4.3 DSN

software SHOULD use a= n SMTP reply code of 451 and, if supported, the

code.

4.4.3 enhanced st= atus code. These = errors can be caused by problems

in either the sender'= s or receiver's DNS software.

=

2.5.7. PermE= rror

2.5.7. Perme= rror

=

A "PermError&q= uot; result means = that the domain's publ= ished records could

A "permerror&q= uot; result means the = domain's published records could not

not be correctly inte= rpreted. This signals an error condition that

be correctly interpre= ted. This signals an error condition that

requires manual inter= vention to be resolved, as opposed to the

definitely= requires manual intervention= to be resolved. If the

TempError result.= Be aware that if the= domain owner uses macros

message is rejected d= uring the SMTP transaction for this reason, the

(Section 8), it is po= ssible that this result is due to the checked

software SHOULD u= se an SMTP reply code of 550 and, if supported, the

identities having an = unexpected format.

5.5.2 enhanced status= code. Be aware that = if the domain owner uses

macros (Section 8), i= t is possible that this result is due to the

checked identities ha= ving an unexpected format. It is also possible

that this result is g= enerated by certain SPF clients due to the input

arguments having an u= nexpected format; see Section 4.8.

3. SPF Records

3. SPF Records

=

An SPF record is a DN= S Resource Record (RR)

An SPF record is a DN= S record that decl= ares which hosts are, and are

are, and are not, aut= horized to use a domain name for the "HELO" and

not, authorized to us= e a domain name for the "HELO" and "MAIL FROM"

"MAIL FROM"= identities. Loosely, the record partitions all hosts

identities. Loosely,= the record partitions all hosts into permitted

into permitted and no= t-permitted sets (though some hosts might fall

and not-permitted set= s (though some hosts might fall into neither

into neither category= ).

category).

=

=

The SPF record is a s= ingle string of text. An example record is the

The SPF record is a s= ingle string of text. The record format is

following:

=

described below in Se= ction 4. An example r= ecord is the following:

v=3Dspf1 +mx a:col= o.example.com/28 -all

v=3Dspf1 +mx a:col= o.example.com/28 -all

This record has a ver= sion of "spf1" and three directives: "+mx",<= /p>

This record has a ver= sion of "spf1" and three directives: "+mx",<= /p>

"a:colo.example.= com/28" (the + is implied), and "-all".

"a:colo.example.= com/28" (the + is implied), and "-all".

=

3.1. Publishing<= /p>

Each SPF record is placed in the DNS tree at the host nam= e it

Domain owners wishing= to be SPF complia= nt must publish SPF records

for the hosts that ar= e used in the "MAIL FROM" and "HELO" identities.

The SPF records are placed in the DNS tree = at the host name it

pertains to, not a su= bdomain under it, such as is done with SRV

pertains to, not a su= bdomain under it, such as is done with SRV

=

records. This is= the same whether the TXT or SPF RR type (see

records [RFC2782]= .

Section 3.1.1) is use= d.

=

The example above= in Section 3 might be published via the= se lines in

The example in th= is section might be pu= blished via these lines in a

a domain zone file:

domain zone file:

example.com. = TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"

<= /td>

example.com. = TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"

<= /td>

smtp-out.example.c= om. TXT "v=3Dspf1 a -all"

smtp-out.example.c= om. TXT "v=3Dspf1 a -all"

=

When publishing v= ia TXT records, beware of other TXT reco= rds

Since TXT records have multiple use= s, beware of other TXT= records

published there for o= ther purposes. They may cause problems with

published there for o= ther purposes. They might cause problems with

size limits (see Sect= ion 3.1.4).

size limits (see Sect= ion 3.4) and c= are has to be take= n to ensure only

SPF records are used<= /span> for SPF processing= .

3.1.1. DNS Resource Rec= ord Types

This document defines= a new DNS RR of type SPF, code 99. The format

of this type is ident= ical to the TXT RR [RFC1035]. For either type,

the character content= of the record is encoded as [US-ASCII].

It is recognized that= the current practice (using a TXT record) is

not optimal, but it i= s necessary because there are a number of DNS

server and resolver implementations in = common use that cannot handle

the new RR type. The= two-record-type scheme provides a forward path

to the better sol= ution of using an RR type reserved for this purpose.

=

An SPF-compliant = domain name SHOULD have SPF records of both RR

ADMDs publishing<= /span> SPF records SHOULD= try to keep the number of

types. A compliant d= omain name MUST have a= record of = at = least one

"include&quo= t; mechanisms and chained "redirect" modifiers to a minimum.

type. If a domain has records of both = types, they MUST have

ADMDs SHOULD also try= to minimize the amount of other DNS information

identical content. F= or example, instead of publishing just one

needed to evaluate a record. Section 4= .6.4 and Section 9= .1.1 provide

record as in Section 3.1 above, it is b= etter to publish:<= /span>

some suggestions on h= ow to achieve this= .

=

example.com. I= N TXT "v=3Dspf1 +mx a:colo.example.com/28 -all"

3.1. DNS Resource Recor= ds

example.com. IN SP= F "v=3Dspf1 +mx a:colo.example.com/28 -all"

=

Example RRs in th= is document are shown with the TXT record type;

SPF records MUST<= /span> be published as a = DNS TXT (type 16) Resource Record

however, they could be published with the SPF type or with = both

(RR) [RFC1035] only. = The character content of the record is encoded

types.

as [US-ASCII]. Use o= f alternate DNS RR types was supported in SPF's

experimental phase, b= ut has been discontinued. See Appendix A of

[RFC6686] for further= information.

=

3.1.2. Multiple DNS Records

3.2. Multiple DNS Recor= ds

A domain name MUST NO= T have multiple records that would cause an

A domain name MUST NO= T have multiple records that would cause an

authorization check t= o select more than one record. See Section 4.5

authorization check t= o select more than one record. See Section 4.5

for the selection rul= es.

for the selection rul= es.

=

3.1.3. Multiple Strings in a Single DNS r= ecord

3.3. Multiple Strings i= n a Single DNS record

As defined in [RFC103= 5] sections 3.3.14 and 3.3, a single text DNS

As defined in [RFC103= 5] sections 3.3.14 and 3.3, a single text DNS

=

record (either TX= T or SPF RR types) can= be composed of more than one

record can be compose= d of more than one string. If a published

string. If a publish= ed record contains multiple strings, then the

record contains multi= ple character-strings, record MUST be treate= d as if those strings are concatenated together

treated as if those s= trings are concatenated together without adding

without adding spaces= . For example:

spaces. For example:=

IN TXT "v=3Ds= pf1 .... first" "second string..."

IN TXT "v=3Ds= pf1 .... first" "second string..."

MUST be treated as eq= uivalent to

MUST be treated as eq= uivalent to

IN TXT "v=3Ds= pf1 .... firstsecond string..."

IN TXT "v=3Ds= pf1 .... firstsecond string..."

=

SPF or TXT records containing multiple = strings are useful in

TXT records containin= g multiple strings are useful in constructing

constructing records = that would exceed the 255-byte maximum length of

records that would ex= ceed the 255-byte maximum length of a character-

a string within a sin= gle TXT or SPF RR = record.

string within a singl= e TXT record.

=

3.1.4. Record Size

3.4. Record Size=

The published SPF rec= ord for a given domain name SHOULD remain small

The published SPF rec= ord for a given domain name SHOULD remain small

enough that the resul= ts of a query for it will fit within 512 octets.

enough that the resul= ts of a query for it will fit within 512 octets.

=

This will keep even o= lder DNS implementations from falling over to

This UDP limit is= defined in [RFC1035] section 2.3.4. This will keep

TCP. Since the answe= r size is dependent on many things outside the

even older DNS implem= entations from falling over to TCP. Since the

scope of this documen= t, it is only possible to give this guideline:

answer size is depend= ent on many things outside the scope of this

If the combined lengt= h of the DNS name and the text of all the

document, it is only = possible to give this guideline: If the combined

records of a given ty= pe (TXT or SPF) is= under 450 characters, then

length of the DNS nam= e and the text of all the records of a given

DNS answers shoul= d fit in UDP packets. = Note that when computing the

type is under 450 cha= racters, then DNS answers fit in UDP

sizes for queries of = the TXT format, one must take into account any

packets. Note that w= hen computing the sizes for queries of the TXT

other TXT records pub= lished at the domain name. Records that are too

format, one has t= o take into account an= y other TXT records published

long to fit in a sing= le UDP packet MAY = be silently ignored by SPF

at the domain name. = Records that are too long to fit in a single UDP

clients.

packet could be silently ignored by SPF= verifiers due to firewall and

other issues that cau= se DNS over TCP to be less reliable than DNS

3.1.5. Wildcard Records=

over UDP.

<= /td>

=

Use of wildcard r= ecords for publishing is not recommended. Care must

3.5. Wildcard Records

be taken if wildcard = records are used. If a domain publishes

wildcard MX records, = it may want to publish wildcard declarations,

subject to the same r= equirements and problems. In particular, the

declaration must be r= epeated for any host that has any RR records at

all, and for subdomai= ns thereof. For example, the example given in

[RFC1034], Section 4.= 3.3, could be extended with the following:

=

X.COM.= MX 10 = A.X.COM

Use of wildcard r= ecords for publishing is discouraged and care has to

X.COM. T= XT "v=3Dspf1 a:A.X.COM -all"

be taken if they are = used. If a zone includes wildcard MX records,

it might want to publ= ish wildcard declarations, subject to the same

requirements and prob= lems. In particular, the declaration MUST be

repeated for any host= that has any RR records at all, and for

subdomains thereof. = Consider the example in [RFC1034], Section

4.3.3. Based on that= , we can do the following:

=

*.X.COM. MX 10 A.X.COM

EXAMPLE.COM.<= /span> MX 10 = A.EXAMPLE.COM

*.X.COM. TXT "v=3Dspf1 = a:A.X.COM -all&quo= t;

EXAMPLE.COM. TXT "v=3D= spf1 a:A.EXAMPLE.COM

=

A.X.COM. = A 1.2.3.4

*.EXAMPLE.COM= . MX 10 = A.EXAMPLE.COM

A.X.COM. MX 10 = A.X= .COM

*.EXAMPLE.COM. TXT "v=3D= spf1 a:A.EXAMPLE.COM

A.X.COM. TXT "v=3Dspf1 = a:A.X.COM -all&quo= t;

=

*.A.X.COM. MX 10 A.X.COM

A.EXAMPLE.COM= . A 203.0.113.1

*.A.X.COM.= TXT "v=3Dspf1 = a:A.X.COM -all&quo= t;

A.EXAMPLE.COM. MX 10 <= /span>A.EXAMPLE.COM

A.EXAMPLE.COM. TXT "v=3D= spf1 a:A.EXAMPLE.COM

=

Notice that SPF r= ecords must be repeated twice for every name within

*.A.EXAMPLE.C= OM. MX 10 A.EXAMPLE.COM

the domain: once for = the name, and once with a wildcard to cover the

*.A.EXAMPLE.COM. = TXT "v=3Dspf1 a:A.EXAMPLE.COM -all"

tree under the name.<= /span>

=

Use of wildcards = is discouraged in general as they cause every name

SPF records have = to be listed twice for= every name within the zone:

under the domain<= /span> to exist and queries= against arbitrary names will

once for the name, an= d once with a wildcard to cover the tree under

never return RCODE 3 = (Name Error).

the name, in orde= r to cover all dom= ains in use in outgoing mail.

4. The check_host() Fun= ction

4. The check_host() Fun= ction

=

This description = is not an API (Application Program Interface)

definition, but rathe= r a function description used to illustrate the

algorithm. A complia= nt SPF implementation MUST do something

semantically equivale= nt to this description.

=

The check_host() func= tion fetches SPF records, parses them, and

The check_host() func= tion fetches SPF records, parses them, and

=

interpret<= span style=3D" font-family:'monospace';">s them to determine whether a = particular host is or is not

evaluates them to determine whether a p= articular host is or is not

permitted to send mai= l with a given identity. Mail receivers that

permitted to send mai= l with a given identity. Mail receivers that

perform this check MU= ST correctly evaluate the check_host() function

perform this check MU= ST correctly evaluate the check_host() function

as described here.

as described here.

Implementations MAY u= se a different algorithm than the canonical

Implementations MAY u= se a different algorithm than the canonical

algorithm defined her= e, so long as the results are the same in all

algorithm defined her= e, so long as the results are the same in all

cases.

cases.

4.1. Arguments

4.1. Arguments

= skipping to c= hange at pa= ge 13, line 12

= skipping to c= hange at pa= ge 17, line 40

informatio= n; initially, the domain portion of the "MAIL

informatio= n; initially, the domain portion of the "MAIL

FROM"= or "HELO" identity.

FROM"= or "HELO" identity.

<sender> - the = "MAIL FROM" or "HELO" identity.

<sender> - the = "MAIL FROM" or "HELO" identity.

The domain portion of= <sender> will usually be the same as the

The domain portion of= <sender> will usually be the same as the

<domain> argume= nt when check_host() is initially evaluated. However,

<domain> argume= nt when check_host() is initially evaluated. However,

this will generally n= ot be true for recursive evaluations (see

this will generally n= ot be true for recursive evaluations (see

Section 5.2 below).

Section 5.2 below).

=

Actual implementa= tions of the check_host() function may need

additional arguments.=

=

4.2. Results

=

4.2. Results

=

The function check_ho= st() can return one of several results described

The function check_ho= st() can return one of several results described

in Section 2.5. Base= d on the result, the action to be taken is

in Section 2.5. Base= d on the result, the action to be taken is

determined by the loc= al policies of the receiver.

determined by the loc= al policies of the receiver.

4.3. Initial Processing=

4.3. Initial Processing=

=

If the <domain>= is malformed (labelzero-

If the <domain>= is malformed (e.g. label longer than 63 characters,

length label not at the end, etc.) or is no= t a fully qualified domain

zero-length label not at the end, etc.)= or is not a fully qualified

name, or if the DNS l= ookup returns "domain does not exist" (RCODE 3),

domain name, or if th= e DNS lookup returns "domain does not exist"

check_host() immediat= ely returns the result "None".

(RCODE 3), check_host= () immediately returns the result "none".

Properly formed domai= ns are fully qualified email domains as

described in [RFC5321= ] Section 2.3.5. Internationalized domain names

MUST be encoded as A-= labels, as described in Section 2.3 of

[RFC5890].on 2.3 of [= RFC5890].

=

If the <sender>= has no localpart,= substitute the string "postmaster"

If the <sender>= has no local-part, substitute the string "postmaster"

for the localpart= .

for the local-par= t.

4.4. Record Lookup

4.4. Record Lookup

=

In accordance with ho= w the records are published (see Section 3.1

In accordance with ho= w the records are published (see Section 3

above), a DNS query n= eeds to be made for the <domain> name, querying

above), a DNS query n= eeds to be made for the <domain> name, querying

=

for either RR type TXT, SPF, or both= . If both SPF and TXT= RRs are

for type TXT <= span style=3D" font-family:'monospace'; background-color:#88ffff;">only= .

looked up, the querie= s MAY be done in parallel.

If all DNS lookups th= at are made return a server failure (RCODE 2),

If all DNS lookups th= at are made return a server failure (RCODE 2),

or other error (RCODE= other than 0 or 3), or time out, then

or other error (RCODE= other than 0 or 3), or time out, then

=

check_host() <= span style=3D" font-family:'monospace'; background-color:#aaccff;">exit= s immediately with the= result "TempError".

check_host() <= span style=3D" font-family:'monospace'; background-color:#88ffff;">term= inates immediately wit= h the result "temperror".

Alternatively, for a = server failure (RCODE 2) result, check_host()

MAY track failures an= d treat multiple failures within 24 hours for

the same domain as &q= uot;permerror".

This alternative is i= ntended to shorten the queue time of messages

that cannot be accept= ed, by returning a permanent negative completion

reply code to the cli= ent, instead of a transient one. [RFC2308]

suggests on an algori= thm for doing such tracking and handling of

server failure codes.=

4.5. Selecting Records<= /span>

4.5. Selecting Records<= /span>

Records begin with a = version section:

Records begin with a = version section:

record =3D = version terms *SP

record =3D = version terms *SP

version =3D = "v=3Dspf1"

version =3D = "v=3Dspf1"

Starting with the set= of records that were returned by the lookup,

Starting with the set= of records that were returned by the lookup,

=

record selection = proceeds in two steps:

discard records that do not begin with = a version section of exactly

"v=3Dspf1&qu= ot;. Note that the ve= rsion section is terminated either by an

1. Records that do not begin with a version= section of exactly

SP character or the e= nd of the record. A record with a version

"v=3Dspf1= " are discarded. = Note that the version section is

section of "v=3D= spf10" does not match and MUST be discarded.

terminated either = by an SP character or the end of the record. A

record with a vers= ion section of "v=3Dspf10" does not match and must=

be discarded.

=

2. If any records= of type SPF are in the set, then all records of

type TXT are disca= rded.

After the above steps= , there should be exactly one record remaining

and evaluation can pr= oceed. If there are two or more records

remaining, then check= _host() exits immediately with the result of

"PermError"= .

=

If no matching re= cords are returned, an SPF client MUST assume that

If the resultant = record set includes no= records, check_host()

the domain makes<= /span> no SPF declarations.= SPF processing MUST stop and

produces the "no= ne" result. If the resultant record set includes

return "None&quo= t;.

more than one record,= check_host() produces the "permerror" result.

4.6. Record Evaluation<= /span>

4.6. Record Evaluation<= /span>

=

After one SPF rec= ord has been selected, the

The check_host() function parses and in= terprets the SPF record to

parses and interprets= it to find a resu= lt for the current test. If

find a result for the= current test. If there are any syntax errors,

there are any syntax = errors, check_host() returns immediately with

check_host() returns = immediately with the result "permerror".

the result "= PermError".

Implementations MAY c= hoose to parse the entire record first and

Implementations MAY c= hoose to parse the entire record first and

=

return "<= span style=3D" font-family:'monospace'; background-color:#aaccff;">Perm= Error" if the rec= ord is not syntactically well formed.

return "<= span style=3D" font-family:'monospace'; background-color:#88ffff;">perm= error" if the rec= ord is not syntactically well formed.

However, in all cases= , any syntax errors anywhere in the record MUST

However, in all cases= , any syntax errors anywhere in the record MUST

be detected.

be detected.

4.6.1. Term Evaluation<= /span>

4.6.1. Term Evaluation<= /span>

There are two types o= f terms: mechanisms and modifiers. A record

There are two types o= f terms: mechanisms and modifiers. A record

contains an ordered l= ist of these as specified in the following

contains an ordered l= ist of these as specified in the following

Augmented Backus-Naur= Form (ABNF).

Augmented Backus-Naur= Form (ABNF).

terms =3D = *( 1*SP ( directive / modifier ) )

terms =3D = *( 1*SP ( directive / modifier ) )

directive =3D = [ qualifier ] mechanism

directive =3D = [ qualifier ] mechanism

qualifier =3D = "+" / "-" / "?" / "~"

qualifier =3D = "+" / "-" / "?" / "~"

mechanism =3D = ( all / include

mechanism =3D = ( all / include

/ = A / MX / PTR / IP4 / IP6 / exists )

/ = A / MX / PTR / IP4 / IP6 / exists )

modifier =3D = redirect / explanation / unknown-modifier

modifier =3D = redirect / explanation / unknown-modifier

unknown-modifier =3D = name "=3D" macro-string

unknown-modifier =3D = name "=3D" macro-string

=

; = where name is not any known modifier

name =3D = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." = )

name =3D = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." = )

Most mechanisms allow= a ":" or "/" character after the name.

<= /td>

Most mechanisms allow= a ":" or "/" character after the name.

<= /td>

Modifiers always cont= ain an equals ('=3D') character immediately after

Modifiers always cont= ain an equals ('=3D') character immediately after

=

the name, and before = any ":" or "/" characters that may be part of

the name, and before = any ":" or "/" characters that might be part of

the macro-string.

the macro-string.

Terms that do not con= tain any of "=3D", ":", or "/" are mechan= isms, as

Terms that do not con= tain any of "=3D", ":", or "/" are mechan= isms, as

defined in Section 5.=

defined in Section 5.=

=

As per the definition= of the ABNF notation in [RFC4234], mechanism

As per the definition= of the ABNF notation in [RFC5234], mechanism

and modifier names ar= e case-insensitive.

and modifier names ar= e case-insensitive.

4.6.2. Mechanisms

4.6.2. Mechanisms

Each mechanism is con= sidered in turn from left to right. If there

Each mechanism is con= sidered in turn from left to right. If there

are no more mechanism= s, the result is specified in Section 4.7.

are no more mechanism= s, the result is specified in Section 4.7.

When a mechanism is e= valuated, one of three things can happen: it can

When a mechanism is e= valuated, one of three things can happen: it can

=

match, not match, or = throw an exception= .

match, not match, or = return an exceptio= n.

If it matches, proces= sing ends and the qualifier value is returned as

If it matches, proces= sing ends and the qualifier value is returned as

the result of that re= cord. If it does not match, processing

the result of that re= cord. If it does not match, processing

=

continues with the ne= xt mechanism. If it throws an exception,

continues with the ne= xt mechanism. If it returns an exception,

mechanism processing = ends and the exception value is returned.

mechanism processing = ends and the exception value is returned.

=

The possible qualifie= rs, and the results they return are as follows:

The possible qualifie= rs, and the results they cause check_host() to

return are as follows= :

=

"+" = Pass

"+" = pass

"-" = Fail

"-" = fail

"~" = SoftFail

"~" = softfail

"?" = Neutral

"?" = neutral

The qualifier is opti= onal and defaults to "+".

The qualifier is opti= onal and defaults to "+".

=

When a mechanism matc= hes and the qualifier is "-", then a "Fail"

When a mechanism matc= hes and the qualifier is "-", then a "fail"

result is returned an= d the explanation string is computed as

result is returned an= d the explanation string is computed as

described in Section = 6.2.

described in Section = 6.2.

The specific mechanis= ms are described in Section 5.

The specific mechanis= ms are described in Section 5.

4.6.3. Modifiers=

4.6.3. Modifiers=

=

Modifiers are not mechanisms: they do n= ot return match or not-match.

Modifiers are not mechanisms. They do = not return match or not-match.

Instead they provide additional informa= tion. Although modifiers do

Instead, they provide additional inform= ation. Although modifiers do

not directly affect t= he evaluation of the record, the "redirect"

not directly affect t= he evaluation of the record, the "redirect"

modifier has an effec= t after all the mechanisms have been evaluated.

modifier has an effec= t after all the mechanisms have been evaluated.

=

4.6.4. DNS Lookup Limit= s

SPF implementations M= UST limit the number of mechanisms and modifiers

("terms") t= hat cause any DNS query to at most 10 during SPF

evaluation. Specific= ally, the "include", "a", "mx", "ptr= ", and

"exists" me= chanisms as well as the "redirect" modifier count against

this limit. The &quo= t;all", "ip4", and "ip6" mechanisms do not cou= nt

against this limit. = If this number is exceeded during a check, a

permerror MUST be ret= urned. The "exp" modifier does not count

against this limit be= cause the DNS lookup to fetch the explanation

string occurs after t= he SPF record evaluation has been completed.

When evaluating the &= quot;mx" and "ptr" mechanisms, or the %{p} macro,=

there MUST be a limit= of no more than 10 MX or PTR RRs looked up and

checked. If more tha= n 10 "mx" or "ptr" records are returned for this

further lookup, a per= merror MUST be returned. This limit is per

mechanism or macro in= the record and in addition to the lookup limits

above.

MTAs or other process= ors SHOULD impose a limit on the maximum amount

of elapsed time to ev= aluate check_host(). Such a limit SHOULD allow

at least 20 seconds. = If such a limit is exceeded, the result of

authorization SHOULD = be "temperror".

=

4.7. Default Result

4.7. Default Result

If none of the mechan= isms match and there is no "redirect" modifier,

If none of the mechan= isms match and there is no "redirect" modifier,

=

then the check_host()= returns a result of "Neutral", just as if

then the check_host()= returns a result of "neutral", just as if

"?all" were= specified as the last directive. If there is a

"?all" were= specified as the last directive. If there is a

"redirect" = modifier, check_host() proceeds as defined in Section 6.1.

"redirect" = modifier, check_host() proceeds as defined in Section 6.1.

Note that records SHO= ULD always use either a "redirect" modifier or

Note that records SHO= ULD always use either a "redirect" modifier or

=

an "all" me= chanism to explicitly terminate processing.

an "all" me= chanism to explicitly terminate processing. Although the

latter has default (s= pecifically "?all"), it aids debugging efforts

if it is explicitly i= ncluded.

For example:

For example:

v=3Dspf1 +mx -all<= /span>

v=3Dspf1 +mx -all<= /span>

or

or

v=3Dspf1 +mx redir= ect=3D_spf.example.com

v=3Dspf1 +mx redir= ect=3D_spf.example.com

4.8. Domain Specificati= on

4.8. Domain Specificati= on

=

Several of these mech= anisms and modifiers have a <domain-spec>

Several of these mech= anisms and modifiers have a domain-spec section.

section. The = <= ;domain-spec> strin= g is macro expanded (see Section 8).

The domain-spec string is subject t= o macro expansion<= /span> (see Section 8).

The resulting string = is the common presentation form of a fully-

The resulting string = is the common presentation form of a fully-

qualified DNS name: a= series of labels separated by periods. This

qualified DNS name: a= series of labels separated by periods. This

domain is called the = <target-name> in the rest of this document.

domain is called the = <target-name> in the rest of this document.

Note: The result of t= he macro expansion is not subject to any further

Note: The result of t= he macro expansion is not subject to any further

escaping. Hence, thi= s facility cannot produce all characters that

escaping. Hence, thi= s facility cannot produce all characters that

are legal in a DNS la= bel (e.g., the control characters). However,

are legal in a DNS la= bel (e.g., the control characters). However,

this facility is powe= rful enough to express legal host names and

this facility is powe= rful enough to express legal host names and

common utility labels= (such as "_spf") that are used in DNS.

common utility labels= (such as "_spf") that are used in DNS.

For several mechanism= s, the <domain-spec> is optional. If it is not

For several mechanism= s, the <domain-spec> is optional. If it is not

=

provided, the <dom= ain> is used as the <target-name>.

provided, the <dom= ain> is used as the <target-name>. Domain and

<= /td>

domain-spec are synta= ctically identical after macro expansion.

Domain is an input va= lue for check_host() while domain-spec is

computed by check_hos= t().

Note: Historically, t= his document has made no provisions for how to

handle domain-specs, = or macro-expansions thereof, that are

syntactically invalid= per [RFC1035], such as names with empty labels

(e.g., "foo..exa= mple.com") or overlong labels (more than 63

characters). Some im= plementations choose to treat as a no-match

mechanisms, and ignor= e modifiers, with such names, whereas others

return a "permer= ror" exception. The outcome for an unexpected

domain-spec without m= acros might even differ from that for an

unexpected target-nam= e after macro expansion.

5. Mechanism Definition= s

5. Mechanism Definition= s

This section defines = two types of mechanisms.

This section defines = two types of mechanisms.

Basic mechanisms cont= ribute to the language framework. They do not

Basic mechanisms cont= ribute to the language framework. They do not

specify a particular = type of authorization scheme.

specify a particular = type of authorization scheme.

all

all

include

=

include

=

Designated sender mec= hanisms are used to designate a set of <ip>

Designated sender mec= hanisms are used to designate a set of <ip>

addresses as being pe= rmitted or not permitted to use the <domain> for

addresses as being pe= rmitted or not permitted to use the <domain> for

sending mail.<= /p>

sending mail.<= /p>

a

a

mx

mx

=

ptr

ptr (deprecate= d)

ip4

ip4

ip6

ip6

exists

<= /td>

exists

<= /td>

The following convent= ions apply to all mechanisms that perform a

The following convent= ions apply to all mechanisms that perform a

comparison between &l= t;ip> and an IP address at any point:

comparison between &l= t;ip> and an IP address at any point:

=

If no CIDR-length= is given in the direc= tive, then <ip> and the IP

If no CIDR prefix= length is given in th= e directive, then <ip> and the

address are compared = for equality. (Here, CIDR is Classless Inter-

IP address are compar= ed for equality. (Here, CIDR is Classless

Domain Routing.)

Inter-Domain Rout= ing, described in [RFC4632].)

=

If a CIDR-length<= /span> is specified, then onl= y the specified number of

If a CIDR prefix = length is specified, t= hen only the specified number

high-order bits of &l= t;ip> and the IP address are compared for equality.

of high-order bits of= <ip> and the IP address are compared for

equality.

<= /td>

When any mechanism fe= tches host addresses to compare with <ip>, when

When any mechanism fe= tches host addresses to compare with <ip>, when

=

<ip> is an IPv4= address, A records are fetched, when <ip> is an IPv6

<ip> is an IPv4= address, A records are fetched; when <ip> is an IPv6

address, AAAA records= are fetched. Even if the SMTP connection is

address, AAAA records= are fetched. Even if the SMTP connection uses

via IPv6, an IPv4-mapped IPv6 IP address (s= ee [RFC3513], Sect= ion

IPv6, an IPv4-mapped = IPv6 IP address (see [RFC4291], Section 2.5.5)

2.5.5) MUST still be = considered an IPv4 address.

MUST still be conside= red an IPv4 address and MUST be evaluated using

IPv4 mechanisms (i.e.= "ip4" and "a").

=

Several mechanisms re= ly on information fetched from DNS. For these

Several mechanisms re= ly on information fetched from the DNS. For

DNS queries, except w= here noted, if the DNS server returns an error

these DNS queries, ex= cept where noted, if the DNS server returns an

(RCODE other than 0 o= r 3) or the query times out, the mechanism

error (RCODE other th= an 0 or 3) or the query times out, the mechanism

throws the exception "TempErro= r". If the serve= r returns "domain does

stops and<= span style=3D" font-family:'monospace';"> the topmost check_host() = returns "temperror". If the

not exist" (RCOD= E 3), then evaluation of the mechanism continues as

server returns "= domain does not exist" (RCODE 3), then evaluation of

if the server returne= d no error (RCODE 0) and zero answer records.

the mechanism continu= es as if the server returned no error (RCODE 0)

and zero answer recor= ds.

5.1. "all"

5.1. "all"

all =3D = "all"

all =3D = "all"

The "all" m= echanism is a test that always matches. It is used as the

The "all" m= echanism is a test that always matches. It is used as the

rightmost mechanism i= n a record to provide an explicit default.

rightmost mechanism i= n a record to provide an explicit default.

For example:

For example:

v=3Dspf1 a mx -all=

v=3Dspf1 a mx -all=

=

Mechanisms after &quo= t;all" will never be tested. Any "redirect" modifier

Mechanisms after &quo= t;all" will never be tested. Mechanisms listed after

(Section 6.1) = has= no effect when there = is an "all" mechanism.

"all" MUST = be ignored. Any "= ;redirect" modifier (Section 6.1) MUST be

ignored when there is an "all"

5.2. "include"= ;

5.2. "include"= ;

=

include =3D "include&q= uot; ":" domain-spec

include =3D = "include" ":" domain-spec

The "include&quo= t; mechanism triggers a recursive evaluation of

The "include&quo= t; mechanism triggers a recursive evaluation of

=

check_host(). The do= main-spec is expanded as per Section 8. Then

check_host().<= /p>

check_host() is evaluated with the resultin= g string as the <domain>.

=

The <ip> and &l= t;sender> arguments remain the same as in the current

1. The domain-spec is expanded as per = Section 8.

evaluation of check_h= ost().

=

2. Check_host()<= /span> is evaluated with the = resulting string as the

<domain>. = The <ip> and <sender> arguments remain the same as in

the current evalu= ation of check_host().

=

3. The recursive= evaluation returns either match, not match, or an

error. If it mat= ches, then the appropriate result for the

include: mechanis= m is used (e.g. include or +include gives a

"pass" = result and -include gives "fail).

4. If there is no ma= tch, the parent check_host() resumes processing

as per the table = below, with the previous value of <domain>

restored.<= /p>

In hindsight, the nam= e "include" was poorly chosen. Only the

In hindsight, the nam= e "include" was poorly chosen. Only the

evaluated result of t= he referenced SPF record is used, rather than

evaluated result of t= he referenced SPF record is used, rather than

acting as if the refe= renced SPF record was literally included in the

acting as if the refe= renced SPF record was literally included in the

first. For example, = evaluating a "-all" directive in the referenced

first. For example, = evaluating a "-all" directive in the referenced

record does not termi= nate the overall processing and does not

record does not termi= nate the overall processing and does not

=

necessarily result in= an overall "Fail". (Better names for this

necessarily result in= an overall "fail". (Better names for this

mechanism would have = been "if-pass", "on-pass", etc.)

mechanism would have = been "if-match", "on-match", etc.)

The "include&quo= t; mechanism makes it possible for one domain to designate

The "include&quo= t; mechanism makes it possible for one domain to designate

multiple administrati= vely-independent domains. For example, a vanity

multiple administrati= vely-independent domains. For example, a vanity

domain "example.= net" might send mail using the servers of

domain "example.= net" might send mail using the servers of

administratively-inde= pendent domains example.com and example.org.

administratively-inde= pendent domains example.com and example.org.

Example.net could say=

Example.net could say=

IN TXT "v=3Ds= pf1 include:example.com include:example.org -all"

IN TXT "v=3Ds= pf1 include:example.com include:example.org -all"

This would direct che= ck_host() to, in effect, check the records of

This would direct che= ck_host() to, in effect, check the records of

=

example.com and examp= le.org for a "P

example.com and examp= le.org for a "p

were not permitted fo= r either of those domains would the result be

were not permitted fo= r either of those domains would the result be

=

"Fail".

"fail".

=

Whether this mechanis= m matches, does not match, or throws an

Whether this mechanis= m matches, does not match, or returns an

exception depends on = the result of the recursive evaluation of

exception depends on = the result of the recursive evaluation of

check_host():<= /p>

check_host():<= /p>

+--------------------= -------------+---------------------------------+

+--------------------= -------------+---------------------------------+

| A recursive check_h= ost() result | Causes the "include" mechanism |

| A recursive check_h= ost() result | Causes the "include" mechanism |

| of: = | to: |

| of: = | to: |

+--------------------= -------------+---------------------------------+

+--------------------= -------------+---------------------------------+

=

| Pass | match= |

| pass | match= |

| = | |

| = | |

=

| Fail | not m= atch |

| fail | not m= atch |

| = | |

| = | |

=

| SoftFail | not m= atch |

| softfail | not m= atch |

| = | |

| = | |

=

| Neutral | not m= atch |

| neutral | not m= atch |

| = | |

| = | |

=

| TempError = | throw TempError |

| temperror = | return temperror |

| = | |

| = | |

=

| PermError = | throw PermError |

| permerror = | return permerror |

| = | |

| = | |

=

| None = | throw PermError |

| none = | return permerror |

+--------------------= -------------+---------------------------------+

+--------------------= -------------+---------------------------------+

The "include&quo= t; mechanism is intended for crossing administrative

The "include&quo= t; mechanism is intended for crossing administrative

=

boundaries. <= span style=3D" font-family:'monospace'; background-color:#aaccff;">Alth= ough it is possible to use includes to consolidate

boundaries. For exam= ple, if example.com and example.org were managed

multiple domains that= share the same set of designated hosts, domains

by the same entity, a= nd if the permitted set of hosts for both

are encouraged to use= redirects where possible, and to minimize the

domains was

number of includes wi= thin a single administrative domain. For

example, if example.c= om and example.org were managed by the same

entity, and if the pe= rmitted set of hosts for both domains was

"mx:example.com&= quot;, it would be possible for example.org to specify

"mx:example.com&= quot;, it would be possible for example.org to specify

"include:example= .com", but it would be preferable to specify

"include:example= .com", but it would be preferable to specify

"redirect=3Dexam= ple.com" or even "mx:example.com".

"redirect=3Dexam= ple.com" or even "mx:example.com".

=

With the "in= clude" mechanism an administratively external set of

hosts can be authoriz= ed, but determination of sender policy is still

a function of the ori= ginal domain's SPF record (as determined by the

"all" mecha= nism in that record). The redirect modifier is more

suitable for consolid= ating both authorizations and policy into a

common set to be shar= ed within an ADMD. Redirect is much more like a

common code element t= o be shared among records in a single ADMD. It

is possible to contro= l both authorized hosts and policy for an

arbitrary number of d= omains from a single record.

=

5.3. "a"

5.3. "a"

This mechanism matche= s if <ip> is one of the <target-name>'s IP

This mechanism matche= s if <ip> is one of the <target-name>'s IP

addresses.

=

addresses.

=

=

A =3D "a" = [ ":" domain-spec ] [ dual-cidr-length ]

a =3D "a" = [ ":" domain-spec ] [ dual-cidr-length ]

An address lookup is = done on the <target-name>. The <ip> is compared

=

An address lookup is = done on the <target-name>. The <ip> is compared

=

to the returned addre= ss(es). If any address matches, the mechanism

to the returned addre= ss(es). If any address matches, the mechanism

matches.

matches.

5.4. "mx"

5.4. "mx"

This mechanism matche= s if <ip> is one of the MX hosts for a domain

This mechanism matche= s if <ip> is one of the MX hosts for a domain

name.

name.

=

MX =3D "mx" = [ ":" domain-spec ] [ dual-cidr-length ]

mx =3D "mx" = [ ":" domain-spec ] [ dual-cidr-length ]

check_host() first pe= rforms an MX lookup on the <target-name>. Then

check_host() first pe= rforms an MX lookup on the <target-name>. Then

it performs an addres= s lookup on each MX name returned. The <ip> is

it performs an addres= s lookup on each MX name returned. The <ip> is

compared to each retu= rned IP address. To prevent Denial of Service

compared to each retu= rned IP address. To prevent Denial of Service

(DoS) attacks, more t= han 10 MX names MUST NOT be looked up during the

(DoS) attacks, more t= han 10 MX names MUST NOT be looked up during the

=

evaluation of an &quo= t;mx" mechanism10).

evaluation of an &quo= t;mx" mechanism. If there are more than 10 MX names

matches, the mechanis= m matches.

then permerror is ret= urned and the evaluation terminated (see

Section 4.6.4). If any address matches= , the mechanism matches.

Note regarding implic= it MXs: If the <target-name> has no MX records,

Note regarding implic= it MXs: If the <target-name> has no MX records,

check_host() MUST NOT= pretend the target is its single MX, and MUST

check_host() MUST NOT= pretend the target is its single MX, and MUST

=

NOT default to an A l= ookup on the <target-name> directly. This

NOT default to an A <= /span>or AAAA lookup on t= he <target-name> directly.

behavior breaks w= ith the legacy "i= mplicit MX" rule. See [RFC2821],

This behavior = div= erges from the legacy = "implicit MX" rule, (See

Section 5. If such b= ehavior is desired, the publisher should specify

[RFC5321], Section 5. If such behavior is = desired, the publisher

an "a" = directive.

will have to specify an "a" <= /span>directive).

=

5.5. "ptr"

5.5. "ptr" (deprecated)

This mechanism tests = whether the DNS reverse-mapping for <ip> exists

This mechanism tests = whether the DNS reverse-mapping for <ip> exists

and correctly points = to a domain name within a particular domain.

and correctly points = to a domain name within a particular domain.

=

This mechanism is dep= recated and SHOULD NOT be used.

=

PTR =3D "ptr" = [ ":" domain-spec ]

ptr =3D "ptr" = [ ":" domain-spec ]

=

First, the= <ip>'s name is looked = up using this procedure: perform a

The <ip>'s name is looked up usin= g this procedure:

DNS reverse-mapping f= or <ip>, looking up the corresponding PTR record

in "in-addr.arpa= ." if the address is an IPv4 one and in "ip6.arpa."

if it is an IPv6 addr= ess. For each record returned, validate the

domain name by lookin= g up its IP address. To prevent DoS attacks,

more than 10 PTR name= s MUST NOT be looked up during the evaluation of

a "ptr" mec= hanism (see Section 10). If <ip> is among the returned IP=

addresses, then that = domain name is validated. In pseudocode:

=

sending-domain_na= mes :=3D ptr_lookup(sending-host_IP); if more than 10

1. Perform a DNS= reverse-mapping for <= /span><ip>: Look up the corresponding

sending-domain_names = are found, use at most 10.each name in

PTR record= in "in-addr.arpa.&q= uot; if the addres= s is an IPv4 one and

(sending-domain_n= ames) {

in "ip6.arpa= ." if it is an IPv6 address.

IP_addresses :=3D a= _lookup(name);

if the sending-= domain_IP is one o= f the IP_addresses {

validated-sending= -domain_names +=3D name;

} }

=

Check all validated d= omain names to see if they end in the

2. For each reco= rd returned, validate the domain name by looking up

<target-name> d= omain. If any do, this mechanism matches. If no

its IP addresses.= To prevent DoS attacks, more than 10 PTR names

validated domain name= can be found, or if none of the validated

MUST NOT be looke= d up during the evaluation of a "ptr" mechanism

domain names <= span style=3D" font-family:'monospace'; background-color:#aaccff;">end = in the <target-name= >, this mechanism fails to match.

(see Section 4.6.= 4).

If a DNS error occurs= while doing the PTR RR lookup, then this

mechanism fails to ma= tch. If a DNS error occurs while doing an A RR

3. If <ip> is = among the returned IP addresses, then that domain name

lookup, then that dom= ain name is skipped and the search continues.

is validated.

=

Check all validated d= omain names to see if they either match the

<target-name> d= omain or are a subdomain of the <target-name> domain.

If any do, this mecha= nism matches. If no validated domain name can

be found, or if none = of the validated domain names match or are a

subdomain of the <target-name>, this = mechanism fails to match. If a

DNS error occurs whil= e doing the PTR RR lookup, then this mechanism

fails to match. If a= DNS error occurs while doing an A RR lookup,

then that domain name= is skipped and the search continues.

Pseudocode:

Pseudocode:

=

sending-domain_na= mes :=3D ptr_lookup(sending-host_IP);

if more than 10 sendi= ng-domain_names are found, use at most 10.

for each name in (sen= ding-domain_names) {

IP_addresses :=3D a= _lookup(name);

if the sending-doma= in_IP is one of the IP_addresses {

validated-sending= -domain_names +=3D name;

}

}

=

for each name in (val= idated-sending-domain_names) {

for each name in (val= idated-sending-domain_names) {

if name ends in <= ;domain-spec>, return match.

if name ends in <= ;domain-spec>, return match.

if name is <doma= in-spec>, return match.

if name is <doma= in-spec>, return match.

}

}

return no-match.

return no-match.

=

This mechanism matche= s if the <target-name> is either an ancestor of

This mechanism matche= s if the <target-name> is either a subdomain of

a validated domain na= me or if the <target-name> and a validated

a validated domain na= me or if the <target-name> and a validated

domain name are the s= ame. For example: "mail.example.com" is within

domain name are the s= ame. For example: "mail.example.com" is within

the domain "exam= ple.com", but "mail.bad-example.com" is not.

<= /td>

the domain "exam= ple.com", but "mail.bad-example.com" is not.

<= /td>

=

Note: Use of this= mechanism is discouraged because it is slow, it is

Note: This mechan= ism has been deprecate= d because it is slow, it is

not as reliable as ot= her mechanisms in cases of DNS errors, and it

not as reliable as ot= her mechanisms in cases of DNS errors, and it

=

places a large burden= on the arpa name = servers. If used, proper PTR

places a large burden= on the .arpa name= servers. If used, proper PTR

records must be in place for the domain= 's hosts and the "ptr"

records MUST be in place for the domain= 's hosts and the "ptr"

mechanism should<= /span> be one of the last mec= hanisms checked.

mechanism SHOULD<= /span> be one of the last mec= hanisms checked. After many

years of SPF deployme= nt experience it has been concluded it is

unnecessary and more = reliable alternatives used instead. It is,

however, still in use= and part of the SPF protocol, so compliant

check_host() implemen= tations MUST support it.

5.6. "ip4" an= d "ip6"

5.6. "ip4" an= d "ip6"

These mechanisms test= whether <ip> is contained within a given IP

These mechanisms test= whether <ip> is contained within a given IP

network.

network.

=

IP4 =3D "ip4" = ":" ip4-network [ ip4-cidr-length ]

ip4 =3D "ip4" = ":" ip4-network [ ip4-cidr-length ]

IP6 =3D "ip6" = ":" ip6-network [ ip6-cidr-length ]

ip6 =3D "ip6" = ":" ip6-network [ ip6-cidr-length ]

ip4-cidr-length =3D = "/" 1*DIGIT

ip4-cidr-length =3D = "/" 1*DIGIT

ip6-cidr-length =3D = "/" 1*DIGIT

ip6-cidr-length =3D = "/" 1*DIGIT

dual-cidr-length =3D = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

dual-cidr-length =3D = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

ip4-network =3D = qnum "." qnum "." qnum "." qnum

ip4-network =3D = qnum "." qnum "." qnum "." qnum

qnum =3D = DIGIT ; 0-9

qnum =3D = DIGIT ; 0-9

/ = %x31-39 DIGIT ; 10-99

/ = %x31-39 DIGIT ; 10-99

/ = "1" 2DIGIT ; 100-199

/ = "1" 2DIGIT ; 100-199

/ = "2" %x30-34 DIGIT ; 200-249

/ = "2" %x30-34 DIGIT ; 200-249

/ = "25" %x30-35 ; 250-255

/ = "25" %x30-35 ; 250-255

; as per con= ventional dotted quad notation. e.g., 192.0.2.0

; as per con= ventional dotted quad notation. e.g., 192.0.2.0

=

ip6-network =3D = <as per [RFC 3513

ip6-network =3D = <as per [RFC 4291

; e.g., 2001= :DB8::CD30

; e.g., 2001= :DB8::CD30

=

The <ip> is com= pared to the given network. If CIDR-length high-order

The <ip> is com= pared to the given network. If CIDR prefix length

bits match, the mecha= nism matches.

high-order bits match= , the mechanism matches.

If ip4-cidr-length is= omitted, it is taken to be "/32". If

If ip4-cidr-length is= omitted, it is taken to be "/32". If

ip6-cidr-length is om= itted, it is taken to be "/128". It is not

ip6-cidr-length is om= itted, it is taken to be "/128". It is not

permitted to omit par= ts of the IP address instead of using CIDR

permitted to omit par= ts of the IP address instead of using CIDR

notations. That is, = use 192.0.2.0/24 instead of 192.0.2.

notations. That is, = use 192.0.2.0/24 instead of 192.0.2.

5.7. "exists"=

5.7. "exists"=

This mechanism is use= d to construct an arbitrary domain name that is

This mechanism is use= d to construct an arbitrary domain name that is

used for a DNS A reco= rd query. It allows for complicated schemes

used for a DNS A reco= rd query. It allows for complicated schemes

= skipping to c= hange at pa= ge 22, line 34

= skipping to c= hange at pa= ge 28, line 15

Domains can use this = mechanism to specify arbitrarily complex

Domains can use this = mechanism to specify arbitrarily complex

queries. For example= , suppose example.com publishes the record:

queries. For example= , suppose example.com publishes the record:

v=3Dspf1 exists:%{= ir}.%{l1r+-}._spf.%{d} -all

v=3Dspf1 exists:%{= ir}.%{l1r+-}._spf.%{d} -all

The <target-name&g= t; might expand to

The <target-name&g= t; might expand to

"1.2.0.192.someu= ser._spf.example.com". This makes fine-grained

"1.2.0.192.someu= ser._spf.example.com". This makes fine-grained

decisions possible at= the level of the user and client IP address.

decisions possible at= the level of the user and client IP address.

This mechanism enable= s queries that mimic the style of tests that

This mechanism enable= s queries that mimic the style of tests that

=

existing anti-spa= m DNS blacklists (= DNSBL) use.

existing DNS <= span style=3D" font-family:'monospace'; background-color:#88ffff;">whit= e/black lists (DNSxLs) use, as described in

[RFC5782]. The query= will either return NXDOMAIN (no match), any

valid answer (match),= or an error.

6. Modifier Definitions=

6. Modifier Definitions=

Modifiers are name/va= lue pairs that provide additional information.

Modifiers are name/va= lue pairs that provide additional information.

Modifiers always have= an "=3D" separating the name and the value.

Modifiers always have= an "=3D" separating the name and the value.

The modifiers defined= in this document ("redirect" and "exp") MAY=

The modifiers defined= in this document ("redirect" and "exp") MAY=

appear anywhere in th= e record, but SHOULD appear at the end, after

appear anywhere in th= e record, but SHOULD appear at the end, after

all mechanisms. Orde= ring of these two modifiers does not matter.

all mechanisms. Orde= ring of these two modifiers does not matter.

These two modifiers M= UST NOT appear in a record more than once each.

These two modifiers M= UST NOT appear in a record more than once each.

=

If they do, then chec= k_host() exits with a result of "PermError".

If they do, then chec= k_host() exits with a result of "permerror".

Unrecognized modifier= s MUST be ignored no matter where in a record,

Unrecognized modifier= s MUST be ignored no matter where in a record,

or how often. This a= llows implementations of this document to

or how often. This a= llows implementations of this document to

gracefully handle rec= ords with modifiers that are defined in other

gracefully handle rec= ords with modifiers that are defined in other

specifications.

specifications.

6.1. redirect: Redirect= ed Query

6.1. redirect: Redirect= ed Query

=

If all mechanisms= fail to match, and a = "redirect" modifier is

The redirect modi= fier is intended for consolidating both

present, then pro= cessing proceeds as follows:

authorizations= and policy into a common set to be shared = within a

single ADMD. Redirec= t is like a common= code element to be shared

among records in a si= ngle ADMD. It is possible to control both

authorized hosts and = policy for an arbitrary number of domains from a

single record.=

redirect =3D = "redirect" "=3D" domain-spec

redirect =3D = "redirect" "=3D" domain-spec

=

If all mechanisms= fail to match, and a "redirect" modifier is

present, then process= ing proceeds as follows:

=

The domain-spec porti= on of the redirect section is expanded as per

The domain-spec porti= on of the redirect section is expanded as per

the macro rules in Se= ction 8. Then check_host() is evaluated with

the macro rules in Se= ction 8. Then check_host() is evaluated with

the resulting string = as the <domain>. The <ip> and <sender>

the resulting string = as the <domain>. The <ip> and <sender>

=

arguments remain the = same as current evaluation of check_host().

arguments remain the = same as in the cur= rent evaluation of

check_host().<= /p>

The result of this ne= w evaluation of check_host() is then considered

The result of this ne= w evaluation of check_host() is then considered

the result of the cur= rent evaluation with the exception that if no

the result of the cur= rent evaluation with the exception that if no

SPF record is found, = or if the target-name is malformed, the result

SPF record is found, = or if the target-name is malformed, the result

=

is a "PermEr= ror" rather than "None".

is a "permer= ror" rather than "none".

=

Note that the newly-q= ueried domain may = itself specify redirect

Note that the newly-q= ueried domain can = itself specify redirect

processing.

processing.

This facility is inte= nded for use by organizations that wish to apply

This facility is inte= nded for use by organizations that wish to apply

the same record to mu= ltiple domains. For example:

the same record to mu= ltiple domains. For example:

la.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

la.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

ny.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

ny.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

sf.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

sf.example.com. TXT= "v=3Dspf1 redirect=3D_spf.example.com"

_spf.example.com. TXT= "v=3Dspf1 mx:example.com -all"

_spf.example.com. TXT= "v=3Dspf1 mx:example.com -all"

In this example, mail= from any of the three domains is described by

In this example, mail= from any of the three domains is described by

the same record. Thi= s can be an administrative advantage.

the same record. Thi= s can be an administrative advantage.

Note: In general, the= domain "A" cannot reliably use a redirect to

Note: In general, the= domain "A" cannot reliably use a redirect to

another domain "= B" not under the same administrative control. Since

another domain "= B" not under the same administrative control. Since

the <sender> st= ays the same, there is no guarantee that the record at

the <sender> st= ays the same, there is no guarantee that the record at

domain "B" = will correctly work for mailboxes in domain "A",

domain "B" = will correctly work for mailboxes in domain "A",

=

especially if domain = "B" uses mechanisms involving localparts. An

especially if domain = "B" uses mechanisms involving local-parts. An

"include" d= irective may be mo= re appropriate.

"include" d= irective is generally be more appropriate.

For clarity, it is RE= COMMENDED that any "redirect" modifier appear as

For clarity, it is RE= COMMENDED that any "redirect" modifier appear as

the very last term in= a record.

the very last term in= a record.

6.2. exp: Explanation

6.2. exp: Explanation

explanation =3D = "exp" "=3D" domain-spec

explanation =3D = "exp" "=3D" domain-spec

=

If check_host() resul= ts in a "Fail= " due to a mechanism match (such as

If check_host() resul= ts in a "fail= " due to a mechanism match (such as

"-all"), an= d the "exp" modifier is present, then the explanation<= /p>

"-all"), an= d the "exp" modifier is present, then the explanation<= /p>

string returned is co= mputed as described below. If no "exp" modifier

string returned is co= mputed as described below. If no "exp" modifier

is present, then eith= er a default explanation string or an empty

is present, then eith= er a default explanation string or an empty

=

explanation string be returned.

explanation string be returned.

=

The <domain-sp= ec> is macro expand= ed (see Section 8) and becomes the

The domain-spec is macro expanded (see = Section 8) and becomes the

<target-name>. = The DNS TXT record for the <target-name> is fetched.

<= /td>

<target-name>. = The DNS TXT record for the <target-name> is fetched.

<= /td>

=

If <domain-spe= c> is empty, or the= re are any DNS processing errors

If there are any DNS = processing errors (any RCODE other than 0), or

(any RCODE other than= 0), or if no records are returned, or if more

if no records are ret= urned, or if more than one record is returned,

than one record is re= turned, or if there are syntax errors in the

or if there are synta= x errors in the explanation string, then proceed

explanation string, t= hen proceed as if no exp modifier was given.

as if no exp modifier= was given.

The fetched TXT recor= d's strings are concatenated with no spaces, and

The fetched TXT recor= d's strings are concatenated with no spaces, and

=

then treated as an

then treated as an , whic= h is macro-expanded. This

final result is the e= xplanation string. Implementations MAY limit

final result is the e= xplanation string. Implementations MAY limit

the length of the res= ulting explanation string to allow for other

the length of the res= ulting explanation string to allow for other

protocol constraints = and/or reasonable processing limits. Since the

protocol constraints = and/or reasonable processing limits. Since the

=

explanation string is= intended for an SMTP response and [RFC2821]

explanation string is= intended for an SMTP response and [RFC5321]

Section 2.4 says that= responses are in [US-ASCII], the explanation

Section 2.4 says that= responses are in [US-ASCII], the explanation

=

string is also limited to US-ASCII.

string MUST be limited to US-ASCII.

Software evaluating c= heck_host() can use this string to communicate

Software evaluating c= heck_host() can use this string to communicate

information from the = publishing domain in the form of a short message

information from the = publishing domain in the form of a short message

or URL. Software SHO= ULD make it clear that the explanation string

or URL. Software SHO= ULD make it clear that the explanation string

comes from a third pa= rty. For example, it can prepend the macro

comes from a third pa= rty. For example, it can prepend the macro

=

string "%{o} exp= lains: " to the explanation, such as shown in Section

string "%{o} exp= lains: " to the explanation, such as shown in

2.5.4.

Section 2.5.4.=

Suppose example.com h= as this record:

Suppose example.com h= as this record:

v=3Dspf1 mx -all e= xp=3Dexplain._spf.%{d}

v=3Dspf1 mx -all e= xp=3Dexplain._spf.%{d}

Here are some example= s of possible explanation TXT records at

Here are some example= s of possible explanation TXT records at

explain._spf.example.= com:

explain._spf.example.= com:

"Mail from ex= ample.com should only be sent by its own servers."

"Mail from ex= ample.com should only be sent by its own servers."

=

-- a simple, co= nstant message

-- = a simple, constant message

"%{i} is not = one of %{d}'s designated mail servers."

"%{i} is not = one of %{d}'s designated mail servers."

=

-- a message wi= th a little more information, including the IP

-- a message w= ith a little more information, including the IP

address that= failed the check

address tha= t failed the check

"See http://%= {d}/why.html?s=3D%{S}&i=3D%{I}"

"See http://%= {d}/why.html?s=3D%{S}&i=3D%{I}"

=

-- a complicate= d example that constructs a URL with the

-- a complicat= ed example that constructs a URL with the

arguments to= check_host() so that a web page can be

arguments t= o check_host() so that a web page can be

generated wi= th detailed, custom instructions

generated w= ith detailed, custom instructions

Note: During recursio= n into an "include" mechanism, an exp=3D modifier

<= /td>

Note: During recursio= n into an "include" mechanism, an exp=3D modifier

<= /td>

from the <target-n= ame> MUST NOT be used. In contrast, when executing

from the <target-n= ame> MUST NOT be used. In contrast, when executing

a "redirect"= ; modifier, an exp=3D modifier from the original domain MUST

=

a "redirect"= ; modifier, an exp=3D modifier from the original domain MUST

=

NOT be used.

NOT be used.

=

7. The Received-SPF = Header Field

7. Recording The Res= ult

=

It is RECOMMENDED that SMTP receivers r= ecord the result of SPF

To provide downst= ream agents, such as MUAs, with the information they

processing in the mes= sage header. If an SMTP receiver chooses to do

might need in terms o= f evaluating or representing the apparent safety

so, it SHOULD use the "Received-SP= F" header field d= efined here for

of the message conten= t, it is RECOMMENDED t= hat SMTP receivers record

each identity tha= t was checked. Th= is information is = intended for the

the result of SPF pro= cessing in the message header. For operators

recipient. (Informat= ion intended for t= he sender is described in

that choose to record SPF results in the header of the me= ssage for

Section 6.2, Explanat= ion.)

processing by interna= l filters or MUAs, two methods are presented.

Section 7.1 defines t= he Received-SPF field, which is the results

field originally<= /span> defined for SPF us= e. Section 7.2 discusses

Authentication-Result= s [RFC5451] which was = specified more recently

and is designed for use by SPF and other authentication m= ethods.

=

The Received-SPF head= er field is a trace field (see [RFC2822] Section

Both are in commo= n use, and hence both are included here. However,

it is important to no= te that they were designed to serve slightly

different purposes. = Received-SPF is intended to include enough

forensic information = to enable reconstruction of the SPF evaluation

of the message, while= Authentication-Results is designed only to

relay the result itse= lf and related output details of likely use to

end users (e.g., what= property of the message was actually

authenticated and wha= t it contained), leaving forensic work to the

purview of system log= s and the Received field contents. Also,

Received-SPF relies o= n compliance of agents within the receiving ADMD

to adhere to the head= er field ordering rules of [RFC5321] and

[RFC5322], while Auth= entication-Results includes some provisions to

protect against non-c= ompliant implementations.

An operator could cho= ose to use both to serve different downstream

agents. In such case= s, care needs to be taken to ensure both fields

are conveying the sam= e details, or unexpected results can occur.

7.1. The Received-SPF H= eader Field

=

The Received-SPF head= er field is a trace field (see [RFC5322] Section

3.6.7) and SHOULD be = prepended to the existing header, above the

3.6.7) and SHOULD be = prepended to the existing header, above the

Received: field that = is generated by the SMTP receiver. It MUST

Received: field that = is generated by the SMTP receiver. It MUST

appear above all othe= r Received-SPF fields in the message. The

appear above all othe= r Received-SPF fields in the message. The

header field has the = following format:

header field has the = following format:

header-field =3D = "Received-SPF:" [CFWS] result FWS [comment FWS]

header-field =3D = "Received-SPF:" [CFWS] result FWS [comment FWS]

[ = key-value-list ] CRLF

[ = key-value-list ] CRLF

=

result =3D = "Pass" /= "Fail" = / "SoftFail""Neutral" /

result =3D = "pass" /= "fail" = / "softfail""neutral" /

/ <= /span>"TempError""PermError"

/ <= /span>"temperror""permerror"

key-value-list =3D = key-value-pair *( ";" [CFWS] key-value-pair )

key-value-list =3D = key-value-pair *( ";" [CFWS] key-value-pair )

[&= quot;;"]

[&= quot;;"]

key-value-pair =3D = key [CFWS] "=3D" ( dot-atom / quoted-string )

key-value-pair =3D = key [CFWS] "=3D" ( dot-atom / quoted-string )

key =3D = "client-ip" / "envelope-from" / "helo" /<= /span>

key =3D = "client-ip" / "envelope-from" / "helo" /<= /span>

&q= uot;problem" / "receiver" / "identity" /

&q= uot;problem" / "receiver" / "identity" /

=

m= echanism / "x-" name / name

m= echanism / name

identity =3D = "mailfrom" ; for the "MAIL FROM" identity<= /p>

identity =3D = "mailfrom" ; for the "MAIL FROM" identity<= /p>

/ = "helo" ; for the "HELO" identity

/ = "helo" ; for the "HELO" identity

/ = name ; other identities

/ = name ; other identities

=

dot-atom =3D = <unquoted word as per [RFC2822]>

dot-atom =3D = <unquoted word as per [RFC5322]>

quoted-string =3D = <quoted string as per [RFC2822]>

quoted-string =3D = <quoted string as per [RFC5322]>

comment =3D = <comment string as per

comment =3D = <comment string as per CFWS =3D = <comment or folding white space as per [RFC2822]>

<= /td>

CFWS =3D = <comment or folding white space as per [RFC5322]>

<= /td>

FWS =3D = <folding white space as per [RFC2822]>

FWS =3D = <folding white space as per [RFC5322]>

CRLF =3D = <standard end-of-line token as per [RFC2822]>

CRLF =3D = <standard end-of-line token as per [RFC2532]>

=

The header field SHOU= LD include a "(...)" style <comment> after the

The header field SHOU= LD include a "(...)" style comment after the

result, conveying sup= porting information for the result, such as

result, conveying sup= porting information for the result, such as

<ip>, <sende= r>, and <domain>.

<ip>, <sende= r>, and <domain>.

The following key-val= ue pairs are designed for later machine parsing.

The following key-val= ue pairs are designed for later machine parsing.

=

SPF client= s SHOULD give enough informat= ion so that the SPF results

SPF verifiers SHOULD give enough inform= ation so that the SPF results

can be verified. Tha= t is, at least "client-ip", "helo", and, if the

can be verified. Tha= t is, at least "client-ip", "helo", and, if the

"MAIL FROM"= identity was checked, "envelope-from".

"MAIL FROM"= identity was checked, "envelope-from".

client-ip the IP= address of the SMTP client

client-ip the IP= address of the SMTP client

envelope-from the en= velope sender mailbox

envelope-from the en= velope sender mailbox

helo the ho= st name given in the HELO or EHLO command

helo the ho= st name given in the HELO or EHLO command

mechanism the me= chanism that matched (if no mechanisms matched,

mechanism the me= chanism that matched (if no mechanisms matched,

substi= tute the word "default")

substi= tute the word "default")

problem if an = error was returned, details about the error

problem if an = error was returned, details about the error

=

=

receiver the ho= st name of the SPF verifier

receiver the ho= st name of the SPF client

identity the id= entity that was checked; see the <identity> ABNF

identity the id= entity that was checked; see the <identity> ABNF

rule

rule

=

Other keys may be defined by SPF cl= ients. Until a new key name

Other keys MAY be defined by SPF ve= rifiers.

becomes widely accept= ed, new key names should start with "x-".

=

SPF clients MUST make sure that the Rec= eived-SPF header field does

SPF verifiers MUST make sure that the R= eceived-SPF header field does

not contain invalid c= haracters, is not excessively long, and does not

not contain invalid c= haracters, is not excessively long (See

contain malicious dat= a that has been provided by the sender.

[RFC5322] Section 2.1= .1), and does not cont= ain malicious data that

has been provided by = the sender.

=

Examples of various h= eader styles that could be generated are the

Examples of various h= eader field styles= that could be generated are

following:

=

the following:=

=

Received-SPF: = Pass (mybox.example.org: = domain of

Received-SPF: = pass (mybox.example.org: = domain of

myname@example.com d= esignates 192.0.2.1 as permitted sender)

myname@example.com d= esignates 192.0.2.1 as permitted sender)

receiver=3Dmybox.= example.org; client-ip=3D192.0.2.1;

receiver=3Dmybox.= example.org; client-ip=3D192.0.2.1;

=

envelope-from=3D<= /span><myname@example.com>; helo=3Dfoo.example.com;

envelope-from=3D<= /span>"myname@example.com"; helo=3Dfoo.example.com;

=

Received-SPF: = Fail (mybox.example.org: = domain of

Received-SPF: = fail (mybox.example.org: = domain of

myn= ame@example.com does not designate

myn= ame@example.com does not designate

192= .0.2.1 as permitted sender)

192= .0.2.1 as permitted sender)

ide= ntity=3Dmailfrom; client-ip=3D192.0.2.1;

ide= ntity=3Dmailfrom; client-ip=3D192.0.2.1;

=

envelope-from=3D<myname@example.com>;

envelope-from=3D"myname@example.com";

7.2. SPF Results in the= Authentication-Results Header Field

As mentioned in Secti= on 7, the Authentication-Results header field is

designed to communica= te lists of tests a border MTA did and their

results. The specifi= ed elements of the field provide less

information than the = SPF-Received field:

Authentication-Result= s: myhost.example.org; spf=3Dpass

smtp.mailfrom=3Dexa= mple.net

Received-SPF: pass (m= yhost.example.org: domain of

myname@example.com d= esignates 192.0.2.1 as permitted sender)

receiver=3Dmybox.= example.org; client-ip=3D192.0.2.1;

envelope-from=3D&= quot;myname@example.com"; helo=3Dfoo.example.com;

It is, however, possi= ble to add CFWS in the "reason" part of an

Authentication-Result= s header field and provide the equivalent

information, if desir= ed.

As an example, an exp= anded Authentication-Results header field might

look like (for a &quo= t;MAIL FROM" check in this example):

Authentication-Result= s: myhost.example.org; spf=3Dpass

reason=3D"clie= nt-ip=3D192.0.2.1; smtp.helo=3Dfoo.example.com"

smtp.mailfrom=3Duse= r@example.net

8. Macros

8. Macros

8.1. Macro Definitions<= /span>

8.1. Macro Definitions<= /span>

=

Many mechanisms and m= odifiers perform macro expansion on part of the

Many mechanisms and m= odifiers perform macro expansion on a term.

term.

domain-spec =3D = macro-string domain-end

domain-spec =3D = macro-string domain-end

domain-end =3D = ( "." toplabel [ "." ] ) / macro-expand

<= /td>

domain-end =3D = ( "." toplabel [ "." ] ) / macro-expand

<= /td>

toplabel =3D = ( *alphanum ALPHA *alphanum ) /

toplabel =3D = ( *alphanum ALPHA *alphanum ) /

( = 1*alphanum "-" *( alphanum / "-" ) alphanum )

( = 1*alphanum "-" *( alphanum / "-" ) alphanum )

; = LDH rule plus additional TLD restrictions

; = LDH rule plus additional TLD restrictions

=

; = (see [RFC3696], Section 2)

; = (see [RFC3696], Section 2 for background)

alphanum =3D = ALPHA / DIGIT

alphanum =3D = ALPHA / DIGIT

explain-string =3D = *( macro-string / SP )

explain-string =3D = *( macro-string / SP )

macro-string =3D = *( macro-expand / macro-literal )

macro-string =3D = *( macro-expand / macro-literal )

macro-expand =3D = ( "%{" macro-letter transformers *delimiter "}" )

macro-expand =3D = ( "%{" macro-letter transformers *delimiter "}" )

/ = "%%" / "%_" / "%-"

/ = "%%" / "%_" / "%-"

macro-literal =3D = %x21-24 / %x26-7E

macro-literal =3D = %x21-24 / %x26-7E

; = visible characters except "%"

; = visible characters except "%"

macro-letter =3D = "s" / "l" / "o" / "d" / "i= " / "p" / "h" /

macro-letter =3D = "s" / "l" / "o" / "d" / "i= " / "p" / "h" /

=

&q= uot;c" / "r" / "t"

&q= uot;c" / "r" / "t" / "v"<= /p>

transformers =3D = *DIGIT [ "r" ]

transformers =3D = *DIGIT [ "r" ]

delimiter =3D = "." / "-" / "+" / "," / "/= " / "_" / "=3D"

delimiter =3D = "." / "-" / "+" / "," / "/= " / "_" / "=3D"

A literal "%&quo= t; is expressed by "%%".

A literal "%&quo= t; is expressed by "%%".

"%_" exp= ands to a single " " space.

"%_" exp= ands to a single " " space.

"%-" exp= ands to a URL-encoded space, viz., "%20".

"%-" exp= ands to a URL-encoded space, viz., "%20".

The following macro l= etters are expanded in term arguments:

The following macro l= etters are expanded in term arguments:

s =3D <sender&g= t;

s =3D <sender&g= t;

l =3D local-part o= f <sender>

l =3D local-part o= f <sender>

o =3D domain of &l= t;sender>

o =3D domain of &l= t;sender>

d =3D <domain&g= t;

d =3D <domain&g= t;

i =3D <ip>

i =3D <ip>

=

p =3D the validate= d domain name of <ip>

p =3D the validate= d domain name of <ip> (deprecated)

v =3D the string &= quot;in-addr" if <ip> is ipv4, or "ip6" if <ip&= gt; is ipv6

v =3D the string &= quot;in-addr" if <ip> is ipv4, or "ip6" if <ip&= gt; is ipv6

h =3D HELO/EHLO do= main

h =3D HELO/EHLO do= main

The following macro l= etters are allowed only in "exp" text:

The following macro l= etters are allowed only in "exp" text:

c =3D SMTP client = IP (easily readable format)

c =3D SMTP client = IP (easily readable format)

r =3D domain name = of host performing the check

r =3D domain name = of host performing the check

t =3D current time= stamp

t =3D current time= stamp

A '%' character not f= ollowed by a '{', '%', '-', or '_' character is

A '%' character not f= ollowed by a '{', '%', '-', or '_' character is

= skipping to c= hange at pa= ge 28, line 13

= skipping to c= hange at pa= ge 37, line 7

h =3D HELO/EHLO do= main

h =3D HELO/EHLO do= main

The following macro l= etters are allowed only in "exp" text:

The following macro l= etters are allowed only in "exp" text:

c =3D SMTP client = IP (easily readable format)

c =3D SMTP client = IP (easily readable format)

r =3D domain name = of host performing the check

r =3D domain name = of host performing the check

t =3D current time= stamp

t =3D current time= stamp

A '%' character not f= ollowed by a '{', '%', '-', or '_' character is

A '%' character not f= ollowed by a '{', '%', '-', or '_' character is

a syntax error. So

a syntax error. So

=

=

-exists:%(ir).sbl.= spamhaus.example.org

-exists:%(ir).sbl.= spamhaus.example.org

=

=

is incorrect and will= cause check_host() to yield a "permerror".

is incorrect and will= cause check_host() to return a "PermError".

Instead, say

Instead, say

=

=

-exists:%{ir}.sbl.= spamhaus.example.org

-exists:%{ir}.sbl.= spamhaus.example.org

Optional transformers= are the following:

Optional transformers= are the following:

*DIGIT =3D zero or= more digits

*DIGIT =3D zero or= more digits

'r' =3D reverse= value, splitting on dots by default

'r' =3D reverse= value, splitting on dots by default

If transformers or de= limiters are provided, the replacement value for

If transformers or de= limiters are provided, the replacement value for

a macro letter is spl= it into parts. After performing any reversal

a macro letter is spl= it into parts. After performing any reversal

operation and/or remo= val of left-hand parts, the parts are rejoined

operation and/or remo= val of left-hand parts, the parts are rejoined

= skipping to c= hange at pa= ge 28, line 32

= skipping to c= hange at pa= ge 37, line 23

*DIGIT =3D zero or= more digits

*DIGIT =3D zero or= more digits

'r' =3D reverse= value, splitting on dots by default

'r' =3D reverse= value, splitting on dots by default

If transformers or de= limiters are provided, the replacement value for

If transformers or de= limiters are provided, the replacement value for

a macro letter is spl= it into parts. After performing any reversal

a macro letter is spl= it into parts. After performing any reversal

operation and/or remo= val of left-hand parts, the parts are rejoined

operation and/or remo= val of left-hand parts, the parts are rejoined

using "." a= nd not the original splitting characters.

using "." a= nd not the original splitting characters.

By default, strings a= re split on "." (dots). Note that no special

By default, strings a= re split on "." (dots). Note that no special

=

treatment is given to= leading, trailing, or consecutive delimiters,

treatment is given to= leading, trailing, or consecutive delimiters in

and so the list of pa= rts may contain em= pty strings. Older

input strings,= and so the list of parts might contain empty s= trings.

implementations of SP= F prohibit trailing dots in domain names, so

Some older= implementations of SPF prohi= bit trailing dots in domain

trailing dots = sho= uld not be published b= y domain owners, although they

names, so trailing do= ts SHOULD NOT be p= ublished by domain owners,

must be accepted by implementations con= forming to this document.

although they = MUS= T be accepted by imple= mentations conforming to this

Macros may= specify delimiter characters= that are used instead of ".".

document. Macros can specify delimiter= characters that are used

instead of ".&qu= ot;.

The 'r' transformer i= ndicates a reversal operation: if the client IP

The 'r' transformer i= ndicates a reversal operation: if the client IP

address were 192.0.2.= 1, the macro %{i} would expand to "192.0.2.1"

address were 192.0.2.= 1, the macro %{i} would expand to "192.0.2.1"

and the macro %{ir} w= ould expand to "1.2.0.192".

and the macro %{ir} w= ould expand to "1.2.0.192".

The DIGIT transformer= indicates the number of right-hand parts to

The DIGIT transformer= indicates the number of right-hand parts to

use, after optional r= eversal. If a DIGIT is specified, the value

use, after optional r= eversal. If a DIGIT is specified, the value

MUST be nonzero. If = no DIGITs are specified, or if the value

MUST be nonzero. If = no DIGITs are specified, or if the value

specifies more parts = than are available, all the available parts are

specifies more parts = than are available, all the available parts are

used. If the DIGIT w= as 5, and only 3 parts were available, the macro

used. If the DIGIT w= as 5, and only 3 parts were available, the macro

interpreter would pre= tend the DIGIT was 3. Implementations MUST

interpreter would pre= tend the DIGIT was 3. Implementations MUST

support at least a va= lue of 128, as that is the maximum number of

support at least a va= lue of 128, as that is the maximum number of

labels in a domain na= me.

labels in a domain na= me.

=

The "s" mac= ro expands to the <sender> argument. It is an E-Mail<= /p>

The "s" mac= ro expands to the <sender> argument. It is an email

address with a lo= calpart, an "@&qu= ot; character, and a domain. The "l"

address with a lo= cal-part, an "@&q= uot; character, and a domain. The "l"

macro expands to just= the localpart. T= he "o" macro expands to just

macro expands to just= the local-part. = The "o" macro expands to just

the domain part. Not= e that these values remain the same during

the domain part. Not= e that these values remain the same during

recursive and chained= evaluations due to "include" and/or "redirect".

recursive and chained= evaluations due to "include" and/or "redirect".

=

Note also that if the= original <sender> had no localpart, the

Note also that if the= original <sender> had no local-part, the local-

localpart<= span style=3D" font-family:'monospace';"> was set to "postmaster&q= uot; in initial processing (see Section

part was set to "postmaster" in i= nitial processing (see Section 4.3).

4.3).

For IPv4 addresses, b= oth the "i" and "c" macros expand to the

=

For IPv4 addresses, b= oth the "i" and "c" macros expand to the

=

standard dotted-quad = format.

standard dotted-quad = format.

For IPv6 addresses, t= he "i" macro expands to a dot-format address; it

For IPv6 addresses, t= he "i" macro expands to a dot-format address; it

=

is intended for use i= n %{ir}. The "c" macro may expand to any of the

is intended for use i= n %{ir}. The "c" macro can expand to any of the

hexadecimal colon-for= mat addresses specified in [RFC3513], Section

hexadecimal colon-for= mat addresses specified in [RFC4291], Section

2.2. It is intended = for humans to read.

2.2. It is intended = for humans to read.

The "p" mac= ro expands to the validated domain name of <ip>. The

<= /td>

The "p" mac= ro expands to the validated domain name of <ip>. The

<= /td>

=

procedure for finding= the validated domain name is defined in Section

procedure for finding= the validated domain name is defined in

5.5. If the <doma= in> is present in the list of validated domains, it

Section 5.5. If the = <domain> is present in the list of validated

SHOULD be used. Othe= rwise, if a subdomain of the <domain> is

domains, it SHOULD be= used. Otherwise, if a subdomain of the

present, it SHOULD be= used. Otherwise, any name from the list may be

<domain> is pre= sent, it SHOULD be used. Otherwise, any name from the

used. If there are n= o validated domain names or if a DNS error

list can be used. If there are no vali= dated domain names or if a DNS

occurs, the string &q= uot;unknown" is used.

error occurs, the str= ing "unknown" is used. This macro is deprecated

and SHOULD NOT be used.

The "r" mac= ro expands to the name of the receiving MTA. This SHOULD

The "r" mac= ro expands to the name of the receiving MTA. This SHOULD

be a fully qualified = domain name, but if one does not exist (as when

be a fully qualified = domain name, but if one does not exist (as when

the checking is done = by a MUA) or if policy restrictions dictate

the checking is done = by a MUA) or if policy restrictions dictate

otherwise, the word &= quot;unknown" SHOULD be substituted. The domain name

otherwise, the word &= quot;unknown" SHOULD be substituted. The domain name

=

may be different from the name found in= the MX record that the client

can be different from the name found in= the MX record that the client

MTA used to locate th= e receiving MTA.

MTA used to locate th= e receiving MTA.

The "t" mac= ro expands to the decimal representation of the

The "t" mac= ro expands to the decimal representation of the

approximate number of= seconds since the Epoch (Midnight, January 1,

approximate number of= seconds since the Epoch (Midnight, January 1,

=

1970, UTC). This is the same value as = is returned by the POSIX

1970, UTC) at the= time of the evaluation.

time() function in mo= st standards-compliant libraries.

is returned by the PO= SIX time() function in most standards-compliant

libraries.

=

When the result of ma= cro expansion is used in a domain name query, if

When the result of ma= cro expansion is used in a domain name query, if

the expanded domain n= ame exceeds 253 characters (the maximum length

the expanded domain n= ame exceeds 253 characters (the maximum length

of a domain name), th= e left side is truncated to fit, by removing

of a domain name), th= e left side is truncated to fit, by removing

=

successive domain lab= els until the total length does not exceed 253

successive domain lab= els (and their following dots) until the total

characters.

length does not excee= d 253 characters.

Uppercased macros exp= and exactly as their lowercased equivalents, and

Uppercased macros exp= and exactly as their lowercased equivalents, and

=

are then URL escaped.= URL escaping must be performed for characters

are then URL escaped.= URL escaping MUST be performed for characters

not in the "= uric" set, which = is defined in [RFC3986].

not in the "= unreserved" set, = which is defined in [RFC3986].

=

Note: Care must be taken so that macro = expansion for legitimate

Note: Care has to= be taken so that macr= o expansion for legitimate

E-Mail does not exceed the 63-character= limit on DNS labels. The

email does not exceed the 63-character = limit on DNS labels. The

localpart<= span style=3D" font-family:'monospace';"> of E-Mail addresses, in particular, can have mo= re than 63

local-part= of email addresses, in particular, can have mo= re than 63

characters between do= ts.

characters between do= ts.

=

Note: Domains = sho= uld avoid using the &q= uot;s", "l", "o", or "h" macros in

Note: Domains = SHO= ULD avoid using the &q= uot;s", "l", "o", or "h" macros in

conjunction with any = mechanism directive. Although these macros are

conjunction with any = mechanism directive. Although these macros are

powerful and allow pe= r-user records to be published, they severely

powerful and allow pe= r-user records to be published, they severely

limit the ability of = implementations to cache results of check_host()

limit the ability of = implementations to cache results of check_host()

and they reduce the e= ffectiveness of DNS caches.

and they reduce the e= ffectiveness of DNS caches.

=

Implementations s= hould be aware that if= no directive processed during

Note: If no directive processed during = the evaluation of check_host()

the evaluation of che= ck_host() contains an "s", "l", "o", or &= quot;h"

contains an "s&q= uot;, "l", "o", or "h" macro, then the re= sults of the

macro, then the resul= ts of the evaluation can be cached on the basis

evaluation can be cac= hed on the basis of <domain> and <ip> alone for

<= /td>

of <domain> and= <ip> alone for as long as the shortest Time To Live

as long as the shorte= st Time To Live (TTL) of all the DNS records

(TTL) of all the DNS = records involved.

involved.

<= /td>

8.2. Expansion Examples=

8.2. Expansion Examples=

The <sender>= is strong-bad@email.example.com.

The <sender>= is strong-bad@email.example.com.

The IPv4 SMTP clie= nt IP is 192.0.2.3.

The IPv4 SMTP clie= nt IP is 192.0.2.3.

The IPv6 SMTP clie= nt IP is 2001:DB8::CB01.

The IPv6 SMTP clie= nt IP is 2001:DB8::CB01.

The PTR domain nam= e of the client IP is mx.example.org.

The PTR domain nam= e of the client IP is mx.example.org.

macro = expansion

macro = expansion

------- ------------= ----------------

------- ------------= ----------------

= skipping to c= hange at pa= ge 31, line 20

= skipping to c= hange at pa= ge 40, line 4

b= ad.strong.lp.3.2.0.192.in-addr._spf.example.com

b= ad.strong.lp.3.2.0.192.in-addr._spf.example.com

%{ir}.%{v}.%{l1r-}.lp= ._spf.%{d2}

%{ir}.%{v}.%{l1r-}.lp= ._spf.%{d2}

= 3.2.0.192.in-addr.strong.lp._spf.example.com

= 3.2.0.192.in-addr.strong.lp._spf.example.com

%{d2}.trusted-domains= .example.net

%{d2}.trusted-domains= .example.net

= example.com.trusted-domains.example.net

= example.com.trusted-domains.example.net

IPv6:

IPv6:

%{ir}.%{v}._spf.%{d2}= 1.0.B.C.0.0.0.0.

%{ir}.%{v}._spf.%{d2}= 1.0.B.C.0.0.0.0.

=

=

0.0.0.0.0.0.0.0.0.0.0= .0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com

0.0.0.0.0.0.0.0.0.0.0= .0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com

9. Implications<= /p>

9. Implications<= /p>

This section outlines= the major implications that adoption of this

This section outlines= the major implications that adoption of this

=

document will have on= various entities involved in Internet E-Mail.

document will have on= various entities involved in Internet email.

It is intended to mak= e clear to the reader where this document

It is intended to mak= e clear to the reader where this document

knowingly affects the= operation of such entities. This section is

knowingly affects the= operation of such entities. This section is

not a "how-to&qu= ot; manual, or a "best practices" document, and it is not

not a "how-to&qu= ot; manual, or a "best practices" document, and it is not

=

a comprehensive list = of what such entities should do in light of this

a comprehensive list = of what such entities SHOULD do in light of this

document.

<= /td>

document.

<= /td>

=

This section is non-n= ormative.

This section is non-n= ormative. [RFC5598] describes the Internet

email architecture. = This section is organized based on the different

segments of the archi= tecture.

9.1. Sending Domains

9.1. Sending Domains

=

Domains that wish to = be compliant with this specification will need

Originating ADMDs= (ADministrative Management Domains - [RFC5598]

to determine the list= of hosts that the= y allow to use their domain

Section 2.2.1 and Sec= tion 2.3) that wish to= be compliant with this

name in the "HEL= O" and "MAIL FROM" identities. It is recognized that

specification will ne= ed to determine the list of relays ([RFC5598]

forming such a list i= s not just a simple technical exercise, but

Section 2.2.2)= that they allow to use their= domain name in the "HELO"

involves policy decis= ions with both technical and administrative

and "MAIL FROM&q= uot; identities when relaying to other ADMDs. It is

considerations.

recognized that formi= ng such a list is not just a simple technical

exercise, but involve= s policy decisions with both technical and

administrative consid= erations.

=

It can be helpful to = publish records that include a "tracking

9.1.1. DNS Resource Con= siderations

Minimizing the DNS re= sources required for SPF lookups can be done by

choosing directives t= hat require less DNS information and by placing

lower-cost mechanisms= earlier in the SPF record.

+----------= +--------+-----------------+

| term = | cost | limit |

+----------= +--------+-----------------+

| ip4/ip6 = | 0 | - |

| a = | 1 | 10 |

| include = | 1 | 10 |

| redirect = | 1 | 10 |

| exists = | 1 | 10 |

| mx = | 1 + N* | 10 and N* <=3D 10 |

| ptr/%{p} = | 1 + N* | 10 and N* <=3D 10 |

| all = | 0 | - |

+----------= +--------+-----------------+

* N is the= number of RRs found during each term evaluation

Section 4.6.4 specifi= es the limits receivers have to use. It is

essential to publish = records that do not exceed these requirements.

It is also required t= o carefully weight the cost and the

maintainability of li= cit solutions.

For example, consider= a domain set up as follows:

example.com. I= N MX 10 mx.example.com.

I= N MX 20 mx2.example.com.

mx.example.com. I= N A 192.0.2.1

mx2.example.com. I= N A 192.0.2.129

Assume the administra= tive point is to authorize (pass) mx and mx2

while failing every o= ther host. Compare the following solutions:

Best record:

example.com. IN = TXT "v=3Dspf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"

=

Good record:

$ORIGIN example.co= m.

@ IN = TXT "v=3Dspf1 a:authorized-spf.example.com -all"

<= /td>

authorized-spf IN = A 192.0.2.1

IN = A 192.0.2.129

Expensive record:

example.com. IN = TXT "v=3Dspf1 mx:example.com -all"

Wasteful, bad record:=

example.com. IN = TXT "v=3Dspf1 ip4:192.0.2.0/24 mx -all"

9.1.2. Administrator's = Considerations

There might be admini= strative considerations: using "a" over "ip4" or

"ip6" allow= s hosts to be renumbered easily. Using "mx" over "a&quo= t;

allows the set of mai= l hosts to be changed easily. Unless such

changes are common, i= t is better to use the less resource intensive

mechanisms like "= ;ip4" and "ip6" over "a" or "a" or &= quot;mx".

In some specific case= s, standard advice on record content is

appropriate. Publish= ing SPF records for domains that send no mail is

a well established be= st practice. The record for a domain that sends

no mail is:

www.example.com. = IN TXT "v=3Dspf1 -all"

Publishing SPF record= s for individual hosts is also best practice.

The hostname is gener= ally the identity used in the 5321.HELO/.EHLO

command. In the case= of messages with a null 5321.MailFrom, this is

used as the domain fo= r 5321.MailFrom SPF checks, in addition to being

used in 5321.HELO/.EH= LO based SPF checks. The standard SPF record

for an individual hos= t that is involved in mail processing is:

relay.example.com.= IN TXT "v=3Dspf1 a -all"

Validating correct de= ployment is difficult. [RFC6652] describes one

mechanism for solicit= ing feedback on SPF failures. Another approach

that can be helpful to publish records that= include a "tracking

exists:" mechani= sm. By looking at the name server logs, a rough list

exists:" mechani= sm. By looking at the name server logs, a rough list

=

may then be generated. For example:

can then be generated. For example:

v=3Dspf1 exists:_h= .%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all

v=3Dspf1 exists:_h= .%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all

=

9.2. Mailing Lists

Regardless of the= method used, understanding the ADMD's outbound mail

architecture is essen= tial to effective deployment.

=

Mailing lists = mus= t be aware of how they= re-inject mail that is sent

9.1.3. Bounces

to the list. Mailing= lists MUST comply with the requirements in

[RFC2821],= Section 3.10, and [RFC1123],= Section 5.3.6, that say that

As explained in Secti= on 1.3.3, [RFC5321] allows the reverse-path to

be null, which is typ= ical of some Delivery Status Notification

[RFC3464], commonly c= alled email bounces. In this case the only

entity available for = performing an SPF check is the "HELO" identity

defined in Section 1.= 3.4. SPF functionality is enhanced by

administrators ensuri= ng this identity is set correctly and has an

appropriate SPF recor= d. It is normal to have the HELO identity set

to hostname instead o= f domain. Zone file generation for significant

numbers of hosts can = be consolidated using the redirect modifier and

scripted for initial = deployment. Specific deployment advice is given

above in Section 9.1.= 2.

9.2. Mediators

Broadly speaking, the= re are two types of mediating ADMDs that can

affect SPF deployment= of other ADMDs: mailing lists (see [RFC5598]

Section 5.3) and ReSe= nders ([RFC5598] Section 5.2).

9.2.1. Mailing Lists

=

Mailing lists = hav= e to be aware of how t= hey re-inject mail that is

sent to the list. Ma= iling lists MUST comply with the requirements in

[RFC5321],= Section 3.10, and [RFC1123],= Section 5.3.6, that say that

the reverse-path MUST= be changed to be the mailbox of a person or

the reverse-path MUST= be changed to be the mailbox of a person or

other entity who admi= nisters the list. Whereas the reasons for

other entity who admi= nisters the list. Whereas the reasons for

changing the reverse-= path are many and long-standing, SPF adds

changing the reverse-= path are many and long-standing, SPF adds

enforcement to this r= equirement.

enforcement to this r= equirement.

In practice, almost a= ll mailing list software in use already complies

In practice, almost a= ll mailing list software in use already complies

=

with this requirement= . Mailing lists that do not comply may or may

with this requirement= . Mailing lists that do not comply might

not encounter problems depending on how acc= ess to the list is

encounter problems de= pending on how access to the list is restricted.

restricted. Such lis= ts that are entirely internal to a domain (only

Such lists that are e= ntirely internal to a domain (only people in the

people in the domain = can send to or receive from the list) are not

domain can send to or= receive from the list) are not affected.

affected.

<= /td>

=

9.3. Forwarding Services and Aliases

9.2.2. Forwarding Services and Aliases

Forwarding services t= ake mail that is received at a mailbox and

Forwarding services t= ake mail that is received at a mailbox and

direct it to some ext= ernal mailbox. At the time of this writing, the

direct it to some ext= ernal mailbox. At the time of this writing, the

near-universal practi= ce of such services is to use the original "MAIL

near-universal practi= ce of such services is to use the original "MAIL

FROM" of a messa= ge when re-injecting it for delivery to the external

FROM" of a messa= ge when re-injecting it for delivery to the external

=

mailbox. [RFC1123] a= nd [RFC2821] descr= ibe this action as an "alias"

mailbox. [RFC1123] a= nd [RFC5321] descr= ibe this action as an "alias"

rather than a "m= ail list". This means that the external mailbox's

rather than a "m= ail list". This means the external mailbox's MTA

MTA sees all such mai= l in a connection from a host of the forwarding

sees all such mail in= a connection from a host of the forwarding

service, and so the &= quot;MAIL FROM" identity will not, in general, pass

service, and so the &= quot;MAIL FROM" identity will not, in general, pass

authorization.=

authorization.=

There are three place= s that techniques can be used to ameliorate this

There are three place= s that techniques can be used to ameliorate this

problem.

problem.

=

1. The beginning,= when E-Mail is first sent

1. The beginning= , when email is first sent (Originating ADMDs).

=

1. "Neutral&= quot; results could be given for IP addresses that may be

1. "Neutral= " results could be given for IP addresses that might

<= /td>

forwarders, in= stead of "Fail" results. For example:

be forwarders= , instead of "fail" results based on a list of

=

known reliabl= e forwarders. For exa= mple:

=

"v= =3Dspf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"

"= v=3Dspf1 mx ?exists:%{ir}.whitlist.example.org -all"

=

This would cau= se a lookup on an anti-spam DNS blacklist

This would ca= use a lookup on an DNS white list (DNSWL) and

(DNSBL)= and cause a result of &q= uot;Fail" only fo= r E-Mail coming

cause a resul= t of "fail" only for email not either coming

from liste= d sources. All other E-Mail, including E-Mail sent

from the = domain's mx host(s) (SPF pass) or white listed

through forwar= ders, would receive a "Neutral" result. By

sources (SPF = neutral). This, in effect, outsources an

checking the DNSBL after<= span style=3D" font-family:'monospace';"> the known good sources, p= roblems with

element of se= nder policy to the maintainer of the whitelist.

incorrect list= ing on the DNSBL a= re greatly reduced.

=

2. The "MAIL= FROM" identity could have additional information in

2. The "MAI= L FROM" identity could have additional information in

the localp= art that cryptographic= ally identifies the mail as

the local= -part that cryptograph= ically identifies the mail as

coming from an= authorized source. In this case, such an SPF

coming from a= n authorized source. In this case, such an SPF

record could b= e used:

record could = be used:

=

"v=3Ds= pf1 mx exists:%{l}._spf_verify.%{d} -all"

"v=3Dspf1 mx exists:%{l= }._spf_verify.%{d} -all"

=

Then, a specia= lized DNS server can be set up to serve the

Then, a speci= alized DNS server can be set up to serve the

_spf_verify su= bdomain that validates the localpart. Although

_spf_verify s= ubdomain that validates the local-part.

this requires = an extra DNS lookup, this happens only when the

Although this= requires an extra DNS lookup, this happens only

E-Mail would otherwise be reject= ed as not coming from a known

when the = email would otherwise = be rejected as not coming from

good source.

a known good = source.

Note that= due to the 63-character limit for domain labels,

this approach= only works reliably if the local-part signature

scheme is gua= ranteed either to only produce local-parts with

a maximum of = 63 characters or to gracefully handle truncated

local-parts.<= /span>

=

Note that due to the 63-char= acter limit for domain labels,

3. Similarly= , a specialized DNS server could be set up that this approach = only works reliably if= the localpart signature

rate-limit the email coming from= unexpected IP addresses.

scheme is guar= anteed either to only produce localparts with a

maximum of 63 = characters or to gracefully handle truncated

localparts.

=

3. Similarly,= a specialized DNS server could be set up that will

"= v=3Dspf1 mx exists:%{ir}._spf_rate.%{d} -all"

rate-limit the= E-Mail coming from unexpected IP addresses.

=

"v= =3Dspf1 mx exists:%{ir}._spf_rate.%{d} -all"

4. SPF allow= s the creation of per-user policies for special

cases. For e= xample, the following SPF record and appropriate

wildcard DNS = records can be used:

=

4. SPF allows= the creation of per-user policies for special

"= v=3Dspf1 mx redirect=3D%{l1r+}._at_.%{o}._spf.%{d}"

cases. For ex= ample, the following SPF record and appropriate

wildcard DNS r= ecords can be used:

=

&qu= ot;v=3Dspf1 mx redirect=3D%{l1r+}._at_.%{o}._spf.%{d}"

<= /td>

2. The middle, w= hen email is forwarded (Mediating ADMDs).

=

2. The middle, w= hen E-Mail is forwarded.

1. Forwardin= g services can solve the problem by rewriting the

"MAIL FR= OM" to be in their own domain. This means mail

rejected from= the external mailbox will have to be forwarded

back to the o= riginal sender by the forwarding service.

Various schem= es to do this exist though they vary widely in

complexity an= d resource requirements on the part of the

forwarding se= rvice.

=

1. Forwarding= services can <= span style=3D" font-family:'monospace'; background-color:#aaccff;">solv= e the problem by rewriting the

2. Several p= opular MTAs can be forced from "= ;alias" semantics= to

"MAIL FRO= M" to be <= span style=3D" font-family:'monospace'; background-color:#aaccff;">in t= heir own domain. This means that mail

"mai= ling list" semantics by configuring an additional alias

bounced= from the external mailbo= x will have to = be = re-bounced

with "ow= ner-" prepended t= o the original alias name (e.g., an

by the for= warding service. Various schemes to do this exist

alias of &quo= t;friends: george@example.com, fred@example.org"

though they va= ry widely in complexity and resource

would need an= other alias of the form "owner-friends:

requirements o= n the part<= span style=3D" font-family:'monospace';"> of the forwarding service= .

localowner&qu= ot;).

=

2. Several po= pular MTAs can be forced from "alias" semantics to

=

3. Forwardin= g servers could reject mail that would "fail" SPF if

"mailing = list" semantics by configuring an additional alias

forwarded usi= ng an SMTP reply c= ode of 551, User not local,

with "own= er-" prepended to= the original alias name (e.g., an

(see [RFC5321= ] section 3.4) to = communicate the co= rrect target

alias of "= ;friends: george@example.com, fred@example.org" would

address to re= send the mail to.<= /span>

need another a= lias of the form &= quot;owner-friends: localowner").

=

3. The end, when = E-Mail is received.

3. The end, when= email is received (Receiving ADMDs).

=

1. If the owner o= f the external mailbox wishes to trust the

1. If the owner = of the external mailbox wishes to trust the

forwarding ser= vice, he can direct the external mailbox's MTA

forwarding se= rvice, he can direct the external mailbox's MTA

to skip SPF te= sts when the client host belongs to the

to skip SPF t= ests when the client host belongs to the

forwarding ser= vice.

forwarding se= rvice.

=

2. Tests against = other identities, such as the "HELO" identity,

2. Tests against= other identities, such as the "HELO" identity,

may= be used to override a failed= test against the "MAIL FROM"

MAY be used to override a faile= d test against the "MAIL FROM"

identity.

identity.

=

3. For larger dom= ains, it may not b= e possible to have a complete

3. For larger do= mains, it might no= t be possible to have a

or accurate li= st of forwarding services used by the owners of

complete or a= ccurate list of forwarding services used by the

the domain's m= ailboxes. In such cases, whitelists of

owners of the= domain's mailboxes. In such cases, whitelists

generally-reco= gnized forwarding services could be employed.

of generally-= recognized forwarding services could be

employed.

=

9.4. Mail Services

9.2.3. Mail Services

=

Service providers= that offer mail servi= ces to third-party domains,

MSPs (Mail= Service Providers - [RFC5= 598] Section 2.3) that= offer mail

such as sending of bu= lk mail, may want = to adjust their setup in light

services to third-par= ty domains, such as sending of bulk mail, might

of the authorization = check described in this document. If the "MAIL

want to adjust their = configurations in = light of the authorization

FROM" identity u= sed for such E-Mail uses the domain of the service

check described in th= is document. If the domain part of the "MAIL

provider, then the provider needs only to e= nsure that its sending

FROM" identity u= sed for such email= uses the domain of one of the MSPs

host is authorized by= its own SPF record, if any.

domain, then the provider needs only to ens= ure that its sending host

is authorized by its = own SPF record, if any.

=

If the "MAIL FRO= M" identity does not use the mail service provider's

If the "MAIL FRO= M" identity does not use the MSP's domain, then extra

domain, then extra ca= re must be taken. = The SPF record format has

care has to be taken. The SPF record f= ormat has several options for

several options for t= he third-party domain to authorize the service

the third-party domai= n to authorize the service provider's MTAs to

provider's MTAs to se= nd mail on its behalf. For mail service

send mail on its beha= lf. For MSPs, suc= h as ISPs, that have a wide

providers, such as ISPs, that have a wide v= ariety of customers using

variety of customers = using the same MTA, steps to

the same MTA, steps <= /span>should be taken to = prevent cross-cust= omer forgery

mitiate the risk = of cross-customer forg= ery (see Section 10.4).

(see Section 10.4).

=

9.5. MTA Relays

9.2.4. MTA Relays

=

The authorization che= ck generally precludes the use of arbitrary MTA

Relays are descri= bed in [RFC5598] Section 2.2.2. The authorization

relays between sender= and receiver of an E-Mail message.

check generally precl= udes the use of arbitrary MTA relays between

sender and receiver o= f an email message= .

Within an organizatio= n, MTA relays can be effectively deployed.

Within an organizatio= n, MTA relays can be effectively deployed.

However, for purposes= of this document, such relays are effectively

However, for purposes= of this document, such relays are effectively

transparent. The SPF= authorization check is a check between border

transparent. The SPF= authorization check is a check between border

=

MTAs of different domains.

MTAs of different ADMDs.

=

For mail senders, thi= s means that published SPF records must

For mail senders, thi= s means that published SPF records have to

authorize any MTAs th= at actually send across the Internet. Usually,

authorize any MTAs th= at actually send across the Internet. Usually,

these are just the bo= rder MTAs as internal MTAs simply forward mail

these are just the bo= rder MTAs as internal MTAs simply forward mail

=

to these MTAs for delivery.

<= /td>

to these MTAs for relaying.

<= /td>

=

Mail receivers will generally want to p= erform the authorization check

The receiving ADM= D will generally want = to perform the authorization

at the border MTAs, specifically including all secondary MX= s. This

check at the <= span style=3D" font-family:'monospace'; background-color:#88ffff;">boun= dary MTAs, including a= ll secondary MXs. Internal

allows mail that fail= s to be rejected during the SMTP session rather

MTAs (including M= TAs that might serve both as boundary MTAs and

than bounced.<= span style=3D" font-family:'monospace';"> Internal MTAs then do not pe= rform the authorization

internal relays from = secondary MXs when they are processing the

test. To perform the= authorization test other than at the border,

relayed mail stream)<= /span> then do not perform th= e authorization test. To

the host that first t= ransferred the message to the organization must

perform the authoriza= tion test other than at the boundary, the host

be determined, which = can be difficult to extract from the message

that first transferre= d the message to the receiving ADMD have to be

header. Testing other than at the = border is not <= span style=3D" font-family:'monospace'; background-color:#aaccff;">reco= mmended.

determined, which can= be difficult to extract from the message header

because (a) header fi= elds can be forged or malformed, and (b) there's

no standard way to en= code that information such that it can be

reliably extracted. Testing other than at = the boundary is likely to

produce unreliable re= sults.

9.3. Receivers

SPF results can be us= ed in combination with other methods to

determine the final l= ocal disposition (either positive or negative of

a message. It can al= so be considered dispositive on its own.

9.3.1. Policy For SPF P= ass

SPF pass results can = be used in combination with "white lists" of

known "good"= ; domains to bypass some or all additional pre-delivery

email checks. Exactl= y which checks and how to determine appropriate

white list entries ha= s to be based on local conditions and

requirements.<= /p>

9.3.2. Policy For SPF F= ail

SPF fail results can = be used to reject messages during the SMTP

transaction based on = either "MAIL FROM" or "HELO" identity results.

This reduces resource= requirements for various content filtering

methods and conserves= bandwidth since rejection can be done before

the SMTP content is t= ransferred. It also gives immediate feedback to

the sender who might = then be able to resolve the issue. Due to some

of the issues describ= ed above in this section (Section 9), SPF based

rejection does presen= t some risk of rejecting legitimate email when

rejecting based on &q= uot;MAIL FROM" results.

SPF fail results can = alternately be used as one input into a larger

set of evaluations wh= ich might, based on a combination with other

evaluation techniques= , result in the email being marked negatively in

some way (this might = be via delivery to a special spam folder,

modifying subject lin= es, or other locally determined means).

Developing the detail= s of such an approach have to be based on local

conditions and requir= ements. Using SPF results in this way does not

have the advantages o= f resource conservation and immediate feedback

to the sender associa= ted with SMTP rejection, but could produce fewer

undesirable rejection= s in a well designed system. Such an approach

might result in email= that was not authorized by the sending ADMD

being unknowingly del= ivered to end users.

Either general approa= ch can be used as they both leave a clear

disposition of emails= . They are either delivered in some manner or

the sender is notifie= d of the failure. Other dispositions such as

"dropping" = or deleting email after acceptance are inappropriate

because they leave un= certainty and reduce the overall reliabilility

and utility of email = across the Internet.

9.3.3. Policy For SPF P= ermerror

The "permerror&q= uot; result (see Section 2.5.7) indicates the SPF

processing module at = the receiver determined that the retrieved SPF

policy record could n= ot be interpreted. This gives no true

indication about the = authorized use of the data found in the

envelope.

<= /td>

As with all results, = implementers have a choice to make regarding

what to do with a mes= sage that yields this result. SMTP allows only

a few basic options.<= /span>

Rejection of the mess= age is an option, in that it is the one thing a

receiver can do to dr= aw attention to the difficulty encountered while

protecting itself fro= m messages that do not have a definite SPF

result of some kind. = However, if the SPF implementation is defective

and returns spurious = "permerror" results, only the sender is actively

notified of the defec= t (in the form of rejected mail), and not the

receiver making use o= f SPF.

The less intrusive ha= ndling choice is to deliver the message, perhaps

with some kind of ann= otation of the difficulty encountered and/or

logging of a similar = nature. However, this will not be desirable to

operators that wish t= o implement SPF checking as strictly as

possible, nor is this= sort of passive problem reporting typically

effective.

=

There is of course th= e option placing this choice in the hands of the

operator rather than = the implementer since this kind of choice is

often a matter of loc= al policy rather than a condition with a

universal solution, b= ut this adds one more piece of complexity to an

already non-trivial e= nvironment.

Both implementers and= operators need to be cautious of all choices

and outcomes when han= dling SPF results.

10. Security Considerat= ions

10. Security Considerat= ions

10.1. Processing Limits=

10.1. Processing Limits=

=

As with most aspects = of E-Mail, there a= re a number of ways that

As with most aspects = of email, there ar= e a number of ways that

malicious parties cou= ld use the protocol as an avenue for a

malicious parties cou= ld use the protocol as an avenue for a

=

Denial-of-Service (Do= S) attack. The processing limits outlined here

Denial-of-Service (Do= S) attack. The processing limits outlined in

are designed to preve= nt attacks such as the following:

Section 4.6.4<= span style=3D" font-family:'monospace';"> are designed to prevent attac= ks such as the following:

o A malicious party = could create an SPF record with many references

o A malicious party = could create an SPF record with many references

=

to a victim's doma= in and send many E-Mails to different SPF

to a victim's doma= in and send many emails to different SPF

clients; those SPF clients would then create a DoS att= ack. In

verifiers; those SPF verifiers would then create a DoS= attack. In

effect, the SPF are being us= ed to amplify the attacker's

effect, the SPF are being = used to amplify the attacker's

bandwidth by using= fewer bytes in the SMTP session than are used

bandwidth by using= fewer bytes in the SMTP session than are used

by the DNS queries= . Using SPF clients also allows the attacker to

by the DNS queries= . Using SPF clients also allows the attacker to

hide the true sour= ce of the attack.

hide the true sour= ce of the attack.

o Whereas implementa= tions of check_host() are supposed to limit the

o Whereas implementa= tions of check_host() are supposed to limit the

number of DNS look= ups, malicious domains could publish records

number of DNS look= ups, malicious domains could publish records

that exceed these = limits in an attempt to waste computation effort

that exceed these = limits in an attempt to waste computation effort

at their targets w= hen they send them mail. Malicious domains

at their targets w= hen they send them mail. Malicious domains

could also design = SPF records that cause particular

could also design = SPF records that cause particular

implementations to= use excessive memory or CPU usage, or to

implementations to= use excessive memory or CPU usage, or to

trigger bugs.

trigger bugs.

o Malicious parties = could send a large volume of mail purporting to

o Malicious parties = could send a large volume of mail purporting to

come from the inte= nded target to a wide variety of legitimate mail

come from the inte= nded target to a wide variety of legitimate mail

hosts. These legi= timate machines would then present a DNS load on

hosts. These legi= timate machines would then present a DNS load on

the target as they= fetched the relevant records.

the target as they= fetched the relevant records.

Of these, the case of= a third party referenced in the SPF record is

Of these, the case of= a third party referenced in the SPF record is

the easiest for a DoS= attack to effectively exploit. As a result,

the easiest for a DoS= attack to effectively exploit. As a result,

=

limits that m<= span style=3D" font-family:'monospace'; background-color:#aaccff;">ay seem reasonable for an = individual mail server can

limits that m<= span style=3D" font-family:'monospace'; background-color:#88ffff;">ight= seem reasonable for a= n individual mail server can

still allow an unreas= onable amount of bandwidth amplification.

still allow an unreas= onable amount of bandwidth amplification.

Therefore, the proces= sing limits need to be quite low.

Therefore, the proces= sing limits need to be quite low.

=

SPF implementatio= ns MUST limit the number of mechanisms and modifiers

10.2. SPF-Authorized May Contain Ot= her False Identities

that do DNS lookups t= o at most 10 per SPF check, including any

lookups caused by the= use of the "include" mechanism or the

"redirect" = modifier. If this number is exceeded during a check, a

PermError MUST be ret= urned. The "include", "a", "mx", "p= tr", and

"exists" me= chanisms as well as the "redirect" modifier do count

against this limit. = The "all", "ip4", and "ip6" mechanisms do= not

require DNS lookups a= nd therefore do not count against this limit.

The "exp" m= odifier does not count against this limit because the DNS

lookup to fetch the e= xplanation string occurs after the SPF record

has been evaluated.

When evaluating the &= quot;mx" and "ptr" mechanisms, or the %{p} macro,=

there MUST be a limit= of no more than 10 MX or PTR RRs looked up and

checked.

SPF implementations S= HOULD limit the total amount of data obtained

from the DNS queries.= For example, when DNS over TCP or EDNS0 are

available, there may = need to be an explicit limit to how much data

will be accepted to p= revent excessive bandwidth usage or memory usage

and DoS attacks.

MTAs or other process= ors MAY also impose a limit on the maximum

amount of elapsed tim= e to evaluate check_host(). Such a limit SHOULD

allow at least 20 sec= onds. If such a limit is exceeded, the result

of authorization SHOU= LD be "TempError".

Domains publishing re= cords SHOULD try to keep the number of "include"

mechanisms and chaine= d "redirect" modifiers to a minimum. Domains

SHOULD also try to mi= nimize the amount of other DNS information

needed to evaluate a = record. This can be done by choosing directives

that require less DNS= information and placing lower-cost mechanisms

earlier in the SPF re= cord.

For example, consider= a domain set up as follows:

example.com. IN = MX 10 mx.example.com.

mx.example.com. IN = A 192.0.2.1

a.example.com. IN = TXT "v=3Dspf1 mx:example.com -all"

b.example.com. IN = TXT "v=3Dspf1 a:mx.example.com -all"

c.example.com. IN = TXT "v=3Dspf1 ip4:192.0.2.1 -all"

Evaluating check_host= () for the domain "a.example.com" requires the

MX records for "= example.com", and then the A records for the listed

hosts. Evaluating fo= r "b.example.com" requires only the A records.

Evaluating for "= c.example.com" requires none.

However, there may be= administrative considerations: using "a" over

"ip4" allow= s hosts to be renumbered easily. Using "mx" over "a&quo= t;

allows the set of mai= l hosts to be changed easily.

=

10.2. SPF-Authorized May Contain O= ther False Identities

=

The "MAIL FROM" and "HEL= O" identity authorizations must not be

Do not construe t= he "MAIL FROM&quo= t; and "HELO" identity authorizations to

construed to provide more assurance than th= ey do. It is entirely

provide more assuranc= e than they do. It is entirely possible for a

possible for a malici= ous sender to inject a message using his own

malicious sender to i= nject a message using his own domain in the

domain in the identit= ies used by SPF, to have that domain's SPF

identities used by SP= F, to have that domain's SPF record authorize

record authorize the = sending host, and yet the message can easily

the sending host, and= yet the message can easily list other

list other identities= in its header. Unless the user or the MUA

identities in its hea= der. Unless the user or the MUA takes care to

takes care to note th= at the authorized identity does not match the

note that the authori= zed identity does not match the other more

other more commonly-p= resented identities (such as the From: header

commonly-presented id= entities (such as the From: header field), the

field), the user = may be lulled into a f= alse sense of security.

user might= be lulled into a false sense= of security.

10.3. Spoofed DNS and I= P Data

10.3. Spoofed DNS and I= P Data

There are two aspects= of this protocol that malicious parties could

There are two aspects= of this protocol that malicious parties could

exploit to undermine = the validity of the check_host() function:

exploit to undermine = the validity of the check_host() function:

o The evaluation of = check_host() relies heavily on DNS. A malicious

o The evaluation of = check_host() relies heavily on DNS. A malicious

attacker could att= ack the DNS infrastructure and cause

attacker could att= ack the DNS infrastructure and cause

check_host() to se= e spoofed DNS data, and then return incorrect

check_host() to se= e spoofed DNS data, and then return incorrect

=

results. This cou= ld include returning "Pass" for an <ip> value

results. This cou= ld include returning "pass" for an <ip> value

where the actual d= omain's record would evaluate to "Fail". See

where the actual d= omain's record would evaluate to "fail". See

[RFC3833] for a de= scription of DNS weaknesses.

[RFC3833] for a de= scription of DNS weaknesses.

=

o The client IP addr= ess, <ip>, is assumed to be correct. A

o The client IP addr= ess, <ip>, is assumed to be correct. In a

malicious attacker= could spoof TCP sequence numbers to make mail

modern, correc= tly configured system = the risk of this not being

appear to come fro= m a permitted host= for a domain that the=

true is nil.

attacker is impersonating.

10.4. Cross-User Forger= y

10.4. Cross-User Forger= y

By definition, SPF po= licies just map domain names to sets of

By definition, SPF po= licies just map domain names to sets of

=

authorized MTAs, not = whole E-Mail addre= sses to sets of authorized

authorized MTAs, not = whole email addres= ses to sets of authorized

users. Although the = "l" macro (Section 8) provides a limited way to

users. Although the = "l" macro (Section 8) provides a limited way to

=

define individual set= s of authorized MTAs for specific E-Mail

define individual set= s of authorized MTAs for specific email

addresses, it is gene= rally impossible to verify, through SPF, the use

addresses, it is gene= rally impossible to verify, through SPF, the use

=

of specific E-Mail addresses by individ= ual users of the same MTA.

of specific email addresses by individu= al users of the same MTA.

It is up to mail serv= ices and their MTAs to directly prevent

It is up to mail serv= ices and their MTAs to directly prevent

=

cross-user forgery: b= ased on SMTP AUTH ([RFC2554]), users should be

cross-user forgery: b= ased on SMTP AUTH ([RFC4954]), users have to be

restricted to using o= nly those E-Mail a= ddresses that are actually

restricted to using o= nly those email ad= dresses that are actually

under their control (= see [RFC4409], Sec= tion 6.1). Another means to

under their control (= see [RFC6409], Sec= tion 6.1). Another means to

verify the identity o= f individual users is message cryptography such

verify the identity o= f individual users is message cryptography such

=

as PGP ([RFC2440]= ) or S/MIME ([RFC3851]= ).

as PGP ([RFC4880]= ) or S/MIME ([RFC5751]= ).

10.5. Untrusted Informa= tion Sources

10.5. Untrusted Informa= tion Sources

=

SPF uses information supplied by th= ird parties, such as t= he "HELO"

An SPF compliant receiver gathers information from th= e SMTP commands

domain name, the &quo= t;MAIL FROM" address, and SPF records. This

it receives and from<= /span> the published DNS = records of the sending domain

information is then p= assed to the receiver inReceived-SPF: trace

holder, (e.g.,= "HELO" domain name= , the "MAIL FROM" address from the

fields and possibly returned to the cli= ent MTA in the = for= m of an SMTP

envelope,<= span style=3D" font-family:'monospace';"> and SPF DNS records publi= shed by the domain= holder).

rejection message. T= his information must be checked for invalid

characters and excess= ively long lines.

=

When the authorizatio= n check fails, an explanation string may be

10.5.1. Recorded Result= s

This information, pas= sed to the receiver in the Received-SPF: or

Authentication-Result= s: trace fields, may be returned to the client

MTA as an SMTP reject= ion message. If such an SMTP rejection message

is generated, the inf= ormation from the trace fields has to be checked

for such problems as = invalid characters and excessively long lines.

10.5.2. External Explan= ations

=

When the authorizatio= n check fails, an explanation string could be

included in the rejec= t response. Both the sender and the rejecting

included in the rejec= t response. Both the sender and the rejecting

receiver need to be a= ware that the explanation was determined by the

receiver need to be a= ware that the explanation was determined by the

publisher of the SPF = record checked and, in general, not the

publisher of the SPF = record checked and, in general, not the

=

receiver. The explan= ation may contain malicious URLs, or it may be

receiver. The explan= ation can contain malicious URLs, or it might be

offensive or misleadi= ng.

offensive or misleadi= ng.

=

This is probably = less of a concern than it may initially seem since

Explanations returned to sender dom= ains due to "exp" modifiers,

such messages are returned to the sende= r, and the explanation strings

(Section 6.2), were g= enerated by the sender= policy published by the

come from the sender policy published by th= e domain in the identity

domain holders th= emselves. As long as = messages are only returned

claimed by that very = sender. As long as to

with non-delivery not= ification ([RFC3464]) = to domains publishing the

someone other tha= n the actual sender, t= he only people who see

explanation strings f= rom their own DNS SPF records, the only affected

malicious explanation strings are peopl= e whose messages claim to be

parties are the origi= nal publishers of the domain's SPF records.

from domains that= publish such strings in

=

practice, DSNs can be misdirected, such= as when an MTA accepts an

In practice, <= span style=3D" font-family:'monospace'; background-color:#88ffff;">such= non-delivery notifications can be misdirected, such

E-Mail and then later generates a DSN to a forged address, or when an=

as when an MTA accept= s an email and only later generates = the

E-Mail forwarder does not direct the back to the orig= inal sender.

notification to a forged address, or when a= n email forwarder = does not

direct the bounce= back to the original = sender.

=

10.5.3. Macro Expansion=

Macros (Section 8) al= low senders to inject arbitrary text (any non-

null [US-ASCII] chara= cter) into receiver DNS queries. It is necesary

to be prepared for ho= stile or unexpected content.

10.6. Privacy Exposure<= /span>

10.6. Privacy Exposure<= /span>

Checking SPF records = causes DNS queries to be sent to the domain

Checking SPF records = causes DNS queries to be sent to the domain

owner. These DNS que= ries, especially if they are caused by the

owner. These DNS que= ries, especially if they are caused by the

"exists" me= chanism, can contain information about who is sending

"exists" me= chanism, can contain information about who is sending

=

E-Mail and likely to which MTA the = E-Mail is being sent. = This can

email and likely to which MTA the e= mail is being sent. T= his can

introduce some privac= y concerns, which may be more or less of an

introduce some privac= y concerns, which are more or less of an issue

issue depending on lo= cal laws and the relationship between the domain

depending on local la= ws and the relationship between the domain owner

owner and the person = sending the E-Mail.

and the person sendin= g the email.

11. Contributors and Ac= knowledgements

11. Contributors and Ac= knowledgements

=

This document is larg= ely based on the work of Meng Weng Wong and Mark

This document is larg= ely based on the work of Meng Weng Wong, Mark

Lentczner.= Although, as this section a= cknowledges, many people have

Lentczner, and Wa= yne Schlitt. Although= , as this section

contributed to this d= ocument, a very large portion of the writing and

acknowledges, many pe= ople have contributed to this document, a very

editing are due to and Mark.

large portion of the = writing and editing are due to Meng, Mark, and

Wayne.

=

This design owes a de= bt of parentage to [RMX] by Hadmut Danisch and

This design owes a de= bt of parentage to [RMX] by Hadmut Danisch and

to [DMP] by Gordon Fe= cyk. The idea of using a DNS record to check

to [DMP] by Gordon Fe= cyk. The idea of using a DNS record to check

=

the legitimacy of an = E-Mail address tra= ces its ancestry further back

the legitimacy of an = email address trac= es its ancestry further back

through messages on t= he namedroppers mailing list by Paul Vixie

through messages on t= he namedroppers mailing list by Paul Vixie

=

=

[Vixie] (based on sug= gestion by Jim Miller) and by David Green

[Vixie] (based on sug= gestion by Jim Miller) and by David Green

[Green].

[Green].

Philip Gladstone cont= ributed the concept of macros to the

Philip Gladstone cont= ributed the concept of macros to the

specification, multip= lying the expressiveness of the language and

specification, multip= lying the expressiveness of the language and

making per-user and p= er-IP lookups possible.

making per-user and p= er-IP lookups possible.

=

The authors would als= o like to thank the literally hundreds of

The authors of bo= th this document and [RFC4408] would also like to

individuals who have = participated in the development of this design.

thank the literally h= undreds of individuals who have participated in

They are far too nume= rous to name, but they include the following:

the development of th= is design. They are far too numerous to name,

but they include the = following:

=

The participants i= n the SPFbis working group.

The folks on the s= pf-discuss mailing list.

The folks on the s= pf-discuss mailing list.

The folks on the S= PAM-L mailing list.

The folks on the S= PAM-L mailing list.

The folks on the I= RTF ASRG mailing list.

The folks on the I= RTF ASRG mailing list.

The folks on the I= ETF MARID mailing list.

The folks on the I= ETF MARID mailing list.

The folks on #perl= .

The folks on #perl= .

12. IANA Considerations=

12. IANA Considerations=

12.1. The SPF DNS Recor= d Type

12.1. The SPF DNS Recor= d Type

=

The IANA has assigned a new Resource Record Type and Qtype from the<= /p>

Per [RFC4408], th= e IANA assigned th= e Resource Record Type= and Qtype

DNS Parameters Regist= ry for the SPF RR type with code 99.

from the DNS Paramete= rs Registry for the SPF RR type with code 99.

The format of thi= s type is identical to the TXT RR [RFC1035]. The

character content of = the record is encoded as [US-ASCII]. Use of

this record type is o= bsolete for SPF Version 1.

IANA is requested to = add an annotation to the SPF RRTYPE saying

"(OBSOLETE - use= TXT)" in the DNS Parameters registry.

[NOTE TO RFC EDITOR: = (to be changed to " ... has added ..." upon

publication)]<= /p>

12.2. The Received-SPF = Mail Header Field

12.2. The Received-SPF = Mail Header Field

Per [RFC3864], the &q= uot;Received-SPF:" header field is added to the IANA

Per [RFC3864], the &q= uot;Received-SPF:" header field is added to the IANA

Permanent Message Hea= der Field Registry. The following is the

Permanent Message Hea= der Field Registry. The following is the

registration template= :

registration template= :

Header field name:= Received-SPF

Header field name:= Received-SPF

=

Applicable protoco= l: mail ([RFC2822])

Applicable protoco= l: mail ([RFC5322])

Status: Experi= mental

Status: Standa= rds Track

Author/Change cont= roller: IETF

Author/Change cont= roller: IETF

=

Specification docu= ment(s): RFC 4408

Specification docu= ment(s): RFC XXXX

Related informatio= n:

[NOTE TO RFC EDITO= R: (this document)]

Requesting<= span style=3D" font-family:'monospace';"> SPF Council review of any= proposed changes and<= /span>

additions to this field are reco= mmended. For information about

12.3. SPF Modifier Registration

<= /td>

the SPF Council se= e http://www.openspf.org/Council

[RFC6652] created a n= ew SPF Modifier Registration. IANA is requested

to change the referen= ce for the exp and redirect modifiers from

[RFC4408] to this document. Their stat= us should not be changed.

13. References

13. References

13.1. Normative Referen= ces

13.1. Normative Referen= ces

[RFC1035] Mockapetri= s, P., "Domain names - implementation and

[RFC1035] Mockapetri= s, P., "Domain names - implementation and

specificat= ion", STD 13, RFC 1035, November 1987.

specificat= ion", STD 13, RFC 1035, November 1987.

[RFC1123] Braden, R.= , "Requirements for Internet Hosts - Application

[RFC1123] Braden, R.= , "Requirements for Internet Hosts - Application

and Suppor= t", STD 3, RFC 1123, October 1989.

and Suppor= t", STD 3, RFC 1123, October 1989.

[RFC2119] Bradner, S= ., "Key words for use in RFCs to Indicate

[RFC2119] Bradner, S= ., "Key words for use in RFCs to Indicate

Requiremen= t Levels", BCP 14, RFC 2119, March 1997.

Requiremen= t Levels", BCP 14, RFC 2119, March 1997.

=

[RFC2821] Klensi= n, J., "Simple Mail Transfer Protocol", RFC 2821,

<= /td>

[RFC3463]<= span style=3D" font-family:'monospace';"> Vaudreuil, G., "Enh= anced Mail System Stat= us Codes",

April 2001= .

RFC 34= 63, January 2003.

[RFC2822] Resnick, P= ., "Internet Message Format", RFC 2822, April

2001.

[RFC3464] Moore, K. = and G. Vaudreuil, = "An Extensible Message Format

for Delive= ry Status Notifica= tions", RFC 3= 464, January

2003.<= /span>

[RFC3513] Hinden, R.= and S. Deering, "Internet Protocol Version 6

(IPv6) Add= ressing Architecture", RFC 3513, April 2003.

[RFC3864] Klyne, G.,= Nottingham, M., and J. Mogul, "Registration

[RFC3864] Klyne, G.,= Nottingham, M., and J. Mogul, "Registration

Procedures= for Message Header Fields", BCP 90, RFC 3864,

Procedures= for Message Header Fields", BCP 90, RFC 3864,

September = 2004.

September = 2004.

[RFC3986] Berners-Le= e, T., Fielding, R., and L. Masinter, "Uniform

[RFC3986] Berners-Le= e, T., Fielding, R., and L. Masinter, "Uniform

=

Resource I= dentifier (URI): Generic Syntax", STD 66, RFC

Resource I= dentifier (URI): Generic Syntax", STD 66,

3986, Janu= ary 2005.

RFC 3986, = January 2005.

=

[RFC4234] Crocke= r, D. and P. Overe= ll, "Augmented BNF for Syntax

[RFC4291] Hinden= , R. and S. Deerin= g, "IP Version 6 Addressing

Specificat= ions: ABNF", RFC = 4234, October 2005.

Architectu= re", RFC <= span style=3D" font-family:'monospace'; background-color:#88ffff;">4291= , February 2006.

=

[US-ASCII] American N= ational Standards Institute (formerly United

[RFC5234] Crocke= r, D. and P. Overell, "Augmented BNF for Syntax

Specificat= ions: ABNF", STD 68, RFC 5234, January 2008.

[RFC5321] Klensin, J= ., "Simple Mail Transfer Protocol", RFC 5321,

October 20= 08.

[RFC5322] Resnick, P= ., Ed., "Internet Message Format", RFC 5322,

October 20= 08.

[RFC5451] Kucherawy,= M., "Message Header Field for Indicating

Message Au= thentication Status", RFC 5451, April 2009.

[RFC5598] Crocker, D= ., "Internet Mail Architecture", RFC 5598,

July 2009.=

[RFC5890] Klensin, J= ., "Internationalized Domain Names for

Applicatio= ns (IDNA): Definitions and Document Framework",

RFC 5890, = August 2010.

=

[US-ASCII]

=

American N= ational Standards Institute (formerly United

States of = America Standards Institute), "USA Code for

States of = America Standards Institute), "USA Code for

Informatio= n Interchange, X3.4", 1968.

Informatio= n Interchange, X3.4", 1968.

=

ANSI X3.4-1968 has be= en replaced by newer versions with slight

ANSI X3.4-= 1968 has been replaced by newer versions with

modificati= ons, but the 1968 version remains definitive for

slight mod= ifications, but the 1968 version remains

the Intern= et.

definitive= for the Internet.

=

13.2 Informative References

13.2. Informative References

=

[DMP] Fecyk,= G., "Designated Mailers Protocol".

Work In Pr= ogress

[Green] Green, D.,= "Domain-Authorized SMTP Mail", 2002.

[RFC1034] Mockapetri= s, P., "Domain names - concepts and facilities",

[RFC1034] Mockapetri= s, P., "Domain names - concepts and facilities",

STD 13, RF= C 1034, November 1987.

STD 13, RF= C 1034, November 1987.

=

[RFC1983] Malkin, G.= , "Internet Users' Glossary", RFC 1983, August

[RFC1983] Malkin, G.= , "Internet Users' Glossary", RFC 1983,

1996.

August 199= 6.

=

[RFC2440] Callas= , J., Donnerhacke, L., Finney, H., and R. Thayer,

[RFC2308] Andrew= s, M., "Negative Caching of DNS Queries (DNS

"Open= PGP Message Format", RFC 2440, November

NCACHE)&qu= ot;, RFC 2308, Mar= ch 1998.

=

[RFC2554] Myers,= J., "SMTP Service Extension for Authentication",

[RFC2782] Gulbra= ndsen, A., Vixie, P., and L. Esibov, "A DNS RR for

RFC 25= 54, March 1999.

specif= ying the location of services (DNS SRV)", RFC 2782,

February 2= 000.

[RFC3464] Moore, K. = and G. Vaudreuil, "An Extensible Message Format

for Delive= ry Status Notifications", RFC 3464,

January 20= 03.

[RFC3696] Klensin, J= ., "Application Techniques for Checking and

[RFC3696] Klensin, J= ., "Application Techniques for Checking and

Transforma= tion of Names", RFC 3696, February 2004.

Transforma= tion of Names", RFC 3696, February 2004.

[RFC3833] Atkins, D.= and R. Austein, "Threat Analysis of the Domain

[RFC3833] Atkins, D.= and R. Austein, "Threat Analysis of the Domain

Name Syste= m (DNS)", RFC 3833, August 2004.

Name Syste= m (DNS)", RFC 3833, August 2004.

=

[RFC3851] Ramsde= ll, B., "Secure/Multipurpose Internet Mail

[RFC3834] Moore,= K., "Recommendations for Automatic Responses to

Extensions= (S/MIME) Version 3.1 Message Specification",

Electronic= Mail", RFC 3= 834, August 2004.

RFC 38= 51, July 2004.<= /p>

=

[RFC4409] Gellen= s, R. and J. Klens= in, "Message Submission for Mail",

[RFC4408] Wong, = M. and W. Schlitt,= "Sender Policy Framework (SPF)

RFC 44= 09, April 2006.=

for Au= thorizing Use of Domains in E-Mail, Version 1",

RFC 44= 08, April 2006.=

=

[RMX] Danish= , H., "The RMX DNS RR Type for light weight sender

[RFC4632] Fuller= , V. and T. Li, "Classless Inter-domain Routing

authentica= tion", Work In Progress

(CIDR): Th= e Internet Address Assignment and Aggregation

Plan"= , BCP 122, RFC 4632, August 2006.

=

[DMP] Fecyk,= G., "Designated Mailers Protocol", Work In Progress

[RFC4880] Callas= , J., Donnerhacke, L., Finney, H., Shaw, D., and R.

Thayer, &q= uot;OpenPGP Message Format", RFC 4880, November 2007.

=

[Vixie] Vixie,= P., "Repudiating MAIL FROM", 2002.

[RFC4954] Siembo= rski, R. and A. Melnikov, "SMTP Service Extension

for Authen= tication", RFC 4954, July 2007.

=

[Green] Green,= D., "Domain-Authorized SMTP Mail", 2002.

[RFC5751] Ramsde= ll, B. and S. Turner, "Secure/Multipurpose Internet

Mail Exten= sions (S/MIME) Version 3.2 Message

Specificat= ion", RFC 5751, January 2010.

[RFC5782] Levine, J.= , "DNS Blacklists and Whitelists", RFC 5782,

February 2= 010.

[RFC6409] Gellens, R= . and J. Klensin, "Message Submission for Mail",

STD 72= , RFC 6409, November 2011.

[RFC6647] Kucherawy,= M. and D. Crocker, "Email Greylisting: An

Applicabil= ity Statement for SMTP", RFC 6647, June 2012.

[RFC6652] Kitterman,= S., "Sender Policy Framework (SPF)

Authentica= tion Failure Reporting Using the Abuse Reporting

Format&quo= t;, RFC 6652, June 2012.

[RFC6686] Kucherawy,= M., "Resolution of the Sender Policy Framework

(SPF) and = Sender ID Experiments", RFC 6686, July 2012.

[RMX] Danisch, H= ., "The RMX DNS RR Type for light weight sender

authentica= tion".

Work In Pr= ogress

[Vixie] Vixie, P.,= "Repudiating MAIL FROM", 2002.

Appendix A. Collected A= BNF

Appendix A. Collected A= BNF

This section is norma= tive and any discrepancies with the ABNF

This section is norma= tive and any discrepancies with the ABNF

fragments in the prec= eding text are to be resolved in favor of this

fragments in the prec= eding text are to be resolved in favor of this

grammar.

grammar.

=

See [RFC4<= span style=3D" font-family:'monospace';">234] for ABNF notation. Pleas= e note that as per this ABNF

See [RFC5<= span style=3D" font-family:'monospace';">234] for ABNF notation. Pleas= e note that as per this ABNF

definition, literal t= ext strings (those in quotes) are case-

definition, literal t= ext strings (those in quotes) are case-

insensitive. Hence, = "mx" matches "mx", "MX", "mX", = and "Mx".

insensitive. Hence, = "mx" matches "mx", "MX", "mX", = and "Mx".

record =3D = version terms *SP

record =3D = version terms *SP

version =3D = "v=3Dspf1"

version =3D = "v=3Dspf1"

terms =3D = *( 1*SP ( directive / modifier ) )

terms =3D = *( 1*SP ( directive / modifier ) )

directive =3D = [ qualifier ] mechanism

directive =3D = [ qualifier ] mechanism

qualifier =3D = "+" / "-" / "?" / "~"

qualifier =3D = "+" / "-" / "?" / "~"

= skipping to c= hange at pa= ge 42, line 38

= skipping to c= hange at pa= ge 57, line 38

MX =3D = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

MX =3D = "mx" [ ":" domain-spec ] [ dual-cidr-length ]

PTR =3D = "ptr" [ ":" domain-spec ]

PTR =3D = "ptr" [ ":" domain-spec ]

IP4 =3D = "ip4" ":" ip4-network [ ip4-cidr-length ]

IP4 =3D = "ip4" ":" ip4-network [ ip4-cidr-length ]

IP6 =3D = "ip6" ":" ip6-network [ ip6-cidr-length ]

IP6 =3D = "ip6" ":" ip6-network [ ip6-cidr-length ]

exists =3D = "exists" ":" domain-spec

exists =3D = "exists" ":" domain-spec

modifier =3D = redirect / explanation / unknown-modifier

modifier =3D = redirect / explanation / unknown-modifier

redirect =3D = "redirect" "=3D" domain-spec

redirect =3D = "redirect" "=3D" domain-spec

explanation =3D = "exp" "=3D" domain-spec

explanation =3D = "exp" "=3D" domain-spec

unknown-modifier =3D = name "=3D" macro-string

unknown-modifier =3D = name "=3D" macro-string

=

; = where name is not any known modifier

ip4-cidr-length =3D = "/" 1*DIGIT

ip4-cidr-length =3D = "/" 1*DIGIT

ip6-cidr-length =3D = "/" 1*DIGIT

ip6-cidr-length =3D = "/" 1*DIGIT

dual-cidr-length =3D = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

dual-cidr-length =3D = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]

ip4-network =3D = qnum "." qnum "." qnum "." qnum

ip4-network =3D = qnum "." qnum "." qnum "." qnum

qnum =3D = DIGIT ; 0-9

qnum =3D = DIGIT ; 0-9

/ = %x31-39 DIGIT ; 10-99

/ = %x31-39 DIGIT ; 10-99

/ = "1" 2DIGIT ; 100-199

/ = "1" 2DIGIT ; 100-199

/ = "2" %x30-34 DIGIT ; 200-249

/ = "2" %x30-34 DIGIT ; 200-249

/ = "25" %x30-35 ; 250-255

/ = "25" %x30-35 ; 250-255

=

; conventio= nal dotted quad notation. e.g., 192.0.2.0

; convention= al dotted quad notation. e.g., 192.0.2.0

ip6-network =3D = <as per [RFC 3513],

ip6-network =3D = <as per [RFC 4291], ; e.g., 200= 1:DB8::CD30

; e.g., 2001= :DB8::CD30

domain-spec =3D = macro-string domain-end

domain-spec =3D = macro-string domain-end

domain-end =3D = ( "." toplabel [ "." ] ) / macro-expand

<= /td>

domain-end =3D = ( "." toplabel [ "." ] ) / macro-expand

<= /td>

=

=

toplabel =3D = ( *alphanum ALPHA *alphanum ) /

toplabel =3D = ( *alphanum ALPHA *alphanum ) /

( = 1*alphanum "-" *( alphanum / "-" ) alphanum )

( = 1*alphanum "-" *( alphanum / "-" ) alphanum )

; = LDH rule plus additional TLD restrictions

; = LDH rule plus additional TLD restrictions

=

; = (see [RFC3696], Section 2)

; = (see [RFC3696], Section 2 for background)

=

alphanum =3D = ALPHA / DIGIT

alphanum =3D = ALPHA / DIGIT

explain-string =3D = *( macro-string / SP )

explain-string =3D = *( macro-string / SP )

macro-string =3D = *( macro-expand / macro-literal )

macro-string =3D = *( macro-expand / macro-literal )

macro-expand =3D = ( "%{" macro-letter transformers *delimiter "}" )

macro-expand =3D = ( "%{" macro-letter transformers *delimiter "}" )

/ = "%%" / "%_" / "%-"

/ = "%%" / "%_" / "%-"

macro-literal =3D = %x21-24 / %x26-7E

macro-literal =3D = %x21-24 / %x26-7E

; = visible characters except "%"

; = visible characters except "%"

macro-letter =3D = "s" / "l" / "o" / "d" / "i= " / "p" / "h" /

macro-letter =3D = "s" / "l" / "o" / "d" / "i= " / "p" / "h" /

=

&q= uot;c" / "r" / "t"

&q= uot;c" / "r" / "t" / "v"<= /p>

transformers =3D = *DIGIT [ "r" ]

transformers =3D = *DIGIT [ "r" ]

delimiter =3D = "." / "-" / "+" / "," / "/= " / "_" / "=3D"

delimiter =3D = "." / "-" / "+" / "," / "/= " / "_" / "=3D"

name =3D = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." = )

name =3D = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." = )

header-field =3D = "Received-SPF:" [CFWS] result FWS [comment FWS]

header-field =3D = "Received-SPF:" [CFWS] result FWS [comment FWS]

[ = key-value-list ] CRLF

[ = key-value-list ] CRLF

=

result =3D = "Pass" /= "Fail" = / "SoftFail""Neutral" /

result =3D = "pass" /= "fail" = / "softfail""neutral" /

/ <= /span>"TempError""PermError"

/ <= /span>"temperror""permerror"

key-value-list =3D = key-value-pair *( ";" [CFWS] key-value-pair )

key-value-list =3D = key-value-pair *( ";" [CFWS] key-value-pair )

[&= quot;;"]

[&= quot;;"]

key-value-pair =3D = key [CFWS] "=3D" ( dot-atom / quoted-string )

key-value-pair =3D = key [CFWS] "=3D" ( dot-atom / quoted-string )

key =3D = "client-ip" / "envelope-from" / "helo" /<= /span>

key =3D = "client-ip" / "envelope-from" / "helo" /<= /span>

=

&q= uot;problem" / "receiver" / "identity" /

&q= uot;problem" / "receiver" / identity /

m= echanism / "x-" name / name

m= echanism / name

identity =3D = "mailfrom" ; for the "MAIL FROM" identity<= /p>

identity =3D = "mailfrom" ; for the "MAIL FROM" identity<= /p>

/ = "helo" ; for the "HELO" identity

/ = "helo" ; for the "HELO" identity

/ = name ; other identities

/ = name ; other identities

=

dot-atom =3D = <unquoted word as per [RFC2822]>

ALPHA = =3D <A-Z / a-z as per [RFC5234]>

quoted-string =3D = <quoted string as per [RFC2822]>

DIGIT =3D = <0-9 as per [RFC5234]>

comment =3D = <comment string as per

SP =3D = <space character as per [RFC5234]>

CFWS =3D = <comment or folding white space as per [RFC2822]>

<= /td>

domain =3D = <fully qualified domain as per [RFC5321]>

FWS =3D = <folding white space as per [RFC2822]>

dot-atom =3D = <unquoted word as per [RFC5322]>

CRLF =3D = <standard end-of-line token as per [RFC2822]>

quoted-string =3D = <quoted string as per [RFC5322]>

comment =3D = <comment string as per

CFWS =3D = <comment or folding white space as per [RFC5322]>

<= /td>

FWS =3D = <folding white space as per [RFC5322]>

CRLF =3D = <standard end-of-line token as per [RFC5322]>

authserv-id =3D = <authserv-id per [RFC5451]>

reasonspec =3D = <reason per [RFC5451]>

Appendix B. Extended Ex= amples

Appendix B. Extended Ex= amples

These examples are ba= sed on the following DNS setup:

These examples are ba= sed on the following DNS setup:

; A domain with two m= ail servers, two hosts

; A domain with two m= ail servers, two hosts

; and two servers at = the domain name

; and two servers at = the domain name

$ORIGIN example.com.<= /span>

$ORIGIN example.com.<= /span>

@ MX 10 ma= il-a

@ MX 10 ma= il-a

MX 20 ma= il-b

MX 20 ma= il-b

= skipping to c= hange at pa= ge 44, line 46

= skipping to c= hange at pa= ge 60, line 46

; A rogue reverse IP = domain that claims to be

; A rogue reverse IP = domain that claims to be

; something it's not<= /span>

; something it's not<= /span>

$ORIGIN 0.0.10.in-add= r.arpa.

$ORIGIN 0.0.10.in-add= r.arpa.

4 PTR bob.e= xample.com.

4 PTR bob.e= xample.com.

B.1. Simple Examples

B.1. Simple Examples

These examples show v= arious possible published records for

These examples show v= arious possible published records for

example.com and which= values if <ip> would cause check_host() to

example.com and which= values if <ip> would cause check_host() to

=

return "<= span style=3D" font-family:'monospace'; background-color:#aaccff;">Pass". Note that <= ;domain> is "example.com".

return "<= span style=3D" font-family:'monospace'; background-color:#88ffff;">pass". Note that <= ;domain> is "example.com".

v=3Dspf1 +all<= /p>

v=3Dspf1 +all<= /p>

=

-- any <ip> = passes

-- any <ip> passes

=

v=3Dspf1 a -all

v=3Dspf1 a -all

=

-- hosts 192.0.2.1= 0 and 192.0.2.11 pass

-- hosts 192.0.2.10 and 192.0.2.11 = pass

v=3Dspf1 a:example.or= g -all

v=3Dspf1 a:example.or= g -all

=

-- no sending host= s pass since example.org has no A records

-- no sending hosts pass since exam= ple.org has no A records

v=3Dspf1 mx -all

v=3Dspf1 mx -all

=

-- sending hosts 1= 92.0.2.129 and 192.0.2.130 pass

-- sending hosts 192.0.2.129 and 19= 2.0.2.130 pass

v=3Dspf1 mx:example.o= rg -all

v=3Dspf1 mx:example.o= rg -all

=

-- sending host 19= 2.0.2.140 passes

-- sending host 192.0.2.140 passes<= /span>

v=3Dspf1 mx mx:exampl= e.org -all

v=3Dspf1 mx mx:exampl= e.org -all

=

-- sending hosts 1= 92.0.2.129, 192.0.2.130, and 192.0.2.140 pass

-- sending hosts 192.0.2.129, 192.0= .2.130, and 192.0.2.140 pass

v=3Dspf1 mx/30 mx:exa= mple.org/30 -all

v=3Dspf1 mx/30 mx:exa= mple.org/30 -all

=

-- any sending hos= t in 192.0.2.128/30 or 192.0.2.140/30 passes

-- any sending host in 192.0.2.128/= 30 or 192.0.2.140/30 passes

v=3Dspf1 ptr -all

v=3Dspf1 ptr -all

=

-- sending host 19= 2.0.2.65 passes (reverse DNS is valid and is in

-- sending host 1= 92.0.2.65 passes (reverse DNS is valid and is in

example.com)

example.com)

-- sending host 19= 2.0.2.140 fails (reverse DNS is valid, but not

-- sending host 1= 92.0.2.140 fails (reverse DNS is valid, but not

in example.com)=

in example.com= )

-- sending host 10= .0.0.4 fails (reverse IP is not valid)

-- sending host 1= 0.0.0.4 fails (reverse IP is not valid)

v=3Dspf1 ip4:192.0.2.= 128/28 -all

v=3Dspf1 ip4:192.0.2.= 128/28 -all

=

-- sending host 19= 2.0.2.65 fails

-- sending host 1= 92.0.2.65 fails

-- sending host 19= 2.0.2.129 passes

-- sending host 1= 92.0.2.129 passes

B.2. Multiple Domain Ex= ample

B.2. Multiple Domain Ex= ample

These examples show t= he effect of related records:

These examples show t= he effect of related records:

example.org: "= ;v=3Dspf1 include:example.com include:example.net -all"

=

example.org: "= ;v=3Dspf1 include:example.com include:example.net -all"

=

This record would be = used if mail from example.org actually came

This record would be = used if mail from example.org actually came

through servers at ex= ample.com and example.net. Example.org's

through servers at ex= ample.com and example.net. Example.org's

designated servers ar= e the union of example.com's and example.net's

designated servers ar= e the union of example.com's and example.net's

= skipping to c= hange at pa= ge 46, line 10

= skipping to c= hange at pa= ge 62, line 12

These records allow a= set of domains that all use the same mail

These records allow a= set of domains that all use the same mail

system to make use of= that mail system's record. In this way, only

system to make use of= that mail system's record. In this way, only

the mail system's rec= ord needs to be updated when the mail setup

the mail system's rec= ord needs to be updated when the mail setup

changes. These domai= ns' records never have to change.

changes. These domai= ns' records never have to change.

B.3. DNSBL Style Exampl= e

B.3. DNSBL Style Exampl= e

Imagine that, in addi= tion to the domain records listed above, there

Imagine that, in addi= tion to the domain records listed above, there

are these:

=

are these:

=

=

$ORIGIN _spf.example.= com. mary.mobile-users A

$ORIGIN _spf.example.= com.

127.0.0.2 fred.mobile= -users A 127.0.0.2

mary.mobile-users = A 127.0.0.2

fred.mobile-users = A 127.0.0.2

15.15.168.192.joel.re= mote-users A 127.0.0.2

15.15.168.192.joel.re= mote-users A 127.0.0.2

16.15.168.192.joel.re= mote-users A 127.0.0.2

16.15.168.192.joel.re= mote-users A 127.0.0.2

The following records= describe users at example.com who mail from

The following records= describe users at example.com who mail from

arbitrary servers, or= who mail from personal servers.

arbitrary servers, or= who mail from personal servers.

example.com:

example.com:

v=3Dspf1 mx

v=3Dspf1 mx

include:mobile= -users._spf.%{d}

include:mobile= -users._spf.%{d}

skipping to = change at p= age 47, line 5

skipping to = change at p= age 63, line 5

= "-include:ip4._spf.%{d} "

= "-include:ip4._spf.%{d} "

= "-include:ptr._spf.%{d} "

= "-include:ptr._spf.%{d} "

= "+all" )

= "+all" )

ip4._spf.example.com.= SPF "v=3Dspf1 -ip4:192.0.2.0/24 +all"

ip4._spf.example.com.= SPF "v=3Dspf1 -ip4:192.0.2.0/24 +all"

ptr._spf.example.com.= SPF "v=3Dspf1 -ptr +all"

ptr._spf.example.com.= SPF "v=3Dspf1 -ptr +all"

This example shows ho= w the "-include" mechanism can be useful, how an

This example shows ho= w the "-include" mechanism can be useful, how an

SPF record that ends = in "+all" can be very restrictive, and the use

SPF record that ends = in "+all" can be very restrictive, and the use

of De Morgan's Law.

of De Morgan's Law.

=

Authors' Addresses

Appendix C. Change = History

=

Meng Weng Wong

Changes since RFC= 4408 (to be removed prior to publication)

Singapore

<= /td>

=

EMail: mengwong+s= pf@pobox.com

Moved to stand= ards track

=

Wayne Schlitt

Authors update= d

4615 Meredeth #9

Lincoln Nebraska, NE = 68506

United States of Amer= ica

=

EMail: wayne@schl= itt.net

IESG Note rega= rding experimental use replaced with discussion of

URI: http://www.sch= litt.net/spf/

results

=

=

Full Copyright Statement=

Process errata:

=

Copyright (C) The= Internet Society (2006).

Resolved Secti= on 2.5.7 PermError on invalid domains after macro

expansion errata i= n favor of documenting that different clients

produce different = results.

=

This document is = subject to the rig= hts, licenses and restrictions

Add %v macro to ABNF grammar

contained in BCP 78, = and except as set forth therein, the authors

retain all their righ= ts.

=

This document and= the information contained herein are provided on an

Replace "= uric" by "unreserved"

"AS IS" bas= is and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS

OR IS SPONSORED BY (I= F ANY), THE INTERNET SOCIETY AND THE INTERNET

ENGINEERING TASK FORC= E DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,

INCLUDING BUT NOT LIM= ITED TO ANY WARRANTY THAT THE USE OF THE

INFORMATION HEREIN WI= LL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED

WARRANTIES OF MERCHAN= TABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

=

Intellectual Property

Recommend an SMTP = reply code for optional permerror rejections

=

The IETF takes no= position regarding the validity or scope of any

Correct syntax= in Received-SPF e= xamples

Intellectual Property= Rights or other rights that might be claimed to

pertain to the implem= entation or use of the technology described in

this document or = the extent to which any license under such rights

might or might not be= available; nor does it represent that it has

made any independent = effort to identify any such rights. Information

on the procedures wit= h respect to rights in RFC documents can be

found in BCP 78 and B= CP 79.

=

Copies of IPR dis= closures made to the IETF Secretariat and any

Fix unknown-mo= difier clause is too greedy in ABNF

assurances of license= s to be made available, or the result of an

attempt made to obtai= n a general license or permission for the use of

such proprietary righ= ts by implementers or users of this

specification can be = obtained from the IETF on-line IPR repository at

http://www.ietf.org/i= pr.

=

The IETF invites = any interested party to bring to its attention any

Correct use of= empty domain-spec on exp modifier

copyrights, patents o= r patent applications, or other proprietary

rights that may cover= technology that may be required to implement

this standard. Pleas= e address the information to the IETF at

ietf-ipr@ietf.org.

=

Acknowledgement

Fix minor typo err= ata

=

Funding for the RFC Editor function is provided by the IETF

Convert to spf= bis working group draft,

Administrative Suppor= t Activity (IASA).

draft-ietf-spfbis-= 4408bis-00

Addressed Ticket #= 1, RFC 4408 Section 2.5.6 - Temporary errors by

giving the option = to turn repeated SERVFAIL into permerror and

adding RFC 2308 re= ference.

Clarified text abo= ut IPv4 mapped addresses to resolve test suite

ambiguity

Clarified ambiguit= y about result when more than 10 "mx" or "ptr"

records are return= ed for lookup to s= pecify permerror. This

resolves one of th= e test suite ambiguities

Made all reference= s to result codes lower case per issue #7

Adjusted section 2= .2 Requirement to check mail from per issue #15

Added missing &quo= t;v" element in macro-letter in the collected ABNF

per issue #16 - se= ction 8.1 was already fixed in the pre-WG draft

Marked ptr and &qu= ot;p" macro deprecated/SHOULD NOT use per issue #27

Expunged lower cas= e may from the draft per issue #8

Expunged "x-&= quot; name as an obsolete concept

Updated obslete re= ferences: RFC2821 to RFC5321, RFC2822 to

RFC5322, and RFC42= 34 to RFC5234

Refer to RFC6647 t= o describe greylisting instead of trying to

describe it direct= ly.

Updated informativ= e references to the current versions.

Added definition f= or deprecated since there are questions.

Start to rework se= ction 9 with some RFC5598 terms.

Added mention of RFC 6552 feedback rep= orts in section 9.

Added draft-ietf-s= pfbis-experiment as an informational reference.

Drop Type SPF.

Try and clarify in= formational nature of RFC3696

Fix ABNF nits and = add missing definitions per Bill's ABNF checker.

Make DNS lookup ti= me limit SHOULD instead of MAY.

Reorganize and cla= rify processing limits. Move hard limits to new

section 4.6.4, Eva= luation Limits. Move advice to non-normative

section 9.<= /p>

Removed paragraph = in section 10.1 about limiting total data

volumes as it is unused (and removab= le per the charter) and serves

no purpose (it isn= 't something that actually can be implemented in

any reasonable way= ).

Added text and fig= ures from Alessandro Vesely in section 9.1 to

better explain DNS= resource limits.

Multiple editorial= fixes from Murray Kucherawy's review.

Also based on Murr= ay's review, reworked SMTP identity definitions

and made RFC 5598 = a normative reference instead of informative.

This is a downref = that will have to be mentioned in the last call.

Added RFC 3834 as = an informative reference about backscatter.

Added IDN requirem= ents and normative reference to RFC 5890 to deal

with the question = "like DKIM did it.:

Added informative = reference to RFC 4632 for CIDR and use CIDR

prefix length inst= ead of CIDR-length to match its terminology.

Added RFC 5782 inf= ormative reference on DNSxLs to support

improving the exis= ts description.

Added text on crea= ting a Authentication-Results header field that

matches the Receiv= ed-SPF header field information and added a

normative referenc= e to RFC 5451.

Added informative = reference to RFC 2782 due to SRV mention.

Added informative = reference to RFC 3464 due to DSN mention.

Added informative = reference to RFC 5617 for it's DNS wildcard use.

Added informative = reference to RFC 5782 to enhance the explanation

of how the exists = mechanism works. Clarified the intended match/

no-match method.

Added new sections= on Receiver policy for SPF pass, fail, and

permerror.<= /p>

Added new section = 9 discussion on treatment of bounces and the

significance of HE= LO records.

Added request to I= ANA to update the = SPF modifier registry.

Author's Address<= /p>

Scott Kitterman

Kitterman Technical S= ervices

3611 Scheel Dr=

Ellicott City, MD 21= 042

United States of Amer= ica

Email: scott@kitterma= n.com

=A0End of changes. 318 change blocks.=A0 =

943 lines changed or d= eleted

1353 lines changed or = added


This html diff was produced by rfcdiff 1.41. The latest vers= ion is available from http://t= ools.ietf.org/tools/rfcdiff/

--nextPart1485834.jITXE1tHj5-- --nextPart42364935.Jmi9YR0pFl Content-Disposition: attachment; filename="draft-ietf-spfbis-4408bis-08-from-rfc4408.diff.html" Content-Transfer-Encoding: 7Bit Content-Type: text/html; charset="utf-8"; name="draft-ietf-spfbis-4408bis-08-from-rfc4408.diff.html" Diff: rfc4408.txt - draft-ietf-spfbis-4408bis-08.txt
 rfc4408.txt   draft-ietf-spfbis-4408bis-08.txt 
Network Working Group M. Wong Network Working Group S. Kitterman
Request for Comments: 4408 W. Schlitt Internet-Draft Kitterman Technical Services
Category: Experimental April 2006 Obsoletes: 4408 (if approved) October 22, 2012
Intended status: Standards Track
Sender Policy Framework (SPF) for Expires: April 25, 2013
Authorizing Use of Domains in E-Mail, Version 1
Status of This Memo Sender Policy Framework (SPF) for Authorizing Use of Domains in Email,
Version 1
draft-ietf-spfbis-4408bis-08.txt
This memo defines an Experimental Protocol for the Internet Abstract
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice Email on the Internet can be forged in a number of ways. In
particular, existing protocols place no restriction on what a sending
host can use as the "MAIL FROM" of a message or the domain given on
the SMTP HELO/EHLO commands. This document describes version 1 of
the Sender Policy Framework (SPF) protocol, whereby an ADMD can
explicitly authorize the hosts that are allowed to use its domain
names, and a receiving host can check such authorization.
Copyright (C) The Internet Society (2006). This document obsoletes RFC4408.
IESG Note Status of this Memo
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) This Internet-Draft is submitted in full conformance with the
are published simultaneously as Experimental RFCs, although there is provisions of BCP 78 and BCP 79.
no general technical consensus and efforts to reconcile the two
approaches have failed. As such, these documents have not received
full IETF review and are published "AS-IS" to document the different
approaches as they were considered in the MARID working group.
The IESG takes no position about which approach is to be preferred Internet-Drafts are working documents of the Internet Engineering
and cautions the reader that there are serious open issues for each Task Force (IETF). Note that other groups may also distribute
approach and concerns about using them in tandem. The IESG believes working documents as Internet-Drafts. The list of current Internet-
that documenting the different approaches does less harm than not Drafts is at http://datatracker.ietf.org/drafts/current/.
documenting them.
Note that the Sender ID experiment may use DNS records that may have Internet-Drafts are draft documents valid for a maximum of six months
been created for the current SPF experiment or earlier versions in and may be updated, replaced, or obsoleted by other documents at any
this set of experiments. Depending on the content of the record, time. It is inappropriate to use Internet-Drafts as reference
this may mean that Sender-ID heuristics would be applied incorrectly material or to cite them other than as "work in progress."
to a message. Depending on the actions associated by the recipient
with those heuristics, the message may not be delivered or may be
discarded on receipt.
Participants relying on Sender ID experiment DNS records are warned This Internet-Draft will expire on April 25, 2013.
that they may lose valid messages in this set of circumstances.
aParticipants publishing SPF experiment DNS records should consider
the advice given in section 3.4 of RFC 4406 and may wish to publish
both v=spf1 and spf2.0 records to avoid the conflict.
Participants in the Sender-ID experiment need to be aware that the Copyright Notice
way Resent-* header fields are used will result in failure to receive
legitimate email when interacting with standards-compliant systems
(specifically automatic forwarders which comply with the standards by
not adding Resent-* headers, and systems which comply with RFC 822
but have not yet implemented RFC 2822 Resent-* semantics). It would
be inappropriate to advance Sender-ID on the standards track without
resolving this interoperability problem.
The community is invited to observe the success or failure of the two Copyright (c) 2012 IETF Trust and the persons identified as the
approaches during the two years following publication, in order that document authors. All rights reserved.
a community consensus can be reached in the future.
Abstract This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
E-mail on the Internet can be forged in a number of ways. In This document may contain material from IETF Documents or IETF
particular, existing protocols place no restriction on what a sending Contributions published or made publicly available before November
host can use as the reverse-path of a message or the domain given on 10, 2008. The person(s) controlling the copyright in some of this
the SMTP HELO/EHLO commands. This document describes version 1 of material may not have granted the IETF Trust the right to allow
the Sender Policy Framework (SPF) protocol, whereby a domain may modifications of such material outside the IETF Standards Process.
explicitly authorize the hosts that are allowed to use its domain Without obtaining an adequate license from the person(s) controlling
name, and a receiving host may check such authorization. the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction ....................................................4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Protocol Status ............................................4 1.1. Protocol Status . . . . . . . . . . . . . . . . . . . . . 6
1.2. Terminology ................................................5 1.2. Experimental History . . . . . . . . . . . . . . . . . . . 7
2. Operation .......................................................5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. The HELO Identity ..........................................5 1.3.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. The MAIL FROM Identity .....................................5 1.3.2. Imported Definitions . . . . . . . . . . . . . . . . . 7
2.3. Publishing Authorization ...................................6 1.3.3. Mail From Definition . . . . . . . . . . . . . . . . . 7
2.4. Checking Authorization .....................................6 1.3.4. HELO Definition . . . . . . . . . . . . . . . . . . . 8
2.5. Interpreting the Result ....................................7 1.3.5. Deprecated . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1. None ................................................8 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.5.2. Neutral .............................................8 2.1. The "HELO" Identity . . . . . . . . . . . . . . . . . . . 9
2.5.3. Pass ................................................8 2.2. The "MAIL FROM" Identity . . . . . . . . . . . . . . . . . 9
2.5.4. Fail ................................................8 2.3. Publishing Authorization . . . . . . . . . . . . . . . . . 9
2.5.5. SoftFail ............................................9 2.4. Checking Authorization . . . . . . . . . . . . . . . . . . 10
2.5.6. TempError ...........................................9 2.5. Interpreting the Result . . . . . . . . . . . . . . . . . 11
2.5.7. PermError ...........................................9 2.5.1. None . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. SPF Records .....................................................9 2.5.2. Neutral . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Publishing ................................................10 2.5.3. Pass . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. DNS Resource Record Types ..........................10 2.5.4. Fail . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Multiple DNS Records ...............................11 2.5.5. Softfail . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.3. Multiple Strings in a Single DNS record ............11 2.5.6. Temperror . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4. Record Size ........................................11 2.5.7. Permerror . . . . . . . . . . . . . . . . . . . . . . 13
3.1.5. Wildcard Records ...................................11 3. SPF Records . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. DNS Resource Records . . . . . . . . . . . . . . . . . . . 14
4. The check_host() Function ......................................12 3.2. Multiple DNS Records . . . . . . . . . . . . . . . . . . . 15
4.1. Arguments .................................................12 3.3. Multiple Strings in a Single DNS record . . . . . . . . . 15
4.2. Results ...................................................13 3.4. Record Size . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Initial Processing ........................................13 3.5. Wildcard Records . . . . . . . . . . . . . . . . . . . . . 15
4.4. Record Lookup .............................................13 4. The check_host() Function . . . . . . . . . . . . . . . . . . 17
4.5. Selecting Records .........................................13 4.1. Arguments . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6. Record Evaluation .........................................14 4.2. Results . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6.1. Term Evaluation ....................................14 4.3. Initial Processing . . . . . . . . . . . . . . . . . . . . 17
4.6.2. Mechanisms .........................................15 4.4. Record Lookup . . . . . . . . . . . . . . . . . . . . . . 18
4.6.3. Modifiers ..........................................15 4.5. Selecting Records . . . . . . . . . . . . . . . . . . . . 18
4.7. Default Result ............................................16 4.6. Record Evaluation . . . . . . . . . . . . . . . . . . . . 18
4.8. Domain Specification ......................................16 4.6.1. Term Evaluation . . . . . . . . . . . . . . . . . . . 19
5. Mechanism Definitions ..........................................16 4.6.2. Mechanisms . . . . . . . . . . . . . . . . . . . . . . 19
5.1. "all" .....................................................17 4.6.3. Modifiers . . . . . . . . . . . . . . . . . . . . . . 20
5.2. "include" .................................................18 4.6.4. DNS Lookup Limits . . . . . . . . . . . . . . . . . . 20
5.3. "a" .......................................................19 4.7. Default Result . . . . . . . . . . . . . . . . . . . . . . 21
5.4. "mx" ......................................................20 4.8. Domain Specification . . . . . . . . . . . . . . . . . . . 21
5.5. "ptr" .....................................................20 5. Mechanism Definitions . . . . . . . . . . . . . . . . . . . . 22
5.6. "ip4" and "ip6" ...........................................21 5.1. "all" . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.7. "exists" ..................................................22 5.2. "include" . . . . . . . . . . . . . . . . . . . . . . . . 23
6. Modifier Definitions ...........................................22 5.3. "a" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. redirect: Redirected Query ................................23 5.4. "mx" . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. exp: Explanation ..........................................23 5.5. "ptr" (deprecated) . . . . . . . . . . . . . . . . . . . . 25
7. The Received-SPF Header Field ..................................25 5.6. "ip4" and "ip6" . . . . . . . . . . . . . . . . . . . . . 27
8. Macros .........................................................27 5.7. "exists" . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Macro Definitions .........................................27 6. Modifier Definitions . . . . . . . . . . . . . . . . . . . . . 29
8.2. Expansion Examples ........................................30 6.1. redirect: Redirected Query . . . . . . . . . . . . . . . . 29
9. Implications ...................................................31 6.2. exp: Explanation . . . . . . . . . . . . . . . . . . . . . 30
9.1. Sending Domains ...........................................31 7. Recording The Result . . . . . . . . . . . . . . . . . . . . . 32
9.2. Mailing Lists .............................................32 7.1. The Received-SPF Header Field . . . . . . . . . . . . . . 32
9.3. Forwarding Services and Aliases ...........................32 7.2. SPF Results in the Authentication-Results Header Field . . 34
9.4. Mail Services .............................................34 8. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.5. MTA Relays ................................................34 8.1. Macro Definitions . . . . . . . . . . . . . . . . . . . . 36
10. Security Considerations .......................................35 8.2. Expansion Examples . . . . . . . . . . . . . . . . . . . . 39
10.1. Processing Limits ........................................35 9. Implications . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.2. SPF-Authorized E-Mail May Contain Other False 9.1. Sending Domains . . . . . . . . . . . . . . . . . . . . . 41
Identities ...............................................37 9.1.1. DNS Resource Considerations . . . . . . . . . . . . . 41
10.3. Spoofed DNS and IP Data ..................................37 9.1.2. Administrator's Considerations . . . . . . . . . . . . 42
10.4. Cross-User Forgery .......................................37 9.1.3. Bounces . . . . . . . . . . . . . . . . . . . . . . . 43
10.5. Untrusted Information Sources ............................38 9.2. Mediators . . . . . . . . . . . . . . . . . . . . . . . . 43
10.6. Privacy Exposure .........................................38 9.2.1. Mailing Lists . . . . . . . . . . . . . . . . . . . . 43
11. Contributors and Acknowledgements .............................38 9.2.2. Forwarding Services and Aliases . . . . . . . . . . . 44
12. IANA Considerations ...........................................39 9.2.3. Mail Services . . . . . . . . . . . . . . . . . . . . 46
12.1. The SPF DNS Record Type ..................................39 9.2.4. MTA Relays . . . . . . . . . . . . . . . . . . . . . . 46
12.2. The Received-SPF Mail Header Field .......................39 9.3. Receivers . . . . . . . . . . . . . . . . . . . . . . . . 47
13. References ....................................................39 9.3.1. Policy For SPF Pass . . . . . . . . . . . . . . . . . 47
13.1. Normative References .....................................39 9.3.2. Policy For SPF Fail . . . . . . . . . . . . . . . . . 47
13.2. Informative References ...................................40 9.3.3. Policy For SPF Permerror . . . . . . . . . . . . . . . 48
10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
Appendix A. Collected ABNF .......................................42 10.1. Processing Limits . . . . . . . . . . . . . . . . . . . . 49
Appendix B. Extended Examples ....................................44 10.2. SPF-Authorized Email May Contain Other False Identities . 49
B.1. Simple Examples ..........................................44 10.3. Spoofed DNS and IP Data . . . . . . . . . . . . . . . . . 50
B.2. Multiple Domain Example ..................................45 10.4. Cross-User Forgery . . . . . . . . . . . . . . . . . . . . 50
B.3. DNSBL Style Example ......................................46 10.5. Untrusted Information Sources . . . . . . . . . . . . . . 50
B.4. Multiple Requirements Example ............................46 10.5.1. Recorded Results . . . . . . . . . . . . . . . . . . . 50
10.5.2. External Explanations . . . . . . . . . . . . . . . . 51
10.5.3. Macro Expansion . . . . . . . . . . . . . . . . . . . 51
10.6. Privacy Exposure . . . . . . . . . . . . . . . . . . . . . 51
11. Contributors and Acknowledgements . . . . . . . . . . . . . . 52
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53
12.1. The SPF DNS Record Type . . . . . . . . . . . . . . . . . 53
12.2. The Received-SPF Mail Header Field . . . . . . . . . . . . 53
12.3. SPF Modifier Registration . . . . . . . . . . . . . . . . 53
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
13.1. Normative References . . . . . . . . . . . . . . . . . . . 54
13.2. Informative References . . . . . . . . . . . . . . . . . . 55
Appendix A. Collected ABNF . . . . . . . . . . . . . . . . . . . 57
Appendix B. Extended Examples . . . . . . . . . . . . . . . . . . 60
B.1. Simple Examples . . . . . . . . . . . . . . . . . . . . . 60
B.2. Multiple Domain Example . . . . . . . . . . . . . . . . . 61
B.3. DNSBL Style Example . . . . . . . . . . . . . . . . . . . 62
B.4. Multiple Requirements Example . . . . . . . . . . . . . . 62
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 63
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
The current E-Mail infrastructure has the property that any host The current email infrastructure has the property that any host
injecting mail into the mail system can identify itself as any domain injecting mail into the system can use any DNS domain name it wants
name it wants. Hosts can do this at a variety of levels: in in each of the various identifiers specified by [RFC5321] and
particular, the session, the envelope, and the mail headers. [RFC5322]. Although this feature is desirable in some circumstances,
Although this feature is desirable in some circumstances, it is a it is a major obstacle to reducing Unsolicited Bulk Email (UBE, aka
major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). spam). Furthermore, many domain owning ADMDs (ADministrative
Furthermore, many domain name holders are understandably concerned Management Domains, see [RFC5598]) are understandably concerned about
about the ease with which other entities may make use of their domain the ease with which other entities can make use of their domain
names, often with malicious intent. names, often with malicious intent.
This document defines a protocol by which domain owners may authorize This document defines a protocol by which ADMDs can authorize hosts
hosts to use their domain name in the "MAIL FROM" or "HELO" identity. to use their domain names in the "MAIL FROM" or "HELO" identities.
Compliant domain holders publish Sender Policy Framework (SPF) Compliant ADMDs publish Sender Policy Framework (SPF) records in the
records specifying which hosts are permitted to use their names, and DNS specifying which hosts are permitted to use their names, and
compliant mail receivers use the published SPF records to test the compliant mail receivers use the published SPF records to test the
authorization of sending Mail Transfer Agents (MTAs) using a given authorization of sending Mail Transfer Agents (MTAs) using a given
"HELO" or "MAIL FROM" identity during a mail transaction. "HELO" or "MAIL FROM" identity during a mail transaction.
An additional benefit to mail receivers is that after the use of an An additional benefit to mail receivers is that after the use of an
identity is verified, local policy decisions about the mail can be identity is verified, local policy decisions about the mail can be
made based on the sender's domain, rather than the host's IP address. made based on the sender's domain, rather than the host's IP address.
This is advantageous because reputation of domain names is likely to This is advantageous because reputation of domain names is likely to
be more accurate than reputation of host IP addresses. Furthermore, be more accurate than reputation of host IP addresses. Furthermore,
if a claimed identity fails verification, local policy can take if a claimed identity fails verification, local policy can take
stronger action against such E-Mail, such as rejecting it. stronger action against such email, such as rejecting it.
1.1. Protocol Status 1.1. Protocol Status
SPF has been in development since the summer of 2003 and has seen SPF has been in development since the summer of 2003 and has seen
deployment beyond the developers beginning in December 2003. The deployment beyond the developers beginning in December 2003. The
design of SPF slowly evolved until the spring of 2004 and has since design of SPF slowly evolved until the spring of 2004 and has since
stabilized. There have been quite a number of forms of SPF, some stabilized. There have been quite a number of forms of SPF, some
written up as documents, some submitted as Internet Drafts, and many written up as documents, some submitted as Internet Drafts, and many
discussed and debated in development forums. discussed and debated in development forums. The protocol was
originally defined in [RFC4408], which this document replaces.
The goal of this document is to clearly document the protocol defined [RFC4408] was designed to clearly document the protocol defined by
by earlier draft specifications of SPF as used in existing earlier draft specifications of SPF as used in existing
implementations. This conception of SPF is sometimes called "SPF implementations. This updated specification is intended to clarify
Classic". It is understood that particular implementations and identified ambiguities in [RFC4408], resolve techincal issues
deployments may differ from, and build upon, this work. It is hoped identified in post-RFC 4408 deplyment experience, and document widely
that we have nonetheless captured the common understanding of SPF deployed extensions to SPF that have been developed since [RFC4408]
version 1. was published.
1.2. Terminology 1.2. Experimental History
This document updates and replaces RFC 4408 that was part of a group
of simultaneously published Experimental RFCs (RFC 4405, RFC 4406,
RFC 4407, and RFC 4408) in 2006. At that time the IESG requested the
community observe the success or failure of the two approaches
documented in these RFCs during the two years following publication,
in order that a community consensus could be reached in the future.
SPF is widely deployed by large and small email providers alike.
There are multiple, interoperable implementations.
For SPF (as documented in RFC 4408) a careful effort was made to
collect and document lessons learned and errata during the two year
period. The errata list has been stable (no new submissions) and
only minor protocol lessons learned were identified. Resolution of
the IESG's experiment is documented in [RFC6686].
1.3. Terminology
1.3.1. Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
1.3.2. Imported Definitions
The ABNF tokens "ALPHA", "DIGIT", and "SP" are defined in [RFC5234].
The token "local-part" is defined in [RFC5321].
"dot-atom", "quoted-string", "comment", "CFWS", "FWS", and "CRLF" are
defined in [RFC5322].
1.3.3. Mail From Definition
This document is concerned with the portion of a mail message This document is concerned with the portion of a mail message
commonly called "envelope sender", "return path", "reverse path", commonly called "envelope sender", "return path", "reverse path",
"bounce address", "2821 FROM", or "MAIL FROM". Since these terms are "bounce address", "5321 FROM", "MAIL FROM", or RFC5321.MailFrom.
either not well defined or often used casually, this document defines Since these terms are either not well defined or often used casually,
the "MAIL FROM" identity in Section 2.2. Note that other terms that this document uses "MAIL FROM" for consistency. This means the
may superficially look like the common terms, such as "reverse-path", RFC5321.MailFrom as defined in [RFC5598]. Note that other terms that
are used only with the defined meanings from normative documents. might superficially look like the common terms, such as "reverse-
path", are used only with the defined meanings from normative
documents.
2. Operation 1.3.4. HELO Definition
2.1. The HELO Identity This document also makes use of the HELO/EHLO identity. The "HELO"
identity derives from either the SMTP HELO or EHLO command (see
[RFC5321]). Since HELO and EHLO can, in many cases, be used
interchangeably, they are identified commonly as "HELO" in this
document. This means RFC5321.HELO/.EHLO as defined in [RFC5598].
These commands supply the identity of the SMTP client (sending host)
for the SMTP session.
The "HELO" identity derives from either the SMTP HELO or EHLO command 1.3.5. Deprecated
(see [RFC2821]). These commands supply the SMTP client (sending
host) for the SMTP session. Note that requirements for the domain
presented in the EHLO or HELO command are not always clear to the
sending party, and SPF clients must be prepared for the "HELO"
identity to be malformed or an IP address literal. At the time of
this writing, many legitimate E-Mails are delivered with invalid HELO
domains.
It is RECOMMENDED that SPF clients not only check the "MAIL FROM" There are [RFC4408] features that are marked "deprecated". In the
context of this document, deprecated means that senders SHOULD NOT
publish SPF records that make use of such features because they might
be removed entirely in future updates to the protocol. Such features
do, however, remain part of the SPF protocol and receiving systems
MUST support them unless this document explicitly says otherwise.
2. Operation
2.1. The "HELO" Identity
It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
identity, but also separately check the "HELO" identity by applying identity, but also separately check the "HELO" identity by applying
the check_host() function (Section 4) to the "HELO" identity as the the check_host() function (Section 4) to the "HELO" identity as the
<sender>. <sender>. Checking "HELO" promotes consistency of results and can
reduce DNS resource usage. Additionally, since SPF records published
for "HELO" identities refer to a single host, when available, they
are a very reliable source of host authorization status.
2.2. The MAIL FROM Identity Note that requirements for the domain presented in the EHLO or HELO
command are not always clear to the sending party, and SPF verifiers
MUST be prepared for the "HELO" identity to be malformed or an IP
address literal. This SPF check can only be performed when the
"HELO" string is a valid fully qualified domain.
The "MAIL FROM" identity derives from the SMTP MAIL command (see 2.2. The "MAIL FROM" Identity
[RFC2821]). This command supplies the "reverse-path" for a message,
which generally consists of the sender mailbox, and is the mailbox to
which notification messages are to be sent if there are problems
delivering the message.
[RFC2821] allows the reverse-path to be null (see Section 4.5.5 in SPF verifiers MUST check the ""MAIL FROM" identity if a completed
RFC 2821). In this case, there is no explicit sender mailbox, and "HELO" check has not reached a definitive policy result by applying
the check_host() function to the "MAIL FROM" identity as the
<sender>.
[RFC5321] allows the reverse-path to be null (see Section 4.5.5 in
[RFC5321]). In this case, there is no explicit sender mailbox, and
such a message can be assumed to be a notification message from the such a message can be assumed to be a notification message from the
mail system itself. When the reverse-path is null, this document mail system itself. When the reverse-path is null, this document
defines the "MAIL FROM" identity to be the mailbox composed of the defines the "MAIL FROM" identity to be the mailbox composed of the
localpart "postmaster" and the "HELO" identity (which may or may not local-part "postmaster" and the "HELO" identity (which might or might
have been checked separately before). not have been checked separately before).
SPF clients MUST check the "MAIL FROM" identity. SPF clients check
the "MAIL FROM" identity by applying the check_host() function to the
"MAIL FROM" identity as the <sender>.
2.3. Publishing Authorization 2.3. Publishing Authorization
An SPF-compliant domain MUST publish a valid SPF record as described An SPF-compliant domain MUST have valid SPF records as described in
in Section 3. This record authorizes the use of the domain name in Section 3. These records authorize the use of the relevant domain
the "HELO" and "MAIL FROM" identities by the MTAs it specifies. names in the "HELO" and "MAIL FROM" identities by the MTAs specified
therein.
If domain owners choose to publish SPF records, it is RECOMMENDED SPF results can be used to make both positive (source is authorized)
that they end in "-all", or redirect to other records that do, so and negative (source is not authorized) determinations. If domain
that a definitive determination of authorization can be made. owners choose to publish SPF records and want to support receivers
making negative authorization determinations, then they MUST publish
records that end in "-all", or redirect to other records that do,
otherwise, no definitive determination of authorization can be made.
Potential issues and mitigations associated with negative
determinations are discussed in Section 9.
Domain holders may publish SPF records that explicitly authorize no ADMDs can publish SPF records that explicitly authorize no hosts for
hosts if mail should never originate using that domain. domain names that are neither used in the domain part of email
addresses nor expected to originate mail.
When changing SPF records, care must be taken to ensure that there is When changing SPF records, care has to be taken to ensure that there
a transition period so that the old policy remains valid until all is a transition period so that the old policy remains valid until all
legitimate E-Mail has been checked. legitimate email can reasonably expect to have been checked. This
can be as much as 30 days.
2.4. Checking Authorization 2.4. Checking Authorization
A mail receiver can perform a set of SPF checks for each mail message A mail receiver can perform a set of SPF checks for each mail message
it receives. An SPF check tests the authorization of a client host it receives. An SPF check tests the authorization of a client host
to emit mail with a given identity. Typically, such checks are done to emit mail with a given identity. Typically, such checks are done
by a receiving MTA, but can be performed elsewhere in the mail by a receiving MTA, but can be performed elsewhere in the mail
processing chain so long as the required information is available and processing chain so long as the required information is available and
reliable. At least the "MAIL FROM" identity MUST be checked, but it reliable. At least the "MAIL FROM" identity MUST be checked, but it
is RECOMMENDED that the "HELO" identity also be checked beforehand. is RECOMMENDED that the "HELO" identity also be checked beforehand.
Without explicit approval of the domain owner, checking other Without explicit approval of the domain owner, checking other
identities against SPF version 1 records is NOT RECOMMENDED because identities against SPF version 1 records is NOT RECOMMENDED because
there are cases that are known to give incorrect results. For there are cases that are known to give incorrect results. For
example, almost all mailing lists rewrite the "MAIL FROM" identity example, almost all mailing lists rewrite the "MAIL FROM" identity
(see Section 9.2), but some do not change any other identities in the (see Section 9.2.1), but some do not change any other identities in
message. The scenario described in Section 9.3, sub-section 1.2, is the message. The scenario described in Section 9.2.2, sub-section
another example. Documents that define other identities should 1.2, is another example. Documents that define other identities will
define the method for explicit approval. have to define the method for explicit approval.
It is possible that mail receivers will use the SPF check as part of It is possible that mail receivers will use the SPF check as part of
a larger set of tests on incoming mail. The results of other tests a larger set of tests on incoming mail. The results of other tests
may influence whether or not a particular SPF check is performed. might influence whether or not a particular SPF check is performed.
For example, finding the sending host's IP address on a local white For example, finding the sending host's IP address on a local white
list may cause all other tests to be skipped and all mail from that list might cause all other tests to be skipped and all mail from that
host to be accepted. host to be accepted.
When a mail receiver decides to perform an SPF check, it MUST use a When a mail receiver decides to perform an SPF check, it MUST use a
correctly-implemented check_host() function (Section 4) evaluated correctly-implemented check_host() function (Section 4) evaluated
with the correct parameters. Although the test as a whole is with the correct parameters. Although the test as a whole is
optional, once it has been decided to perform a test it must be optional, once it has been decided to perform a test it has to be
performed as specified so that the correct semantics are preserved performed as specified so that the correct semantics are preserved
between publisher and receiver. between publisher and receiver.
To make the test, the mail receiver MUST evaluate the check_host() To make the test, the mail receiver MUST evaluate the check_host()
function with the arguments set as follows: function with the arguments set as follows:
<ip> - the IP address of the SMTP client that is emitting the <ip> - the IP address of the SMTP client that is emitting the
mail, either IPv4 or IPv6. mail, either IPv4 or IPv6.
<domain> - the domain portion of the "MAIL FROM" or "HELO" identity. <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
<sender> - the "MAIL FROM" or "HELO" identity. <sender> - the "MAIL FROM" or "HELO" identity.
Note that the <domain> argument may not be a well-formed domain name. Note that the <domain> argument might not be a well-formed domain
For example, if the reverse-path was null, then the EHLO/HELO domain name. For example, if the reverse-path was null, then the EHLO/HELO
is used, with its associated problems (see Section 2.1). In these domain is used, with its associated problems (see Section 2.1). In
cases, check_host() is defined in Section 4.3 to return a "None" these cases, check_host() is defined in Section 4.3 to return a
result. "none" result.
Although invalid, malformed, or non-existent domains cause SPF checks Although invalid, malformed, or non-existent domains cause SPF checks
to return "None" because no SPF record can be found, it has long been to return "none" because no SPF record can be found, it has long been
the policy of many MTAs to reject E-Mail from such domains, the policy of many MTAs to reject email from such domains, especially
especially in the case of invalid "MAIL FROM". In order to prevent in the case of invalid "MAIL FROM". Rejecting email will prevent one
the circumvention of SPF records, rejecting E-Mail from invalid method of circumventing of SPF records.
domains should be considered.
Implementations must take care to correctly extract the <domain> from Implementations have to take care to correctly extract the <domain>
the data given with the SMTP MAIL FROM command as many MTAs will from the data given with the SMTP MAIL FROM command as many MTAs will
still accept such things as source routes (see [RFC2821], Appendix still accept such things as source routes (see [RFC5321], Appendix
C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
These archaic features have been maliciously used to bypass security These archaic features have been maliciously used to bypass security
systems. systems.
2.5. Interpreting the Result 2.5. Interpreting the Result
This section describes how software that performs the authorization This section describes how software that performs the authorization
should interpret the results of the check_host() function. The interprets the results of the check_host() function. The
authorization check SHOULD be performed during the processing of the authorization check SHOULD be performed during the processing of the
SMTP transaction that sends the mail. This allows errors to be SMTP transaction that sends the mail. This allows errors to be
returned directly to the sending MTA by way of SMTP replies. returned directly to the sending MTA by way of SMTP replies.
Performing the authorization after the SMTP transaction has finished Performing the authorization other than using the return-path and
may cause problems, such as the following: (1) It may be difficult to client address at the time of the MAIL command during the SMTP
accurately extract the required information from potentially transaction can cause problems, such as the following: (1) It might
deceptive headers; (2) legitimate E-Mail may fail because the be difficult to accurately extract the required information from
sender's policy may have since changed. potentially deceptive headers; (2) legitimate email might fail
because the sender's policy had since changed.
Generating non-delivery notifications to forged identities that have Generating non-delivery notifications to forged identities that have
failed the authorization check is generally abusive and against the failed the authorization check is a source of backscatter and SHOULD
explicit wishes of the identity owner. be avoided. [RFC3834] section 2 describes backscatter and the
problems it causes.
2.5.1. None 2.5.1. None
A result of "None" means that no records were published by the domain A result of "none" means either (a) no syntactically valid DNS domain
or that no checkable sender domain could be determined from the given name was extracted from the SMTP session that could be used as the
identity. The checking software cannot ascertain whether or not the one to be authorized, or (b) no TXT records were retrieved from the
client host is authorized. DNS that appeared to be intended for use by SPF verifiers.
2.5.2. Neutral 2.5.2. Neutral
The domain owner has explicitly stated that he cannot or does not The domain owner has explicitly stated that they cannot or do not
want to assert whether or not the IP address is authorized. A want to assert whether the IP address is authorized or not. A
"Neutral" result MUST be treated exactly like the "None" result; the "neutral" result MUST be treated exactly like the "none" result; the
distinction exists only for informational purposes. Treating distinction exists only for informational purposes. Treating
"Neutral" more harshly than "None" would discourage domain owners "neutral" more harshly than "none" would discourage domain owners
from testing the use of SPF records (see Section 9.1). from testing the use of SPF records (see Section 9.1).
2.5.3. Pass 2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail A "pass" result means that the client is authorized to inject mail
with the given identity. The domain can now, in the sense of with the given identity. The domain can now, in the sense of
reputation, be considered responsible for sending the message. reputation, be considered responsible for sending the message.
Further policy checks can now proceed with confidence in the Further policy checks can now proceed with confidence in the
legitimate use of the identity. legitimate use of the identity. This is further discussed in
Section 9.3.1.
2.5.4. Fail 2.5.4. Fail
A "Fail" result is an explicit statement that the client is not A "fail" result is an explicit statement that the client is not
authorized to use the domain in the given identity. The checking authorized to use the domain in the given identity. Disposition of
software can choose to mark the mail based on this or to reject the SPF fail messages is a matter of local policy. See Section 9.3.2 for
mail outright. considerations on developing local policy.
If the checking software chooses to reject the mail during the SMTP If the checking software chooses to reject the mail during the SMTP
transaction, then it SHOULD use an SMTP reply code of 550 (see transaction, then it SHOULD use an SMTP reply code of 550 (see
[RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification [RFC5321]) and, if supported, the 5.7.1 enhanced status code (see
(DSN) code (see [RFC3464]), in addition to an appropriate reply text. [RFC3463]), in addition to an appropriate reply text. The
The check_host() function may return either a default explanation check_host() function will return either a default explanation string
string or one from the domain that published the SPF records (see or one from the domain that published the SPF records (see
Section 6.2). If the information does not originate with the Section 6.2). If the information does not originate with the
checking software, it should be made clear that the text is provided checking software, it is good to make it clear that the text is
by the sender's domain. For example: provided by the sender's domain. For example:
550-5.7.1 SPF MAIL FROM check failed: 550-5.7.1 SPF MAIL FROM check failed:
550-5.7.1 The domain example.com explains: 550-5.7.1 The domain example.com explains:
550 5.7.1 Please see http://www.example.com/mailpolicy.html 550 5.7.1 Please see http://www.example.com/mailpolicy.html
2.5.5. SoftFail If the checking software chooses not to reject the mail during the
SMTP transaction, then it SHOULD add a Received-SPF or
Authentication-Results header field (see Section 7) to communicate
this result to downstream message processors. While this is true for
all SPF results, it is of particular importance for "fail" results
since the message is explicitly not authorized by the domain owner.
A "SoftFail" result should be treated as somewhere between a "Fail" 2.5.5. Softfail
and a "Neutral". The domain believes the host is not authorized but
is not willing to make that strong of a statement. Receiving A "softfail" result ought to be treated as somewhere between "fail"
software SHOULD NOT reject the message based solely on this result, and "neutral"/"none". The domain owner believes the host is not
but MAY subject the message to closer scrutiny than normal. authorized but is not willing to make a strong policy statement.
Receiving software SHOULD NOT reject the message based solely on this
result, but MAY subject the message to closer scrutiny than normal.
The domain owner wants to discourage the use of this host and thus The domain owner wants to discourage the use of this host and thus
desires limited feedback when a "SoftFail" result occurs. For desires limited feedback when a "softfail" result occurs. For
example, the recipient's Mail User Agent (MUA) could highlight the example, the recipient's Mail User Agent (MUA) could highlight the
"SoftFail" status, or the receiving MTA could give the sender a "softfail" status, or the receiving MTA could give the sender a
message using a technique called "greylisting" whereby the MTA can message using greylisting, [RFC6647], with a note the first time the
issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the message is received, but accept it on a later attempt based on
first time the message is received, but accept it the second time. receiver policy.
2.5.6. TempError 2.5.6. Temperror
A "TempError" result means that the SPF client encountered a A "temperror" result means the SPF verifier encountered a transient
transient error while performing the check. Checking software can (generally DNS) error while performing the check. Checking software
choose to accept or temporarily reject the message. If the message can choose to accept or temporarily reject the message. If the
is rejected during the SMTP transaction for this reason, the software message is rejected during the SMTP transaction for this reason, the
SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN software SHOULD use an SMTP reply code of 451 and, if supported, the
code. 4.4.3 enhanced status code. These errors can be caused by problems
in either the sender's or receiver's DNS software.
2.5.7. PermError 2.5.7. Permerror
A "PermError" result means that the domain's published records could A "permerror" result means the domain's published records could not
not be correctly interpreted. This signals an error condition that be correctly interpreted. This signals an error condition that
requires manual intervention to be resolved, as opposed to the definitely requires manual intervention to be resolved. If the
TempError result. Be aware that if the domain owner uses macros message is rejected during the SMTP transaction for this reason, the
(Section 8), it is possible that this result is due to the checked software SHOULD use an SMTP reply code of 550 and, if supported, the
identities having an unexpected format. 5.5.2 enhanced status code. Be aware that if the domain owner uses
macros (Section 8), it is possible that this result is due to the
checked identities having an unexpected format. It is also possible
that this result is generated by certain SPF clients due to the input
arguments having an unexpected format; see Section 4.8.
3. SPF Records 3. SPF Records
An SPF record is a DNS Resource Record (RR) that declares which hosts An SPF record is a DNS record that declares which hosts are, and are
are, and are not, authorized to use a domain name for the "HELO" and not, authorized to use a domain name for the "HELO" and "MAIL FROM"
"MAIL FROM" identities. Loosely, the record partitions all hosts identities. Loosely, the record partitions all hosts into permitted
into permitted and not-permitted sets (though some hosts might fall and not-permitted sets (though some hosts might fall into neither
into neither category). category).
The SPF record is a single string of text. An example record is the The SPF record is a single string of text. The record format is
following: described below in Section 4. An example record is the following:
v=spf1 +mx a:colo.example.com/28 -all v=spf1 +mx a:colo.example.com/28 -all
This record has a version of "spf1" and three directives: "+mx", This record has a version of "spf1" and three directives: "+mx",
"a:colo.example.com/28" (the + is implied), and "-all". "a:colo.example.com/28" (the + is implied), and "-all".
3.1. Publishing Each SPF record is placed in the DNS tree at the host name it
Domain owners wishing to be SPF compliant must publish SPF records
for the hosts that are used in the "MAIL FROM" and "HELO" identities.
The SPF records are placed in the DNS tree at the host name it
pertains to, not a subdomain under it, such as is done with SRV pertains to, not a subdomain under it, such as is done with SRV
records. This is the same whether the TXT or SPF RR type (see records [RFC2782].
Section 3.1.1) is used.
The example above in Section 3 might be published via these lines in The example in this section might be published via these lines in a
a domain zone file: domain zone file:
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all" example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. TXT "v=spf1 a -all" smtp-out.example.com. TXT "v=spf1 a -all"
When publishing via TXT records, beware of other TXT records Since TXT records have multiple uses, beware of other TXT records
published there for other purposes. They may cause problems with published there for other purposes. They might cause problems with
size limits (see Section 3.1.4). size limits (see Section 3.4) and care has to be taken to ensure only
SPF records are used for SPF processing.
3.1.1. DNS Resource Record Types
This document defines a new DNS RR of type SPF, code 99. The format
of this type is identical to the TXT RR [RFC1035]. For either type,
the character content of the record is encoded as [US-ASCII].
It is recognized that the current practice (using a TXT record) is
not optimal, but it is necessary because there are a number of DNS
server and resolver implementations in common use that cannot handle
the new RR type. The two-record-type scheme provides a forward path
to the better solution of using an RR type reserved for this purpose.
An SPF-compliant domain name SHOULD have SPF records of both RR ADMDs publishing SPF records SHOULD try to keep the number of
types. A compliant domain name MUST have a record of at least one "include" mechanisms and chained "redirect" modifiers to a minimum.
type. If a domain has records of both types, they MUST have ADMDs SHOULD also try to minimize the amount of other DNS information
identical content. For example, instead of publishing just one needed to evaluate a record. Section 4.6.4 and Section 9.1.1 provide
record as in Section 3.1 above, it is better to publish: some suggestions on how to achieve this.
example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all" 3.1. DNS Resource Records
example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
Example RRs in this document are shown with the TXT record type; SPF records MUST be published as a DNS TXT (type 16) Resource Record
however, they could be published with the SPF type or with both (RR) [RFC1035] only. The character content of the record is encoded
types. as [US-ASCII]. Use of alternate DNS RR types was supported in SPF's
experimental phase, but has been discontinued. See Appendix A of
[RFC6686] for further information.
3.1.2. Multiple DNS Records 3.2. Multiple DNS Records
A domain name MUST NOT have multiple records that would cause an A domain name MUST NOT have multiple records that would cause an
authorization check to select more than one record. See Section 4.5 authorization check to select more than one record. See Section 4.5
for the selection rules. for the selection rules.
3.1.3. Multiple Strings in a Single DNS record 3.3. Multiple Strings in a Single DNS record
As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
record (either TXT or SPF RR types) can be composed of more than one record can be composed of more than one string. If a published
string. If a published record contains multiple strings, then the record contains multiple character-strings, then the record MUST be
record MUST be treated as if those strings are concatenated together treated as if those strings are concatenated together without adding
without adding spaces. For example: spaces. For example:
IN TXT "v=spf1 .... first" "second string..." IN TXT "v=spf1 .... first" "second string..."
MUST be treated as equivalent to MUST be treated as equivalent to
IN TXT "v=spf1 .... firstsecond string..." IN TXT "v=spf1 .... firstsecond string..."
SPF or TXT records containing multiple strings are useful in TXT records containing multiple strings are useful in constructing
constructing records that would exceed the 255-byte maximum length of records that would exceed the 255-byte maximum length of a character-
a string within a single TXT or SPF RR record. string within a single TXT record.
3.1.4. Record Size 3.4. Record Size
The published SPF record for a given domain name SHOULD remain small The published SPF record for a given domain name SHOULD remain small
enough that the results of a query for it will fit within 512 octets. enough that the results of a query for it will fit within 512 octets.
This will keep even older DNS implementations from falling over to This UDP limit is defined in [RFC1035] section 2.3.4. This will keep
TCP. Since the answer size is dependent on many things outside the even older DNS implementations from falling over to TCP. Since the
scope of this document, it is only possible to give this guideline: answer size is dependent on many things outside the scope of this
If the combined length of the DNS name and the text of all the document, it is only possible to give this guideline: If the combined
records of a given type (TXT or SPF) is under 450 characters, then length of the DNS name and the text of all the records of a given
DNS answers should fit in UDP packets. Note that when computing the type is under 450 characters, then DNS answers ought to fit in UDP
sizes for queries of the TXT format, one must take into account any packets. Note that when computing the sizes for queries of the TXT
other TXT records published at the domain name. Records that are too format, one has to take into account any other TXT records published
long to fit in a single UDP packet MAY be silently ignored by SPF at the domain name. Records that are too long to fit in a single UDP
clients. packet could be silently ignored by SPF verifiers due to firewall and
other issues that cause DNS over TCP to be less reliable than DNS
3.1.5. Wildcard Records over UDP.
Use of wildcard records for publishing is not recommended. Care must 3.5. Wildcard Records
be taken if wildcard records are used. If a domain publishes
wildcard MX records, it may want to publish wildcard declarations,
subject to the same requirements and problems. In particular, the
declaration must be repeated for any host that has any RR records at
all, and for subdomains thereof. For example, the example given in
[RFC1034], Section 4.3.3, could be extended with the following:
X.COM. MX 10 A.X.COM Use of wildcard records for publishing is discouraged and care has to
X.COM. TXT "v=spf1 a:A.X.COM -all" be taken if they are used. If a zone includes wildcard MX records,
it might want to publish wildcard declarations, subject to the same
requirements and problems. In particular, the declaration MUST be
repeated for any host that has any RR records at all, and for
subdomains thereof. Consider the example in [RFC1034], Section
4.3.3. Based on that, we can do the following:
*.X.COM. MX 10 A.X.COM EXAMPLE.COM. MX 10 A.EXAMPLE.COM
*.X.COM. TXT "v=spf1 a:A.X.COM -all" EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
A.X.COM. A 1.2.3.4 *.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
A.X.COM. MX 10 A.X.COM *.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
A.X.COM. TXT "v=spf1 a:A.X.COM -all"
*.A.X.COM. MX 10 A.X.COM A.EXAMPLE.COM. A 203.0.113.1
*.A.X.COM. TXT "v=spf1 a:A.X.COM -all" A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
Notice that SPF records must be repeated twice for every name within *.A.EXAMPLE.COM. MX 10 A.EXAMPLE.COM
the domain: once for the name, and once with a wildcard to cover the *.A.EXAMPLE.COM. TXT "v=spf1 a:A.EXAMPLE.COM -all"
tree under the name.
Use of wildcards is discouraged in general as they cause every name SPF records have to be listed twice for every name within the zone:
under the domain to exist and queries against arbitrary names will once for the name, and once with a wildcard to cover the tree under
never return RCODE 3 (Name Error). the name, in order to cover all domains in use in outgoing mail.
4. The check_host() Function 4. The check_host() Function
This description is not an API (Application Program Interface)
definition, but rather a function description used to illustrate the
algorithm. A compliant SPF implementation MUST do something
semantically equivalent to this description.
The check_host() function fetches SPF records, parses them, and The check_host() function fetches SPF records, parses them, and
interprets them to determine whether a particular host is or is not evaluates them to determine whether a particular host is or is not
permitted to send mail with a given identity. Mail receivers that permitted to send mail with a given identity. Mail receivers that
perform this check MUST correctly evaluate the check_host() function perform this check MUST correctly evaluate the check_host() function
as described here. as described here.
Implementations MAY use a different algorithm than the canonical Implementations MAY use a different algorithm than the canonical
algorithm defined here, so long as the results are the same in all algorithm defined here, so long as the results are the same in all
cases. cases.
4.1. Arguments 4.1. Arguments
skipping to change at page 13, line 12 skipping to change at page 17, line 40
information; initially, the domain portion of the "MAIL information; initially, the domain portion of the "MAIL
FROM" or "HELO" identity. FROM" or "HELO" identity.
<sender> - the "MAIL FROM" or "HELO" identity. <sender> - the "MAIL FROM" or "HELO" identity.
The domain portion of <sender> will usually be the same as the The domain portion of <sender> will usually be the same as the
<domain> argument when check_host() is initially evaluated. However, <domain> argument when check_host() is initially evaluated. However,
this will generally not be true for recursive evaluations (see this will generally not be true for recursive evaluations (see
Section 5.2 below). Section 5.2 below).
Actual implementations of the check_host() function may need
additional arguments.
4.2. Results 4.2. Results
The function check_host() can return one of several results described The function check_host() can return one of several results described
in Section 2.5. Based on the result, the action to be taken is in Section 2.5. Based on the result, the action to be taken is
determined by the local policies of the receiver. determined by the local policies of the receiver.
4.3. Initial Processing 4.3. Initial Processing
If the <domain> is malformed (label longer than 63 characters, zero- If the <domain> is malformed (e.g. label longer than 63 characters,
length label not at the end, etc.) or is not a fully qualified domain zero-length label not at the end, etc.) or is not a fully qualified
name, or if the DNS lookup returns "domain does not exist" (RCODE 3), domain name, or if the DNS lookup returns "domain does not exist"
check_host() immediately returns the result "None". (RCODE 3), check_host() immediately returns the result "none".
Properly formed domains are fully qualified email domains as
described in [RFC5321] Section 2.3.5. Internationalized domain names
MUST be encoded as A-labels, as described in Section 2.3 of
[RFC5890].on 2.3 of [RFC5890].
If the <sender> has no localpart, substitute the string "postmaster" If the <sender> has no local-part, substitute the string "postmaster"
for the localpart. for the local-part.
4.4. Record Lookup 4.4. Record Lookup
In accordance with how the records are published (see Section 3.1 In accordance with how the records are published (see Section 3
above), a DNS query needs to be made for the <domain> name, querying above), a DNS query needs to be made for the <domain> name, querying
for either RR type TXT, SPF, or both. If both SPF and TXT RRs are for type TXT only.
looked up, the queries MAY be done in parallel.
If all DNS lookups that are made return a server failure (RCODE 2), If all DNS lookups that are made return a server failure (RCODE 2),
or other error (RCODE other than 0 or 3), or time out, then or other error (RCODE other than 0 or 3), or time out, then
check_host() exits immediately with the result "TempError". check_host() terminates immediately with the result "temperror".
Alternatively, for a server failure (RCODE 2) result, check_host()
MAY track failures and treat multiple failures within 24 hours for
the same domain as "permerror".
This alternative is intended to shorten the queue time of messages
that cannot be accepted, by returning a permanent negative completion
reply code to the client, instead of a transient one. [RFC2308]
suggests on an algorithm for doing such tracking and handling of
server failure codes.
4.5. Selecting Records 4.5. Selecting Records
Records begin with a version section: Records begin with a version section:
record = version terms *SP record = version terms *SP
version = "v=spf1" version = "v=spf1"
Starting with the set of records that were returned by the lookup, Starting with the set of records that were returned by the lookup,
record selection proceeds in two steps: discard records that do not begin with a version section of exactly
"v=spf1". Note that the version section is terminated either by an
1. Records that do not begin with a version section of exactly SP character or the end of the record. A record with a version
"v=spf1" are discarded. Note that the version section is section of "v=spf10" does not match and MUST be discarded.
terminated either by an SP character or the end of the record. A
record with a version section of "v=spf10" does not match and must
be discarded.
2. If any records of type SPF are in the set, then all records of
type TXT are discarded.
After the above steps, there should be exactly one record remaining
and evaluation can proceed. If there are two or more records
remaining, then check_host() exits immediately with the result of
"PermError".
If no matching records are returned, an SPF client MUST assume that If the resultant record set includes no records, check_host()
the domain makes no SPF declarations. SPF processing MUST stop and produces the "none" result. If the resultant record set includes
return "None". more than one record, check_host() produces the "permerror" result.
4.6. Record Evaluation 4.6. Record Evaluation
After one SPF record has been selected, the check_host() function The check_host() function parses and interprets the SPF record to
parses and interprets it to find a result for the current test. If find a result for the current test. If there are any syntax errors,
there are any syntax errors, check_host() returns immediately with check_host() returns immediately with the result "permerror".
the result "PermError".
Implementations MAY choose to parse the entire record first and Implementations MAY choose to parse the entire record first and
return "PermError" if the record is not syntactically well formed. return "permerror" if the record is not syntactically well formed.
However, in all cases, any syntax errors anywhere in the record MUST However, in all cases, any syntax errors anywhere in the record MUST
be detected. be detected.
4.6.1. Term Evaluation 4.6.1. Term Evaluation
There are two types of terms: mechanisms and modifiers. A record There are two types of terms: mechanisms and modifiers. A record
contains an ordered list of these as specified in the following contains an ordered list of these as specified in the following
Augmented Backus-Naur Form (ABNF). Augmented Backus-Naur Form (ABNF).
terms = *( 1*SP ( directive / modifier ) ) terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~" qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include mechanism = ( all / include
/ A / MX / PTR / IP4 / IP6 / exists ) / A / MX / PTR / IP4 / IP6 / exists )
modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string
; where name is not any known modifier
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
Most mechanisms allow a ":" or "/" character after the name. Most mechanisms allow a ":" or "/" character after the name.
Modifiers always contain an equals ('=') character immediately after Modifiers always contain an equals ('=') character immediately after
the name, and before any ":" or "/" characters that may be part of the name, and before any ":" or "/" characters that might be part of
the macro-string. the macro-string.
Terms that do not contain any of "=", ":", or "/" are mechanisms, as Terms that do not contain any of "=", ":", or "/" are mechanisms, as
defined in Section 5. defined in Section 5.
As per the definition of the ABNF notation in [RFC4234], mechanism As per the definition of the ABNF notation in [RFC5234], mechanism
and modifier names are case-insensitive. and modifier names are case-insensitive.
4.6.2. Mechanisms 4.6.2. Mechanisms
Each mechanism is considered in turn from left to right. If there Each mechanism is considered in turn from left to right. If there
are no more mechanisms, the result is specified in Section 4.7. are no more mechanisms, the result is specified in Section 4.7.
When a mechanism is evaluated, one of three things can happen: it can When a mechanism is evaluated, one of three things can happen: it can
match, not match, or throw an exception. match, not match, or return an exception.
If it matches, processing ends and the qualifier value is returned as If it matches, processing ends and the qualifier value is returned as
the result of that record. If it does not match, processing the result of that record. If it does not match, processing
continues with the next mechanism. If it throws an exception, continues with the next mechanism. If it returns an exception,
mechanism processing ends and the exception value is returned. mechanism processing ends and the exception value is returned.
The possible qualifiers, and the results they return are as follows: The possible qualifiers, and the results they cause check_host() to
return are as follows:
"+" Pass "+" pass
"-" Fail "-" fail
"~" SoftFail "~" softfail
"?" Neutral "?" neutral
The qualifier is optional and defaults to "+". The qualifier is optional and defaults to "+".
When a mechanism matches and the qualifier is "-", then a "Fail" When a mechanism matches and the qualifier is "-", then a "fail"
result is returned and the explanation string is computed as result is returned and the explanation string is computed as
described in Section 6.2. described in Section 6.2.
The specific mechanisms are described in Section 5. The specific mechanisms are described in Section 5.
4.6.3. Modifiers 4.6.3. Modifiers
Modifiers are not mechanisms: they do not return match or not-match. Modifiers are not mechanisms. They do not return match or not-match.
Instead they provide additional information. Although modifiers do Instead, they provide additional information. Although modifiers do
not directly affect the evaluation of the record, the "redirect" not directly affect the evaluation of the record, the "redirect"
modifier has an effect after all the mechanisms have been evaluated. modifier has an effect after all the mechanisms have been evaluated.
4.6.4. DNS Lookup Limits
SPF implementations MUST limit the number of mechanisms and modifiers
("terms") that cause any DNS query to at most 10 during SPF
evaluation. Specifically, the "include", "a", "mx", "ptr", and
"exists" mechanisms as well as the "redirect" modifier count against
this limit. The "all", "ip4", and "ip6" mechanisms do not count
against this limit. If this number is exceeded during a check, a
permerror MUST be returned. The "exp" modifier does not count
against this limit because the DNS lookup to fetch the explanation
string occurs after the SPF record evaluation has been completed.
When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
there MUST be a limit of no more than 10 MX or PTR RRs looked up and
checked. If more than 10 "mx" or "ptr" records are returned for this
further lookup, a permerror MUST be returned. This limit is per
mechanism or macro in the record and in addition to the lookup limits
above.
MTAs or other processors SHOULD impose a limit on the maximum amount
of elapsed time to evaluate check_host(). Such a limit SHOULD allow
at least 20 seconds. If such a limit is exceeded, the result of
authorization SHOULD be "temperror".
4.7. Default Result 4.7. Default Result
If none of the mechanisms match and there is no "redirect" modifier, If none of the mechanisms match and there is no "redirect" modifier,
then the check_host() returns a result of "Neutral", just as if then the check_host() returns a result of "neutral", just as if
"?all" were specified as the last directive. If there is a "?all" were specified as the last directive. If there is a
"redirect" modifier, check_host() proceeds as defined in Section 6.1. "redirect" modifier, check_host() proceeds as defined in Section 6.1.
Note that records SHOULD always use either a "redirect" modifier or Note that records SHOULD always use either a "redirect" modifier or
an "all" mechanism to explicitly terminate processing. an "all" mechanism to explicitly terminate processing. Although the
latter has default (specifically "?all"), it aids debugging efforts
if it is explicitly included.
For example: For example:
v=spf1 +mx -all v=spf1 +mx -all
or or
v=spf1 +mx redirect=_spf.example.com v=spf1 +mx redirect=_spf.example.com
4.8. Domain Specification 4.8. Domain Specification
Several of these mechanisms and modifiers have a <domain-spec> Several of these mechanisms and modifiers have a domain-spec section.
section. The <domain-spec> string is macro expanded (see Section 8). The domain-spec string is subject to macro expansion (see Section 8).
The resulting string is the common presentation form of a fully- The resulting string is the common presentation form of a fully-
qualified DNS name: a series of labels separated by periods. This qualified DNS name: a series of labels separated by periods. This
domain is called the <target-name> in the rest of this document. domain is called the <target-name> in the rest of this document.
Note: The result of the macro expansion is not subject to any further Note: The result of the macro expansion is not subject to any further
escaping. Hence, this facility cannot produce all characters that escaping. Hence, this facility cannot produce all characters that
are legal in a DNS label (e.g., the control characters). However, are legal in a DNS label (e.g., the control characters). However,
this facility is powerful enough to express legal host names and this facility is powerful enough to express legal host names and
common utility labels (such as "_spf") that are used in DNS. common utility labels (such as "_spf") that are used in DNS.
For several mechanisms, the <domain-spec> is optional. If it is not For several mechanisms, the <domain-spec> is optional. If it is not
provided, the <domain> is used as the <target-name>. provided, the <domain> is used as the <target-name>. Domain and
domain-spec are syntactically identical after macro expansion.
Domain is an input value for check_host() while domain-spec is
computed by check_host().
Note: Historically, this document has made no provisions for how to
handle domain-specs, or macro-expansions thereof, that are
syntactically invalid per [RFC1035], such as names with empty labels
(e.g., "foo..example.com") or overlong labels (more than 63
characters). Some implementations choose to treat as a no-match
mechanisms, and ignore modifiers, with such names, whereas others
return a "permerror" exception. The outcome for an unexpected
domain-spec without macros might even differ from that for an
unexpected target-name after macro expansion.
5. Mechanism Definitions 5. Mechanism Definitions
This section defines two types of mechanisms. This section defines two types of mechanisms.
Basic mechanisms contribute to the language framework. They do not Basic mechanisms contribute to the language framework. They do not
specify a particular type of authorization scheme. specify a particular type of authorization scheme.
all all
include include
Designated sender mechanisms are used to designate a set of <ip> Designated sender mechanisms are used to designate a set of <ip>
addresses as being permitted or not permitted to use the <domain> for addresses as being permitted or not permitted to use the <domain> for
sending mail. sending mail.
a a
mx mx
ptr ptr (deprecated)
ip4 ip4
ip6 ip6
exists exists
The following conventions apply to all mechanisms that perform a The following conventions apply to all mechanisms that perform a
comparison between <ip> and an IP address at any point: comparison between <ip> and an IP address at any point:
If no CIDR-length is given in the directive, then <ip> and the IP If no CIDR prefix length is given in the directive, then <ip> and the
address are compared for equality. (Here, CIDR is Classless Inter- IP address are compared for equality. (Here, CIDR is Classless
Domain Routing.) Inter-Domain Routing, described in [RFC4632].)
If a CIDR-length is specified, then only the specified number of If a CIDR prefix length is specified, then only the specified number
high-order bits of <ip> and the IP address are compared for equality. of high-order bits of <ip> and the IP address are compared for
equality.
When any mechanism fetches host addresses to compare with <ip>, when When any mechanism fetches host addresses to compare with <ip>, when
<ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6 <ip> is an IPv4 address, A records are fetched; when <ip> is an IPv6
address, AAAA records are fetched. Even if the SMTP connection is address, AAAA records are fetched. Even if the SMTP connection uses
via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section IPv6, an IPv4-mapped IPv6 IP address (see [RFC4291], Section 2.5.5)
2.5.5) MUST still be considered an IPv4 address. MUST still be considered an IPv4 address and MUST be evaluated using
IPv4 mechanisms (i.e. "ip4" and "a").
Several mechanisms rely on information fetched from DNS. For these Several mechanisms rely on information fetched from the DNS. For
DNS queries, except where noted, if the DNS server returns an error these DNS queries, except where noted, if the DNS server returns an
(RCODE other than 0 or 3) or the query times out, the mechanism error (RCODE other than 0 or 3) or the query times out, the mechanism
throws the exception "TempError". If the server returns "domain does stops and the topmost check_host() returns "temperror". If the
not exist" (RCODE 3), then evaluation of the mechanism continues as server returns "domain does not exist" (RCODE 3), then evaluation of
if the server returned no error (RCODE 0) and zero answer records. the mechanism continues as if the server returned no error (RCODE 0)
and zero answer records.
5.1. "all" 5.1. "all"
all = "all" all = "all"
The "all" mechanism is a test that always matches. It is used as the The "all" mechanism is a test that always matches. It is used as the
rightmost mechanism in a record to provide an explicit default. rightmost mechanism in a record to provide an explicit default.
For example: For example:
v=spf1 a mx -all v=spf1 a mx -all
Mechanisms after "all" will never be tested. Any "redirect" modifier Mechanisms after "all" will never be tested. Mechanisms listed after
(Section 6.1) has no effect when there is an "all" mechanism. "all" MUST be ignored. Any "redirect" modifier (Section 6.1) MUST be
ignored when there is an "all" mechanism in the record.
5.2. "include" 5.2. "include"
include = "include" ":" domain-spec include = "include" ":" domain-spec
The "include" mechanism triggers a recursive evaluation of The "include" mechanism triggers a recursive evaluation of
check_host(). The domain-spec is expanded as per Section 8. Then check_host().
check_host() is evaluated with the resulting string as the <domain>.
The <ip> and <sender> arguments remain the same as in the current 1. The domain-spec is expanded as per Section 8.
evaluation of check_host().
2. Check_host() is evaluated with the resulting string as the
<domain>. The <ip> and <sender> arguments remain the same as in
the current evaluation of check_host().
3. The recursive evaluation returns either match, not match, or an
error. If it matches, then the appropriate result for the
include: mechanism is used (e.g. include or +include gives a
"pass" result and -include gives "fail).
4. If there is no match, the parent check_host() resumes processing
as per the table below, with the previous value of <domain>
restored.
In hindsight, the name "include" was poorly chosen. Only the In hindsight, the name "include" was poorly chosen. Only the
evaluated result of the referenced SPF record is used, rather than evaluated result of the referenced SPF record is used, rather than
acting as if the referenced SPF record was literally included in the acting as if the referenced SPF record was literally included in the
first. For example, evaluating a "-all" directive in the referenced first. For example, evaluating a "-all" directive in the referenced
record does not terminate the overall processing and does not record does not terminate the overall processing and does not
necessarily result in an overall "Fail". (Better names for this necessarily result in an overall "fail". (Better names for this
mechanism would have been "if-pass", "on-pass", etc.) mechanism would have been "if-match", "on-match", etc.)
The "include" mechanism makes it possible for one domain to designate The "include" mechanism makes it possible for one domain to designate
multiple administratively-independent domains. For example, a vanity multiple administratively-independent domains. For example, a vanity
domain "example.net" might send mail using the servers of domain "example.net" might send mail using the servers of
administratively-independent domains example.com and example.org. administratively-independent domains example.com and example.org.
Example.net could say Example.net could say
IN TXT "v=spf1 include:example.com include:example.org -all" IN TXT "v=spf1 include:example.com include:example.org -all"
This would direct check_host() to, in effect, check the records of This would direct check_host() to, in effect, check the records of
example.com and example.org for a "Pass" result. Only if the host example.com and example.org for a "pass" result. Only if the host
were not permitted for either of those domains would the result be were not permitted for either of those domains would the result be
"Fail". "fail".
Whether this mechanism matches, does not match, or throws an Whether this mechanism matches, does not match, or returns an
exception depends on the result of the recursive evaluation of exception depends on the result of the recursive evaluation of
check_host(): check_host():
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism | | A recursive check_host() result | Causes the "include" mechanism |
| of: | to: | | of: | to: |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
| Pass | match | | pass | match |
| | | | | |
| Fail | not match | | fail | not match |
| | | | | |
| SoftFail | not match | | softfail | not match |
| | | | | |
| Neutral | not match | | neutral | not match |
| | | | | |
| TempError | throw TempError | | temperror | return temperror |
| | | | | |
| PermError | throw PermError | | permerror | return permerror |
| | | | | |
| None | throw PermError | | none | return permerror |
+---------------------------------+---------------------------------+ +---------------------------------+---------------------------------+
The "include" mechanism is intended for crossing administrative The "include" mechanism is intended for crossing administrative
boundaries. Although it is possible to use includes to consolidate boundaries. For example, if example.com and example.org were managed
multiple domains that share the same set of designated hosts, domains by the same entity, and if the permitted set of hosts for both
are encouraged to use redirects where possible, and to minimize the domains was
number of includes within a single administrative domain. For
example, if example.com and example.org were managed by the same
entity, and if the permitted set of hosts for both domains was
"mx:example.com", it would be possible for example.org to specify "mx:example.com", it would be possible for example.org to specify
"include:example.com", but it would be preferable to specify "include:example.com", but it would be preferable to specify
"redirect=example.com" or even "mx:example.com". "redirect=example.com" or even "mx:example.com".
With the "include" mechanism an administratively external set of
hosts can be authorized, but determination of sender policy is still
a function of the original domain's SPF record (as determined by the
"all" mechanism in that record). The redirect modifier is more
suitable for consolidating both authorizations and policy into a
common set to be shared within an ADMD. Redirect is much more like a
common code element to be shared among records in a single ADMD. It
is possible to control both authorized hosts and policy for an
arbitrary number of domains from a single record.
5.3. "a" 5.3. "a"
This mechanism matches if <ip> is one of the <target-name>'s IP This mechanism matches if <ip> is one of the <target-name>'s IP
addresses. addresses.
A = "a" [ ":" domain-spec ] [ dual-cidr-length ] a = "a" [ ":" domain-spec ] [ dual-cidr-length ]
An address lookup is done on the <target-name>. The <ip> is compared An address lookup is done on the <target-name>. The <ip> is compared
to the returned address(es). If any address matches, the mechanism to the returned address(es). If any address matches, the mechanism
matches. matches.
5.4. "mx" 5.4. "mx"
This mechanism matches if <ip> is one of the MX hosts for a domain This mechanism matches if <ip> is one of the MX hosts for a domain
name. name.
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] mx = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
check_host() first performs an MX lookup on the <target-name>. Then check_host() first performs an MX lookup on the <target-name>. Then
it performs an address lookup on each MX name returned. The <ip> is it performs an address lookup on each MX name returned. The <ip> is
compared to each returned IP address. To prevent Denial of Service compared to each returned IP address. To prevent Denial of Service
(DoS) attacks, more than 10 MX names MUST NOT be looked up during the (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
evaluation of an "mx" mechanism (see Section 10). If any address evaluation of an "mx" mechanism. If there are more than 10 MX names
matches, the mechanism matches. then permerror is returned and the evaluation terminated (see
Section 4.6.4). If any address matches, the mechanism matches.
Note regarding implicit MXs: If the <target-name> has no MX records, Note regarding implicit MXs: If the <target-name> has no MX records,
check_host() MUST NOT pretend the target is its single MX, and MUST check_host() MUST NOT pretend the target is its single MX, and MUST
NOT default to an A lookup on the <target-name> directly. This NOT default to an A or AAAA lookup on the <target-name> directly.
behavior breaks with the legacy "implicit MX" rule. See [RFC2821], This behavior diverges from the legacy "implicit MX" rule, (See
Section 5. If such behavior is desired, the publisher should specify [RFC5321], Section 5. If such behavior is desired, the publisher
an "a" directive. will have to specify an "a" directive).
5.5. "ptr" 5.5. "ptr" (deprecated)
This mechanism tests whether the DNS reverse-mapping for <ip> exists This mechanism tests whether the DNS reverse-mapping for <ip> exists
and correctly points to a domain name within a particular domain. and correctly points to a domain name within a particular domain.
This mechanism is deprecated and SHOULD NOT be used.
PTR = "ptr" [ ":" domain-spec ] ptr = "ptr" [ ":" domain-spec ]
First, the <ip>'s name is looked up using this procedure: perform a The <ip>'s name is looked up using this procedure:
DNS reverse-mapping for <ip>, looking up the corresponding PTR record
in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
if it is an IPv6 address. For each record returned, validate the
domain name by looking up its IP address. To prevent DoS attacks,
more than 10 PTR names MUST NOT be looked up during the evaluation of
a "ptr" mechanism (see Section 10). If <ip> is among the returned IP
addresses, then that domain name is validated. In pseudocode:
sending-domain_names := ptr_lookup(sending-host_IP); if more than 10 1. Perform a DNS reverse-mapping for <ip>: Look up the corresponding
sending-domain_names are found, use at most 10. for each name in PTR record in "in-addr.arpa." if the address is an IPv4 one and
(sending-domain_names) { in "ip6.arpa." if it is an IPv6 address.
IP_addresses := a_lookup(name);
if the sending-domain_IP is one of the IP_addresses {
validated-sending-domain_names += name;
} }
Check all validated domain names to see if they end in the 2. For each record returned, validate the domain name by looking up
<target-name> domain. If any do, this mechanism matches. If no its IP addresses. To prevent DoS attacks, more than 10 PTR names
validated domain name can be found, or if none of the validated MUST NOT be looked up during the evaluation of a "ptr" mechanism
domain names end in the <target-name>, this mechanism fails to match. (see Section 4.6.4).
If a DNS error occurs while doing the PTR RR lookup, then this
mechanism fails to match. If a DNS error occurs while doing an A RR 3. If <ip> is among the returned IP addresses, then that domain name
lookup, then that domain name is skipped and the search continues. is validated.
Check all validated domain names to see if they either match the
<target-name> domain or are a subdomain of the <target-name> domain.
If any do, this mechanism matches. If no validated domain name can
be found, or if none of the validated domain names match or are a
subdomain of the <target-name>, this mechanism fails to match. If a
DNS error occurs while doing the PTR RR lookup, then this mechanism
fails to match. If a DNS error occurs while doing an A RR lookup,
then that domain name is skipped and the search continues.
Pseudocode: Pseudocode:
sending-domain_names := ptr_lookup(sending-host_IP);
if more than 10 sending-domain_names are found, use at most 10.
for each name in (sending-domain_names) {
IP_addresses := a_lookup(name);
if the sending-domain_IP is one of the IP_addresses {
validated-sending-domain_names += name;
}
}
for each name in (validated-sending-domain_names) { for each name in (validated-sending-domain_names) {
if name ends in <domain-spec>, return match. if name ends in <domain-spec>, return match.
if name is <domain-spec>, return match. if name is <domain-spec>, return match.
} }
return no-match. return no-match.
This mechanism matches if the <target-name> is either an ancestor of This mechanism matches if the <target-name> is either a subdomain of
a validated domain name or if the <target-name> and a validated a validated domain name or if the <target-name> and a validated
domain name are the same. For example: "mail.example.com" is within domain name are the same. For example: "mail.example.com" is within
the domain "example.com", but "mail.bad-example.com" is not. the domain "example.com", but "mail.bad-example.com" is not.
Note: Use of this mechanism is discouraged because it is slow, it is Note: This mechanism has been deprecated because it is slow, it is
not as reliable as other mechanisms in cases of DNS errors, and it not as reliable as other mechanisms in cases of DNS errors, and it
places a large burden on the arpa name servers. If used, proper PTR places a large burden on the .arpa name servers. If used, proper PTR
records must be in place for the domain's hosts and the "ptr" records MUST be in place for the domain's hosts and the "ptr"
mechanism should be one of the last mechanisms checked. mechanism SHOULD be one of the last mechanisms checked. After many
years of SPF deployment experience it has been concluded it is
unnecessary and more reliable alternatives used instead. It is,
however, still in use and part of the SPF protocol, so compliant
check_host() implementations MUST support it.
5.6. "ip4" and "ip6" 5.6. "ip4" and "ip6"
These mechanisms test whether <ip> is contained within a given IP These mechanisms test whether <ip> is contained within a given IP
network. network.
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] ip4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] ip6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; as per conventional dotted quad notation. e.g., 192.0.2.0 ; as per conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 3513], section 2.2> ip6-network = <as per [RFC 4291], section 2.2>
; e.g., 2001:DB8::CD30 ; e.g., 2001:DB8::CD30
The <ip> is compared to the given network. If CIDR-length high-order The <ip> is compared to the given network. If CIDR prefix length
bits match, the mechanism matches. high-order bits match, the mechanism matches.
If ip4-cidr-length is omitted, it is taken to be "/32". If If ip4-cidr-length is omitted, it is taken to be "/32". If
ip6-cidr-length is omitted, it is taken to be "/128". It is not ip6-cidr-length is omitted, it is taken to be "/128". It is not
permitted to omit parts of the IP address instead of using CIDR permitted to omit parts of the IP address instead of using CIDR
notations. That is, use 192.0.2.0/24 instead of 192.0.2. notations. That is, use 192.0.2.0/24 instead of 192.0.2.
5.7. "exists" 5.7. "exists"
This mechanism is used to construct an arbitrary domain name that is This mechanism is used to construct an arbitrary domain name that is
used for a DNS A record query. It allows for complicated schemes used for a DNS A record query. It allows for complicated schemes
skipping to change at page 22, line 34 skipping to change at page 28, line 15
Domains can use this mechanism to specify arbitrarily complex Domains can use this mechanism to specify arbitrarily complex
queries. For example, suppose example.com publishes the record: queries. For example, suppose example.com publishes the record:
v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
The <target-name> might expand to The <target-name> might expand to
"1.2.0.192.someuser._spf.example.com". This makes fine-grained "1.2.0.192.someuser._spf.example.com". This makes fine-grained
decisions possible at the level of the user and client IP address. decisions possible at the level of the user and client IP address.
This mechanism enables queries that mimic the style of tests that This mechanism enables queries that mimic the style of tests that
existing anti-spam DNS blacklists (DNSBL) use. existing DNS white/black lists (DNSxLs) use, as described in
[RFC5782]. The query will either return NXDOMAIN (no match), any
valid answer (match), or an error.
6. Modifier Definitions 6. Modifier Definitions
Modifiers are name/value pairs that provide additional information. Modifiers are name/value pairs that provide additional information.
Modifiers always have an "=" separating the name and the value. Modifiers always have an "=" separating the name and the value.
The modifiers defined in this document ("redirect" and "exp") MAY The modifiers defined in this document ("redirect" and "exp") MAY
appear anywhere in the record, but SHOULD appear at the end, after appear anywhere in the record, but SHOULD appear at the end, after
all mechanisms. Ordering of these two modifiers does not matter. all mechanisms. Ordering of these two modifiers does not matter.
These two modifiers MUST NOT appear in a record more than once each. These two modifiers MUST NOT appear in a record more than once each.
If they do, then check_host() exits with a result of "PermError". If they do, then check_host() exits with a result of "permerror".
Unrecognized modifiers MUST be ignored no matter where in a record, Unrecognized modifiers MUST be ignored no matter where in a record,
or how often. This allows implementations of this document to or how often. This allows implementations of this document to
gracefully handle records with modifiers that are defined in other gracefully handle records with modifiers that are defined in other
specifications. specifications.
6.1. redirect: Redirected Query 6.1. redirect: Redirected Query
If all mechanisms fail to match, and a "redirect" modifier is The redirect modifier is intended for consolidating both
present, then processing proceeds as follows: authorizations and policy into a common set to be shared within a
single ADMD. Redirect is like a common code element to be shared
among records in a single ADMD. It is possible to control both
authorized hosts and policy for an arbitrary number of domains from a
single record.
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
If all mechanisms fail to match, and a "redirect" modifier is
present, then processing proceeds as follows:
The domain-spec portion of the redirect section is expanded as per The domain-spec portion of the redirect section is expanded as per
the macro rules in Section 8. Then check_host() is evaluated with the macro rules in Section 8. Then check_host() is evaluated with
the resulting string as the <domain>. The <ip> and <sender> the resulting string as the <domain>. The <ip> and <sender>
arguments remain the same as current evaluation of check_host(). arguments remain the same as in the current evaluation of
check_host().
The result of this new evaluation of check_host() is then considered The result of this new evaluation of check_host() is then considered
the result of the current evaluation with the exception that if no the result of the current evaluation with the exception that if no
SPF record is found, or if the target-name is malformed, the result SPF record is found, or if the target-name is malformed, the result
is a "PermError" rather than "None". is a "permerror" rather than "none".
Note that the newly-queried domain may itself specify redirect Note that the newly-queried domain can itself specify redirect
processing. processing.
This facility is intended for use by organizations that wish to apply This facility is intended for use by organizations that wish to apply
the same record to multiple domains. For example: the same record to multiple domains. For example:
la.example.com. TXT "v=spf1 redirect=_spf.example.com" la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com" ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com" sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all" _spf.example.com. TXT "v=spf1 mx:example.com -all"
In this example, mail from any of the three domains is described by In this example, mail from any of the three domains is described by
the same record. This can be an administrative advantage. the same record. This can be an administrative advantage.
Note: In general, the domain "A" cannot reliably use a redirect to Note: In general, the domain "A" cannot reliably use a redirect to
another domain "B" not under the same administrative control. Since another domain "B" not under the same administrative control. Since
the <sender> stays the same, there is no guarantee that the record at the <sender> stays the same, there is no guarantee that the record at
domain "B" will correctly work for mailboxes in domain "A", domain "B" will correctly work for mailboxes in domain "A",
especially if domain "B" uses mechanisms involving localparts. An especially if domain "B" uses mechanisms involving local-parts. An
"include" directive may be more appropriate. "include" directive is generally be more appropriate.
For clarity, it is RECOMMENDED that any "redirect" modifier appear as For clarity, it is RECOMMENDED that any "redirect" modifier appear as
the very last term in a record. the very last term in a record.
6.2. exp: Explanation 6.2. exp: Explanation
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
If check_host() results in a "Fail" due to a mechanism match (such as If check_host() results in a "fail" due to a mechanism match (such as
"-all"), and the "exp" modifier is present, then the explanation "-all"), and the "exp" modifier is present, then the explanation
string returned is computed as described below. If no "exp" modifier string returned is computed as described below. If no "exp" modifier
is present, then either a default explanation string or an empty is present, then either a default explanation string or an empty
explanation string may be returned. explanation string MUST be returned.
The <domain-spec> is macro expanded (see Section 8) and becomes the The domain-spec is macro expanded (see Section 8) and becomes the
<target-name>. The DNS TXT record for the <target-name> is fetched. <target-name>. The DNS TXT record for the <target-name> is fetched.
If <domain-spec> is empty, or there are any DNS processing errors If there are any DNS processing errors (any RCODE other than 0), or
(any RCODE other than 0), or if no records are returned, or if more if no records are returned, or if more than one record is returned,
than one record is returned, or if there are syntax errors in the or if there are syntax errors in the explanation string, then proceed
explanation string, then proceed as if no exp modifier was given. as if no exp modifier was given.
The fetched TXT record's strings are concatenated with no spaces, and The fetched TXT record's strings are concatenated with no spaces, and
then treated as an <explain-string>, which is macro-expanded. This then treated as an explain-string, which is macro-expanded. This
final result is the explanation string. Implementations MAY limit final result is the explanation string. Implementations MAY limit
the length of the resulting explanation string to allow for other the length of the resulting explanation string to allow for other
protocol constraints and/or reasonable processing limits. Since the protocol constraints and/or reasonable processing limits. Since the
explanation string is intended for an SMTP response and [RFC2821] explanation string is intended for an SMTP response and [RFC5321]
Section 2.4 says that responses are in [US-ASCII], the explanation Section 2.4 says that responses are in [US-ASCII], the explanation
string is also limited to US-ASCII. string MUST be limited to US-ASCII.
Software evaluating check_host() can use this string to communicate Software evaluating check_host() can use this string to communicate
information from the publishing domain in the form of a short message information from the publishing domain in the form of a short message
or URL. Software SHOULD make it clear that the explanation string or URL. Software SHOULD make it clear that the explanation string
comes from a third party. For example, it can prepend the macro comes from a third party. For example, it can prepend the macro
string "%{o} explains: " to the explanation, such as shown in Section string "%{o} explains: " to the explanation, such as shown in
2.5.4. Section 2.5.4.
Suppose example.com has this record: Suppose example.com has this record:
v=spf1 mx -all exp=explain._spf.%{d} v=spf1 mx -all exp=explain._spf.%{d}
Here are some examples of possible explanation TXT records at Here are some examples of possible explanation TXT records at
explain._spf.example.com: explain._spf.example.com:
"Mail from example.com should only be sent by its own servers." "Mail from example.com should only be sent by its own servers."
-- a simple, constant message -- a simple, constant message
"%{i} is not one of %{d}'s designated mail servers." "%{i} is not one of %{d}'s designated mail servers."
-- a message with a little more information, including the IP -- a message with a little more information, including the IP
address that failed the check address that failed the check
"See http://%{d}/why.html?s=%{S}&i=%{I}" "See http://%{d}/why.html?s=%{S}&i=%{I}"
-- a complicated example that constructs a URL with the -- a complicated example that constructs a URL with the
arguments to check_host() so that a web page can be arguments to check_host() so that a web page can be
generated with detailed, custom instructions generated with detailed, custom instructions
Note: During recursion into an "include" mechanism, an exp= modifier Note: During recursion into an "include" mechanism, an exp= modifier
from the <target-name> MUST NOT be used. In contrast, when executing from the <target-name> MUST NOT be used. In contrast, when executing
a "redirect" modifier, an exp= modifier from the original domain MUST a "redirect" modifier, an exp= modifier from the original domain MUST
NOT be used. NOT be used.
7. The Received-SPF Header Field 7. Recording The Result
It is RECOMMENDED that SMTP receivers record the result of SPF To provide downstream agents, such as MUAs, with the information they
processing in the message header. If an SMTP receiver chooses to do might need in terms of evaluating or representing the apparent safety
so, it SHOULD use the "Received-SPF" header field defined here for of the message content, it is RECOMMENDED that SMTP receivers record
each identity that was checked. This information is intended for the the result of SPF processing in the message header. For operators
recipient. (Information intended for the sender is described in that choose to record SPF results in the header of the message for
Section 6.2, Explanation.) processing by internal filters or MUAs, two methods are presented.
Section 7.1 defines the Received-SPF field, which is the results
field originally defined for SPF use. Section 7.2 discusses
Authentication-Results [RFC5451] which was specified more recently
and is designed for use by SPF and other authentication methods.
The Received-SPF header field is a trace field (see [RFC2822] Section Both are in common use, and hence both are included here. However,
it is important to note that they were designed to serve slightly
different purposes. Received-SPF is intended to include enough
forensic information to enable reconstruction of the SPF evaluation
of the message, while Authentication-Results is designed only to
relay the result itself and related output details of likely use to
end users (e.g., what property of the message was actually
authenticated and what it contained), leaving forensic work to the
purview of system logs and the Received field contents. Also,
Received-SPF relies on compliance of agents within the receiving ADMD
to adhere to the header field ordering rules of [RFC5321] and
[RFC5322], while Authentication-Results includes some provisions to
protect against non-compliant implementations.
An operator could choose to use both to serve different downstream
agents. In such cases, care needs to be taken to ensure both fields
are conveying the same details, or unexpected results can occur.
7.1. The Received-SPF Header Field
The Received-SPF header field is a trace field (see [RFC5322] Section
3.6.7) and SHOULD be prepended to the existing header, above the 3.6.7) and SHOULD be prepended to the existing header, above the
Received: field that is generated by the SMTP receiver. It MUST Received: field that is generated by the SMTP receiver. It MUST
appear above all other Received-SPF fields in the message. The appear above all other Received-SPF fields in the message. The
header field has the following format: header field has the following format:
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF [ key-value-list ] CRLF
result = "Pass" / "Fail" / "SoftFail" / "Neutral" / result = "pass" / "fail" / "softfail" / "neutral" /
"None" / "TempError" / "PermError" "none" / "temperror" / "permerror"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"] [";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" / key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" / "problem" / "receiver" / "identity" /
mechanism / "x-" name / name mechanism / name
identity = "mailfrom" ; for the "MAIL FROM" identity identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity / "helo" ; for the "HELO" identity
/ name ; other identities / name ; other identities
dot-atom = <unquoted word as per [RFC2822]> dot-atom = <unquoted word as per [RFC5322]>
quoted-string = <quoted string as per [RFC2822]> quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC2822]> comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC2822]> CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC2822]> FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC2822]> CRLF = <standard end-of-line token as per [RFC2532]>
The header field SHOULD include a "(...)" style <comment> after the The header field SHOULD include a "(...)" style comment after the
result, conveying supporting information for the result, such as result, conveying supporting information for the result, such as
<ip>, <sender>, and <domain>. <ip>, <sender>, and <domain>.
The following key-value pairs are designed for later machine parsing. The following key-value pairs are designed for later machine parsing.
SPF clients SHOULD give enough information so that the SPF results SPF verifiers SHOULD give enough information so that the SPF results
can be verified. That is, at least "client-ip", "helo", and, if the can be verified. That is, at least "client-ip", "helo", and, if the
"MAIL FROM" identity was checked, "envelope-from". "MAIL FROM" identity was checked, "envelope-from".
client-ip the IP address of the SMTP client client-ip the IP address of the SMTP client
envelope-from the envelope sender mailbox envelope-from the envelope sender mailbox
helo the host name given in the HELO or EHLO command helo the host name given in the HELO or EHLO command
mechanism the mechanism that matched (if no mechanisms matched, mechanism the mechanism that matched (if no mechanisms matched,
substitute the word "default") substitute the word "default")
problem if an error was returned, details about the error problem if an error was returned, details about the error
receiver the host name of the SPF verifier
receiver the host name of the SPF client
identity the identity that was checked; see the <identity> ABNF identity the identity that was checked; see the <identity> ABNF
rule rule
Other keys may be defined by SPF clients. Until a new key name Other keys MAY be defined by SPF verifiers.
becomes widely accepted, new key names should start with "x-".
SPF clients MUST make sure that the Received-SPF header field does SPF verifiers MUST make sure that the Received-SPF header field does
not contain invalid characters, is not excessively long, and does not not contain invalid characters, is not excessively long (See
contain malicious data that has been provided by the sender. [RFC5322] Section 2.1.1), and does not contain malicious data that
has been provided by the sender.
Examples of various header styles that could be generated are the Examples of various header field styles that could be generated are
following: the following:
Received-SPF: Pass (mybox.example.org: domain of Received-SPF: pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender) myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1; receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from=<myname@example.com>; helo=foo.example.com; envelope-from="myname@example.com"; helo=foo.example.com;
Received-SPF: Fail (mybox.example.org: domain of Received-SPF: fail (mybox.example.org: domain of
myname@example.com does not designate myname@example.com does not designate
192.0.2.1 as permitted sender) 192.0.2.1 as permitted sender)
identity=mailfrom; client-ip=192.0.2.1; identity=mailfrom; client-ip=192.0.2.1;
envelope-from=<myname@example.com>; envelope-from="myname@example.com";
7.2. SPF Results in the Authentication-Results Header Field
As mentioned in Section 7, the Authentication-Results header field is
designed to communicate lists of tests a border MTA did and their
results. The specified elements of the field provide less
information than the SPF-Received field:
Authentication-Results: myhost.example.org; spf=pass
smtp.mailfrom=example.net
Received-SPF: pass (myhost.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from="myname@example.com"; helo=foo.example.com;
It is, however, possible to add CFWS in the "reason" part of an
Authentication-Results header field and provide the equivalent
information, if desired.
As an example, an expanded Authentication-Results header field might
look like (for a "MAIL FROM" check in this example):
Authentication-Results: myhost.example.org; spf=pass
reason="client-ip=192.0.2.1; smtp.helo=foo.example.com"
smtp.mailfrom=user@example.net
8. Macros 8. Macros
8.1. Macro Definitions 8.1. Macro Definitions
Many mechanisms and modifiers perform macro expansion on part of the Many mechanisms and modifiers perform macro expansion on a term.
term.
domain-spec = macro-string domain-end domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) / toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions ; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2) ; (see [RFC3696], Section 2 for background)
alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP ) explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal ) macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-" / "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E macro-literal = %x21-24 / %x26-7E
; visible characters except "%" ; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" "c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ] transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
A literal "%" is expressed by "%%". A literal "%" is expressed by "%%".
"%_" expands to a single " " space. "%_" expands to a single " " space.
"%-" expands to a URL-encoded space, viz., "%20". "%-" expands to a URL-encoded space, viz., "%20".
The following macro letters are expanded in term arguments: The following macro letters are expanded in term arguments:
s = <sender> s = <sender>
l = local-part of <sender> l = local-part of <sender>
o = domain of <sender> o = domain of <sender>
d = <domain> d = <domain>
i = <ip> i = <ip>
p = the validated domain name of <ip> p = the validated domain name of <ip> (deprecated)
v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6 v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
h = HELO/EHLO domain h = HELO/EHLO domain
The following macro letters are allowed only in "exp" text: The following macro letters are allowed only in "exp" text:
c = SMTP client IP (easily readable format) c = SMTP client IP (easily readable format)
r = domain name of host performing the check r = domain name of host performing the check
t = current timestamp t = current timestamp
A '%' character not followed by a '{', '%', '-', or '_' character is A '%' character not followed by a '{', '%', '-', or '_' character is
skipping to change at page 28, line 13 skipping to change at page 37, line 7
h = HELO/EHLO domain h = HELO/EHLO domain
The following macro letters are allowed only in "exp" text: The following macro letters are allowed only in "exp" text:
c = SMTP client IP (easily readable format) c = SMTP client IP (easily readable format)
r = domain name of host performing the check r = domain name of host performing the check
t = current timestamp t = current timestamp
A '%' character not followed by a '{', '%', '-', or '_' character is A '%' character not followed by a '{', '%', '-', or '_' character is
a syntax error. So a syntax error. So
-exists:%(ir).sbl.spamhaus.example.org -exists:%(ir).sbl.spamhaus.example.org
is incorrect and will cause check_host() to yield a "permerror".
is incorrect and will cause check_host() to return a "PermError".
Instead, say Instead, say
-exists:%{ir}.sbl.spamhaus.example.org -exists:%{ir}.sbl.spamhaus.example.org
Optional transformers are the following: Optional transformers are the following:
*DIGIT = zero or more digits *DIGIT = zero or more digits
'r' = reverse value, splitting on dots by default 'r' = reverse value, splitting on dots by default
If transformers or delimiters are provided, the replacement value for If transformers or delimiters are provided, the replacement value for
a macro letter is split into parts. After performing any reversal a macro letter is split into parts. After performing any reversal
operation and/or removal of left-hand parts, the parts are rejoined operation and/or removal of left-hand parts, the parts are rejoined
skipping to change at page 28, line 32 skipping to change at page 37, line 23
*DIGIT = zero or more digits *DIGIT = zero or more digits
'r' = reverse value, splitting on dots by default 'r' = reverse value, splitting on dots by default
If transformers or delimiters are provided, the replacement value for If transformers or delimiters are provided, the replacement value for
a macro letter is split into parts. After performing any reversal a macro letter is split into parts. After performing any reversal
operation and/or removal of left-hand parts, the parts are rejoined operation and/or removal of left-hand parts, the parts are rejoined
using "." and not the original splitting characters. using "." and not the original splitting characters.
By default, strings are split on "." (dots). Note that no special By default, strings are split on "." (dots). Note that no special
treatment is given to leading, trailing, or consecutive delimiters, treatment is given to leading, trailing, or consecutive delimiters in
and so the list of parts may contain empty strings. Older input strings, and so the list of parts might contain empty strings.
implementations of SPF prohibit trailing dots in domain names, so Some older implementations of SPF prohibit trailing dots in domain
trailing dots should not be published by domain owners, although they names, so trailing dots SHOULD NOT be published by domain owners,
must be accepted by implementations conforming to this document. although they MUST be accepted by implementations conforming to this
Macros may specify delimiter characters that are used instead of ".". document. Macros can specify delimiter characters that are used
instead of ".".
The 'r' transformer indicates a reversal operation: if the client IP The 'r' transformer indicates a reversal operation: if the client IP
address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
and the macro %{ir} would expand to "1.2.0.192". and the macro %{ir} would expand to "1.2.0.192".
The DIGIT transformer indicates the number of right-hand parts to The DIGIT transformer indicates the number of right-hand parts to
use, after optional reversal. If a DIGIT is specified, the value use, after optional reversal. If a DIGIT is specified, the value
MUST be nonzero. If no DIGITs are specified, or if the value MUST be nonzero. If no DIGITs are specified, or if the value
specifies more parts than are available, all the available parts are specifies more parts than are available, all the available parts are
used. If the DIGIT was 5, and only 3 parts were available, the macro used. If the DIGIT was 5, and only 3 parts were available, the macro
interpreter would pretend the DIGIT was 3. Implementations MUST interpreter would pretend the DIGIT was 3. Implementations MUST
support at least a value of 128, as that is the maximum number of support at least a value of 128, as that is the maximum number of
labels in a domain name. labels in a domain name.
The "s" macro expands to the <sender> argument. It is an E-Mail The "s" macro expands to the <sender> argument. It is an email
address with a localpart, an "@" character, and a domain. The "l" address with a local-part, an "@" character, and a domain. The "l"
macro expands to just the localpart. The "o" macro expands to just macro expands to just the local-part. The "o" macro expands to just
the domain part. Note that these values remain the same during the domain part. Note that these values remain the same during
recursive and chained evaluations due to "include" and/or "redirect". recursive and chained evaluations due to "include" and/or "redirect".
Note also that if the original <sender> had no localpart, the Note also that if the original <sender> had no local-part, the local-
localpart was set to "postmaster" in initial processing (see Section part was set to "postmaster" in initial processing (see Section 4.3).
4.3).
For IPv4 addresses, both the "i" and "c" macros expand to the For IPv4 addresses, both the "i" and "c" macros expand to the
standard dotted-quad format. standard dotted-quad format.
For IPv6 addresses, the "i" macro expands to a dot-format address; it For IPv6 addresses, the "i" macro expands to a dot-format address; it
is intended for use in %{ir}. The "c" macro may expand to any of the is intended for use in %{ir}. The "c" macro can expand to any of the
hexadecimal colon-format addresses specified in [RFC3513], Section hexadecimal colon-format addresses specified in [RFC4291], Section
2.2. It is intended for humans to read. 2.2. It is intended for humans to read.
The "p" macro expands to the validated domain name of <ip>. The The "p" macro expands to the validated domain name of <ip>. The
procedure for finding the validated domain name is defined in Section procedure for finding the validated domain name is defined in
5.5. If the <domain> is present in the list of validated domains, it Section 5.5. If the <domain> is present in the list of validated
SHOULD be used. Otherwise, if a subdomain of the <domain> is domains, it SHOULD be used. Otherwise, if a subdomain of the
present, it SHOULD be used. Otherwise, any name from the list may be <domain> is present, it SHOULD be used. Otherwise, any name from the
used. If there are no validated domain names or if a DNS error list can be used. If there are no validated domain names or if a DNS
occurs, the string "unknown" is used. error occurs, the string "unknown" is used. This macro is deprecated
and SHOULD NOT be used.
The "r" macro expands to the name of the receiving MTA. This SHOULD The "r" macro expands to the name of the receiving MTA. This SHOULD
be a fully qualified domain name, but if one does not exist (as when be a fully qualified domain name, but if one does not exist (as when
the checking is done by a MUA) or if policy restrictions dictate the checking is done by a MUA) or if policy restrictions dictate
otherwise, the word "unknown" SHOULD be substituted. The domain name otherwise, the word "unknown" SHOULD be substituted. The domain name
may be different from the name found in the MX record that the client can be different from the name found in the MX record that the client
MTA used to locate the receiving MTA. MTA used to locate the receiving MTA.
The "t" macro expands to the decimal representation of the The "t" macro expands to the decimal representation of the
approximate number of seconds since the Epoch (Midnight, January 1, approximate number of seconds since the Epoch (Midnight, January 1,
1970, UTC). This is the same value as is returned by the POSIX 1970, UTC) at the time of the evaluation. This is the same value as
time() function in most standards-compliant libraries. is returned by the POSIX time() function in most standards-compliant
libraries.
When the result of macro expansion is used in a domain name query, if When the result of macro expansion is used in a domain name query, if
the expanded domain name exceeds 253 characters (the maximum length the expanded domain name exceeds 253 characters (the maximum length
of a domain name), the left side is truncated to fit, by removing of a domain name), the left side is truncated to fit, by removing
successive domain labels until the total length does not exceed 253 successive domain labels (and their following dots) until the total
characters. length does not exceed 253 characters.
Uppercased macros expand exactly as their lowercased equivalents, and Uppercased macros expand exactly as their lowercased equivalents, and
are then URL escaped. URL escaping must be performed for characters are then URL escaped. URL escaping MUST be performed for characters
not in the "uric" set, which is defined in [RFC3986]. not in the "unreserved" set, which is defined in [RFC3986].
Note: Care must be taken so that macro expansion for legitimate Note: Care has to be taken so that macro expansion for legitimate
E-Mail does not exceed the 63-character limit on DNS labels. The email does not exceed the 63-character limit on DNS labels. The
localpart of E-Mail addresses, in particular, can have more than 63 local-part of email addresses, in particular, can have more than 63
characters between dots. characters between dots.
Note: Domains should avoid using the "s", "l", "o", or "h" macros in Note: Domains SHOULD avoid using the "s", "l", "o", or "h" macros in
conjunction with any mechanism directive. Although these macros are conjunction with any mechanism directive. Although these macros are
powerful and allow per-user records to be published, they severely powerful and allow per-user records to be published, they severely
limit the ability of implementations to cache results of check_host() limit the ability of implementations to cache results of check_host()
and they reduce the effectiveness of DNS caches. and they reduce the effectiveness of DNS caches.
Implementations should be aware that if no directive processed during Note: If no directive processed during the evaluation of check_host()
the evaluation of check_host() contains an "s", "l", "o", or "h" contains an "s", "l", "o", or "h" macro, then the results of the
macro, then the results of the evaluation can be cached on the basis evaluation can be cached on the basis of <domain> and <ip> alone for
of <domain> and <ip> alone for as long as the shortest Time To Live as long as the shortest Time To Live (TTL) of all the DNS records
(TTL) of all the DNS records involved. involved.
8.2. Expansion Examples 8.2. Expansion Examples
The <sender> is strong-bad@email.example.com. The <sender> is strong-bad@email.example.com.
The IPv4 SMTP client IP is 192.0.2.3. The IPv4 SMTP client IP is 192.0.2.3.
The IPv6 SMTP client IP is 2001:DB8::CB01. The IPv6 SMTP client IP is 2001:DB8::CB01.
The PTR domain name of the client IP is mx.example.org. The PTR domain name of the client IP is mx.example.org.
macro expansion macro expansion
------- ---------------------------- ------- ----------------------------
skipping to change at page 31, line 20 skipping to change at page 40, line 4
bad.strong.lp.3.2.0.192.in-addr._spf.example.com bad.strong.lp.3.2.0.192.in-addr._spf.example.com
%{ir}.%{v}.%{l1r-}.lp._spf.%{d2} %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
3.2.0.192.in-addr.strong.lp._spf.example.com 3.2.0.192.in-addr.strong.lp._spf.example.com
%{d2}.trusted-domains.example.net %{d2}.trusted-domains.example.net
example.com.trusted-domains.example.net example.com.trusted-domains.example.net
IPv6: IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0. %{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
9. Implications 9. Implications
This section outlines the major implications that adoption of this This section outlines the major implications that adoption of this
document will have on various entities involved in Internet E-Mail. document will have on various entities involved in Internet email.
It is intended to make clear to the reader where this document It is intended to make clear to the reader where this document
knowingly affects the operation of such entities. This section is knowingly affects the operation of such entities. This section is
not a "how-to" manual, or a "best practices" document, and it is not not a "how-to" manual, or a "best practices" document, and it is not
a comprehensive list of what such entities should do in light of this a comprehensive list of what such entities SHOULD do in light of this
document. document.
This section is non-normative. This section is non-normative. [RFC5598] describes the Internet
email architecture. This section is organized based on the different
segments of the architecture.
9.1. Sending Domains 9.1. Sending Domains
Domains that wish to be compliant with this specification will need Originating ADMDs (ADministrative Management Domains - [RFC5598]
to determine the list of hosts that they allow to use their domain Section 2.2.1 and Section 2.3) that wish to be compliant with this
name in the "HELO" and "MAIL FROM" identities. It is recognized that specification will need to determine the list of relays ([RFC5598]
forming such a list is not just a simple technical exercise, but Section 2.2.2) that they allow to use their domain name in the "HELO"
involves policy decisions with both technical and administrative and "MAIL FROM" identities when relaying to other ADMDs. It is
considerations. recognized that forming such a list is not just a simple technical
exercise, but involves policy decisions with both technical and
administrative considerations.
It can be helpful to publish records that include a "tracking 9.1.1. DNS Resource Considerations
Minimizing the DNS resources required for SPF lookups can be done by
choosing directives that require less DNS information and by placing
lower-cost mechanisms earlier in the SPF record.
+----------+--------+-----------------+
| term | cost | limit |
+----------+--------+-----------------+
| ip4/ip6 | 0 | - |
| a | 1 | 10 |
| include | 1 | 10 |
| redirect | 1 | 10 |
| exists | 1 | 10 |
| mx | 1 + N* | 10 and N* <= 10 |
| ptr/%{p} | 1 + N* | 10 and N* <= 10 |
| all | 0 | - |
+----------+--------+-----------------+
* N is the number of RRs found during each term evaluation
Section 4.6.4 specifies the limits receivers have to use. It is
essential to publish records that do not exceed these requirements.
It is also required to carefully weight the cost and the
maintainability of licit solutions.
For example, consider a domain set up as follows:
example.com. IN MX 10 mx.example.com.
IN MX 20 mx2.example.com.
mx.example.com. IN A 192.0.2.1
mx2.example.com. IN A 192.0.2.129
Assume the administrative point is to authorize (pass) mx and mx2
while failing every other host. Compare the following solutions:
Best record:
example.com. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"
Good record:
$ORIGIN example.com.
@ IN TXT "v=spf1 a:authorized-spf.example.com -all"
authorized-spf IN A 192.0.2.1
IN A 192.0.2.129
Expensive record:
example.com. IN TXT "v=spf1 mx:example.com -all"
Wasteful, bad record:
example.com. IN TXT "v=spf1 ip4:192.0.2.0/24 mx -all"
9.1.2. Administrator's Considerations
There might be administrative considerations: using "a" over "ip4" or
"ip6" allows hosts to be renumbered easily. Using "mx" over "a"
allows the set of mail hosts to be changed easily. Unless such
changes are common, it is better to use the less resource intensive
mechanisms like "ip4" and "ip6" over "a" or "a" or "mx".
In some specific cases, standard advice on record content is
appropriate. Publishing SPF records for domains that send no mail is
a well established best practice. The record for a domain that sends
no mail is:
www.example.com. IN TXT "v=spf1 -all"
Publishing SPF records for individual hosts is also best practice.
The hostname is generally the identity used in the 5321.HELO/.EHLO
command. In the case of messages with a null 5321.MailFrom, this is
used as the domain for 5321.MailFrom SPF checks, in addition to being
used in 5321.HELO/.EHLO based SPF checks. The standard SPF record
for an individual host that is involved in mail processing is:
relay.example.com. IN TXT "v=spf1 a -all"
Validating correct deployment is difficult. [RFC6652] describes one
mechanism for soliciting feedback on SPF failures. Another approach
that can be helpful to publish records that include a "tracking
exists:" mechanism. By looking at the name server logs, a rough list exists:" mechanism. By looking at the name server logs, a rough list
may then be generated. For example: can then be generated. For example:
v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
9.2. Mailing Lists Regardless of the method used, understanding the ADMD's outbound mail
architecture is essential to effective deployment.
Mailing lists must be aware of how they re-inject mail that is sent 9.1.3. Bounces
to the list. Mailing lists MUST comply with the requirements in
[RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that As explained in Section 1.3.3, [RFC5321] allows the reverse-path to
be null, which is typical of some Delivery Status Notification
[RFC3464], commonly called email bounces. In this case the only
entity available for performing an SPF check is the "HELO" identity
defined in Section 1.3.4. SPF functionality is enhanced by
administrators ensuring this identity is set correctly and has an
appropriate SPF record. It is normal to have the HELO identity set
to hostname instead of domain. Zone file generation for significant
numbers of hosts can be consolidated using the redirect modifier and
scripted for initial deployment. Specific deployment advice is given
above in Section 9.1.2.
9.2. Mediators
Broadly speaking, there are two types of mediating ADMDs that can
affect SPF deployment of other ADMDs: mailing lists (see [RFC5598]
Section 5.3) and ReSenders ([RFC5598] Section 5.2).
9.2.1. Mailing Lists
Mailing lists have to be aware of how they re-inject mail that is
sent to the list. Mailing lists MUST comply with the requirements in
[RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that
the reverse-path MUST be changed to be the mailbox of a person or the reverse-path MUST be changed to be the mailbox of a person or
other entity who administers the list. Whereas the reasons for other entity who administers the list. Whereas the reasons for
changing the reverse-path are many and long-standing, SPF adds changing the reverse-path are many and long-standing, SPF adds
enforcement to this requirement. enforcement to this requirement.
In practice, almost all mailing list software in use already complies In practice, almost all mailing list software in use already complies
with this requirement. Mailing lists that do not comply may or may with this requirement. Mailing lists that do not comply might
not encounter problems depending on how access to the list is encounter problems depending on how access to the list is restricted.
restricted. Such lists that are entirely internal to a domain (only Such lists that are entirely internal to a domain (only people in the
people in the domain can send to or receive from the list) are not domain can send to or receive from the list) are not affected.
affected.
9.3. Forwarding Services and Aliases 9.2.2. Forwarding Services and Aliases
Forwarding services take mail that is received at a mailbox and Forwarding services take mail that is received at a mailbox and
direct it to some external mailbox. At the time of this writing, the direct it to some external mailbox. At the time of this writing, the
near-universal practice of such services is to use the original "MAIL near-universal practice of such services is to use the original "MAIL
FROM" of a message when re-injecting it for delivery to the external FROM" of a message when re-injecting it for delivery to the external
mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" mailbox. [RFC1123] and [RFC5321] describe this action as an "alias"
rather than a "mail list". This means that the external mailbox's rather than a "mail list". This means the external mailbox's MTA
MTA sees all such mail in a connection from a host of the forwarding sees all such mail in a connection from a host of the forwarding
service, and so the "MAIL FROM" identity will not, in general, pass service, and so the "MAIL FROM" identity will not, in general, pass
authorization. authorization.
There are three places that techniques can be used to ameliorate this There are three places that techniques can be used to ameliorate this
problem. problem.
1. The beginning, when E-Mail is first sent. 1. The beginning, when email is first sent (Originating ADMDs).
1. "Neutral" results could be given for IP addresses that may be 1. "Neutral" results could be given for IP addresses that might
forwarders, instead of "Fail" results. For example: be forwarders, instead of "fail" results based on a list of
known reliable forwarders. For example:
"v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all" "v=spf1 mx ?exists:%{ir}.whitlist.example.org -all"
This would cause a lookup on an anti-spam DNS blacklist This would cause a lookup on an DNS white list (DNSWL) and
(DNSBL) and cause a result of "Fail" only for E-Mail coming cause a result of "fail" only for email not either coming
from listed sources. All other E-Mail, including E-Mail sent from the domain's mx host(s) (SPF pass) or white listed
through forwarders, would receive a "Neutral" result. By sources (SPF neutral). This, in effect, outsources an
checking the DNSBL after the known good sources, problems with element of sender policy to the maintainer of the whitelist.
incorrect listing on the DNSBL are greatly reduced.
2. The "MAIL FROM" identity could have additional information in 2. The "MAIL FROM" identity could have additional information in
the localpart that cryptographically identifies the mail as the local-part that cryptographically identifies the mail as
coming from an authorized source. In this case, such an SPF coming from an authorized source. In this case, such an SPF
record could be used: record could be used:
"v=spf1 mx exists:%{l}._spf_verify.%{d} -all" "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
Then, a specialized DNS server can be set up to serve the Then, a specialized DNS server can be set up to serve the
_spf_verify subdomain that validates the localpart. Although _spf_verify subdomain that validates the local-part.
this requires an extra DNS lookup, this happens only when the Although this requires an extra DNS lookup, this happens only
E-Mail would otherwise be rejected as not coming from a known when the email would otherwise be rejected as not coming from
good source. a known good source.
Note that due to the 63-character limit for domain labels,
this approach only works reliably if the local-part signature
scheme is guaranteed either to only produce local-parts with
a maximum of 63 characters or to gracefully handle truncated
local-parts.
Note that due to the 63-character limit for domain labels, 3. Similarly, a specialized DNS server could be set up that will
this approach only works reliably if the localpart signature rate-limit the email coming from unexpected IP addresses.
scheme is guaranteed either to only produce localparts with a
maximum of 63 characters or to gracefully handle truncated
localparts.
3. Similarly, a specialized DNS server could be set up that will "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
rate-limit the E-Mail coming from unexpected IP addresses.
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all" 4. SPF allows the creation of per-user policies for special
cases. For example, the following SPF record and appropriate
wildcard DNS records can be used:
4. SPF allows the creation of per-user policies for special "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
cases. For example, the following SPF record and appropriate
wildcard DNS records can be used:
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}" 2. The middle, when email is forwarded (Mediating ADMDs).
2. The middle, when E-Mail is forwarded. 1. Forwarding services can solve the problem by rewriting the
"MAIL FROM" to be in their own domain. This means mail
rejected from the external mailbox will have to be forwarded
back to the original sender by the forwarding service.
Various schemes to do this exist though they vary widely in
complexity and resource requirements on the part of the
forwarding service.
1. Forwarding services can solve the problem by rewriting the 2. Several popular MTAs can be forced from "alias" semantics to
"MAIL FROM" to be in their own domain. This means that mail "mailing list" semantics by configuring an additional alias
bounced from the external mailbox will have to be re-bounced with "owner-" prepended to the original alias name (e.g., an
by the forwarding service. Various schemes to do this exist alias of "friends: george@example.com, fred@example.org"
though they vary widely in complexity and resource would need another alias of the form "owner-friends:
requirements on the part of the forwarding service. localowner").
2. Several popular MTAs can be forced from "alias" semantics to 3. Forwarding servers could reject mail that would "fail" SPF if
"mailing list" semantics by configuring an additional alias forwarded using an SMTP reply code of 551, User not local,
with "owner-" prepended to the original alias name (e.g., an (see [RFC5321] section 3.4) to communicate the correct target
alias of "friends: george@example.com, fred@example.org" would address to resend the mail to.
need another alias of the form "owner-friends: localowner").
3. The end, when E-Mail is received. 3. The end, when email is received (Receiving ADMDs).
1. If the owner of the external mailbox wishes to trust the 1. If the owner of the external mailbox wishes to trust the
forwarding service, he can direct the external mailbox's MTA forwarding service, he can direct the external mailbox's MTA
to skip SPF tests when the client host belongs to the to skip SPF tests when the client host belongs to the
forwarding service. forwarding service.
2. Tests against other identities, such as the "HELO" identity, 2. Tests against other identities, such as the "HELO" identity,
may be used to override a failed test against the "MAIL FROM" MAY be used to override a failed test against the "MAIL FROM"
identity. identity.
3. For larger domains, it may not be possible to have a complete 3. For larger domains, it might not be possible to have a
or accurate list of forwarding services used by the owners of complete or accurate list of forwarding services used by the
the domain's mailboxes. In such cases, whitelists of owners of the domain's mailboxes. In such cases, whitelists
generally-recognized forwarding services could be employed. of generally-recognized forwarding services could be
employed.
9.4. Mail Services 9.2.3. Mail Services
Service providers that offer mail services to third-party domains, MSPs (Mail Service Providers - [RFC5598] Section 2.3) that offer mail
such as sending of bulk mail, may want to adjust their setup in light services to third-party domains, such as sending of bulk mail, might
of the authorization check described in this document. If the "MAIL want to adjust their configurations in light of the authorization
FROM" identity used for such E-Mail uses the domain of the service check described in this document. If the domain part of the "MAIL
provider, then the provider needs only to ensure that its sending FROM" identity used for such email uses the domain of one of the MSPs
host is authorized by its own SPF record, if any. domain, then the provider needs only to ensure that its sending host
is authorized by its own SPF record, if any.
If the "MAIL FROM" identity does not use the mail service provider's If the "MAIL FROM" identity does not use the MSP's domain, then extra
domain, then extra care must be taken. The SPF record format has care has to be taken. The SPF record format has several options for
several options for the third-party domain to authorize the service the third-party domain to authorize the service provider's MTAs to
provider's MTAs to send mail on its behalf. For mail service send mail on its behalf. For MSPs, such as ISPs, that have a wide
providers, such as ISPs, that have a wide variety of customers using variety of customers using the same MTA, steps are required to
the same MTA, steps should be taken to prevent cross-customer forgery mitiate the risk of cross-customer forgery (see Section 10.4).
(see Section 10.4).
9.5. MTA Relays 9.2.4. MTA Relays
The authorization check generally precludes the use of arbitrary MTA Relays are described in [RFC5598] Section 2.2.2. The authorization
relays between sender and receiver of an E-Mail message. check generally precludes the use of arbitrary MTA relays between
sender and receiver of an email message.
Within an organization, MTA relays can be effectively deployed. Within an organization, MTA relays can be effectively deployed.
However, for purposes of this document, such relays are effectively However, for purposes of this document, such relays are effectively
transparent. The SPF authorization check is a check between border transparent. The SPF authorization check is a check between border
MTAs of different domains. MTAs of different ADMDs.
For mail senders, this means that published SPF records must For mail senders, this means that published SPF records have to
authorize any MTAs that actually send across the Internet. Usually, authorize any MTAs that actually send across the Internet. Usually,
these are just the border MTAs as internal MTAs simply forward mail these are just the border MTAs as internal MTAs simply forward mail
to these MTAs for delivery. to these MTAs for relaying.
Mail receivers will generally want to perform the authorization check The receiving ADMD will generally want to perform the authorization
at the border MTAs, specifically including all secondary MXs. This check at the boundary MTAs, including all secondary MXs. Internal
allows mail that fails to be rejected during the SMTP session rather MTAs (including MTAs that might serve both as boundary MTAs and
than bounced. Internal MTAs then do not perform the authorization internal relays from secondary MXs when they are processing the
test. To perform the authorization test other than at the border, relayed mail stream) then do not perform the authorization test. To
the host that first transferred the message to the organization must perform the authorization test other than at the boundary, the host
be determined, which can be difficult to extract from the message that first transferred the message to the receiving ADMD have to be
header. Testing other than at the border is not recommended. determined, which can be difficult to extract from the message header
because (a) header fields can be forged or malformed, and (b) there's
no standard way to encode that information such that it can be
reliably extracted. Testing other than at the boundary is likely to
produce unreliable results.
9.3. Receivers
SPF results can be used in combination with other methods to
determine the final local disposition (either positive or negative of
a message. It can also be considered dispositive on its own.
9.3.1. Policy For SPF Pass
SPF pass results can be used in combination with "white lists" of
known "good" domains to bypass some or all additional pre-delivery
email checks. Exactly which checks and how to determine appropriate
white list entries has to be based on local conditions and
requirements.
9.3.2. Policy For SPF Fail
SPF fail results can be used to reject messages during the SMTP
transaction based on either "MAIL FROM" or "HELO" identity results.
This reduces resource requirements for various content filtering
methods and conserves bandwidth since rejection can be done before
the SMTP content is transferred. It also gives immediate feedback to
the sender who might then be able to resolve the issue. Due to some
of the issues described above in this section (Section 9), SPF based
rejection does present some risk of rejecting legitimate email when
rejecting based on "MAIL FROM" results.
SPF fail results can alternately be used as one input into a larger
set of evaluations which might, based on a combination with other
evaluation techniques, result in the email being marked negatively in
some way (this might be via delivery to a special spam folder,
modifying subject lines, or other locally determined means).
Developing the details of such an approach have to be based on local
conditions and requirements. Using SPF results in this way does not
have the advantages of resource conservation and immediate feedback
to the sender associated with SMTP rejection, but could produce fewer
undesirable rejections in a well designed system. Such an approach
might result in email that was not authorized by the sending ADMD
being unknowingly delivered to end users.
Either general approach can be used as they both leave a clear
disposition of emails. They are either delivered in some manner or
the sender is notified of the failure. Other dispositions such as
"dropping" or deleting email after acceptance are inappropriate
because they leave uncertainty and reduce the overall reliabilility
and utility of email across the Internet.
9.3.3. Policy For SPF Permerror
The "permerror" result (see Section 2.5.7) indicates the SPF
processing module at the receiver determined that the retrieved SPF
policy record could not be interpreted. This gives no true
indication about the authorized use of the data found in the
envelope.
As with all results, implementers have a choice to make regarding
what to do with a message that yields this result. SMTP allows only
a few basic options.
Rejection of the message is an option, in that it is the one thing a
receiver can do to draw attention to the difficulty encountered while
protecting itself from messages that do not have a definite SPF
result of some kind. However, if the SPF implementation is defective
and returns spurious "permerror" results, only the sender is actively
notified of the defect (in the form of rejected mail), and not the
receiver making use of SPF.
The less intrusive handling choice is to deliver the message, perhaps
with some kind of annotation of the difficulty encountered and/or
logging of a similar nature. However, this will not be desirable to
operators that wish to implement SPF checking as strictly as
possible, nor is this sort of passive problem reporting typically
effective.
There is of course the option placing this choice in the hands of the
operator rather than the implementer since this kind of choice is
often a matter of local policy rather than a condition with a
universal solution, but this adds one more piece of complexity to an
already non-trivial environment.
Both implementers and operators need to be cautious of all choices
and outcomes when handling SPF results.
10. Security Considerations 10. Security Considerations
10.1. Processing Limits 10.1. Processing Limits
As with most aspects of E-Mail, there are a number of ways that As with most aspects of email, there are a number of ways that
malicious parties could use the protocol as an avenue for a malicious parties could use the protocol as an avenue for a
Denial-of-Service (DoS) attack. The processing limits outlined here Denial-of-Service (DoS) attack. The processing limits outlined in
are designed to prevent attacks such as the following: Section 4.6.4 are designed to prevent attacks such as the following:
o A malicious party could create an SPF record with many references o A malicious party could create an SPF record with many references
to a victim's domain and send many E-Mails to different SPF to a victim's domain and send many emails to different SPF
clients; those SPF clients would then create a DoS attack. In verifiers; those SPF verifiers would then create a DoS attack. In
effect, the SPF clients are being used to amplify the attacker's effect, the SPF verifiers are being used to amplify the attacker's
bandwidth by using fewer bytes in the SMTP session than are used bandwidth by using fewer bytes in the SMTP session than are used
by the DNS queries. Using SPF clients also allows the attacker to by the DNS queries. Using SPF clients also allows the attacker to
hide the true source of the attack. hide the true source of the attack.
o Whereas implementations of check_host() are supposed to limit the o Whereas implementations of check_host() are supposed to limit the
number of DNS lookups, malicious domains could publish records number of DNS lookups, malicious domains could publish records
that exceed these limits in an attempt to waste computation effort that exceed these limits in an attempt to waste computation effort
at their targets when they send them mail. Malicious domains at their targets when they send them mail. Malicious domains
could also design SPF records that cause particular could also design SPF records that cause particular
implementations to use excessive memory or CPU usage, or to implementations to use excessive memory or CPU usage, or to
trigger bugs. trigger bugs.
o Malicious parties could send a large volume of mail purporting to o Malicious parties could send a large volume of mail purporting to
come from the intended target to a wide variety of legitimate mail come from the intended target to a wide variety of legitimate mail
hosts. These legitimate machines would then present a DNS load on hosts. These legitimate machines would then present a DNS load on
the target as they fetched the relevant records. the target as they fetched the relevant records.
Of these, the case of a third party referenced in the SPF record is Of these, the case of a third party referenced in the SPF record is
the easiest for a DoS attack to effectively exploit. As a result, the easiest for a DoS attack to effectively exploit. As a result,
limits that may seem reasonable for an individual mail server can limits that might seem reasonable for an individual mail server can
still allow an unreasonable amount of bandwidth amplification. still allow an unreasonable amount of bandwidth amplification.
Therefore, the processing limits need to be quite low. Therefore, the processing limits need to be quite low.
SPF implementations MUST limit the number of mechanisms and modifiers 10.2. SPF-Authorized Email May Contain Other False Identities
that do DNS lookups to at most 10 per SPF check, including any
lookups caused by the use of the "include" mechanism or the
"redirect" modifier. If this number is exceeded during a check, a
PermError MUST be returned. The "include", "a", "mx", "ptr", and
"exists" mechanisms as well as the "redirect" modifier do count
against this limit. The "all", "ip4", and "ip6" mechanisms do not
require DNS lookups and therefore do not count against this limit.
The "exp" modifier does not count against this limit because the DNS
lookup to fetch the explanation string occurs after the SPF record
has been evaluated.
When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
there MUST be a limit of no more than 10 MX or PTR RRs looked up and
checked.
SPF implementations SHOULD limit the total amount of data obtained
from the DNS queries. For example, when DNS over TCP or EDNS0 are
available, there may need to be an explicit limit to how much data
will be accepted to prevent excessive bandwidth usage or memory usage
and DoS attacks.
MTAs or other processors MAY also impose a limit on the maximum
amount of elapsed time to evaluate check_host(). Such a limit SHOULD
allow at least 20 seconds. If such a limit is exceeded, the result
of authorization SHOULD be "TempError".
Domains publishing records SHOULD try to keep the number of "include"
mechanisms and chained "redirect" modifiers to a minimum. Domains
SHOULD also try to minimize the amount of other DNS information
needed to evaluate a record. This can be done by choosing directives
that require less DNS information and placing lower-cost mechanisms
earlier in the SPF record.
For example, consider a domain set up as follows:
example.com. IN MX 10 mx.example.com.
mx.example.com. IN A 192.0.2.1
a.example.com. IN TXT "v=spf1 mx:example.com -all"
b.example.com. IN TXT "v=spf1 a:mx.example.com -all"
c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
Evaluating check_host() for the domain "a.example.com" requires the
MX records for "example.com", and then the A records for the listed
hosts. Evaluating for "b.example.com" requires only the A records.
Evaluating for "c.example.com" requires none.
However, there may be administrative considerations: using "a" over
"ip4" allows hosts to be renumbered easily. Using "mx" over "a"
allows the set of mail hosts to be changed easily.
10.2. SPF-Authorized E-Mail May Contain Other False Identities
The "MAIL FROM" and "HELO" identity authorizations must not be Do not construe the "MAIL FROM" and "HELO" identity authorizations to
construed to provide more assurance than they do. It is entirely provide more assurance than they do. It is entirely possible for a
possible for a malicious sender to inject a message using his own malicious sender to inject a message using his own domain in the
domain in the identities used by SPF, to have that domain's SPF identities used by SPF, to have that domain's SPF record authorize
record authorize the sending host, and yet the message can easily the sending host, and yet the message can easily list other
list other identities in its header. Unless the user or the MUA identities in its header. Unless the user or the MUA takes care to
takes care to note that the authorized identity does not match the note that the authorized identity does not match the other more
other more commonly-presented identities (such as the From: header commonly-presented identities (such as the From: header field), the
field), the user may be lulled into a false sense of security. user might be lulled into a false sense of security.
10.3. Spoofed DNS and IP Data 10.3. Spoofed DNS and IP Data
There are two aspects of this protocol that malicious parties could There are two aspects of this protocol that malicious parties could
exploit to undermine the validity of the check_host() function: exploit to undermine the validity of the check_host() function:
o The evaluation of check_host() relies heavily on DNS. A malicious o The evaluation of check_host() relies heavily on DNS. A malicious
attacker could attack the DNS infrastructure and cause attacker could attack the DNS infrastructure and cause
check_host() to see spoofed DNS data, and then return incorrect check_host() to see spoofed DNS data, and then return incorrect
results. This could include returning "Pass" for an <ip> value results. This could include returning "pass" for an <ip> value
where the actual domain's record would evaluate to "Fail". See where the actual domain's record would evaluate to "fail". See
[RFC3833] for a description of DNS weaknesses. [RFC3833] for a description of DNS weaknesses.
o The client IP address, <ip>, is assumed to be correct. A o The client IP address, <ip>, is assumed to be correct. In a
malicious attacker could spoof TCP sequence numbers to make mail modern, correctly configured system the risk of this not being
appear to come from a permitted host for a domain that the true is nil.
attacker is impersonating.
10.4. Cross-User Forgery 10.4. Cross-User Forgery
By definition, SPF policies just map domain names to sets of By definition, SPF policies just map domain names to sets of
authorized MTAs, not whole E-Mail addresses to sets of authorized authorized MTAs, not whole email addresses to sets of authorized
users. Although the "l" macro (Section 8) provides a limited way to users. Although the "l" macro (Section 8) provides a limited way to
define individual sets of authorized MTAs for specific E-Mail define individual sets of authorized MTAs for specific email
addresses, it is generally impossible to verify, through SPF, the use addresses, it is generally impossible to verify, through SPF, the use
of specific E-Mail addresses by individual users of the same MTA. of specific email addresses by individual users of the same MTA.
It is up to mail services and their MTAs to directly prevent It is up to mail services and their MTAs to directly prevent
cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be cross-user forgery: based on SMTP AUTH ([RFC4954]), users have to be
restricted to using only those E-Mail addresses that are actually restricted to using only those email addresses that are actually
under their control (see [RFC4409], Section 6.1). Another means to under their control (see [RFC6409], Section 6.1). Another means to
verify the identity of individual users is message cryptography such verify the identity of individual users is message cryptography such
as PGP ([RFC2440]) or S/MIME ([RFC3851]). as PGP ([RFC4880]) or S/MIME ([RFC5751]).
10.5. Untrusted Information Sources 10.5. Untrusted Information Sources
SPF uses information supplied by third parties, such as the "HELO" An SPF compliant receiver gathers information from the SMTP commands
domain name, the "MAIL FROM" address, and SPF records. This it receives and from the published DNS records of the sending domain
information is then passed to the receiver in the Received-SPF: trace holder, (e.g., "HELO" domain name, the "MAIL FROM" address from the
fields and possibly returned to the client MTA in the form of an SMTP envelope, and SPF DNS records published by the domain holder).
rejection message. This information must be checked for invalid
characters and excessively long lines.
When the authorization check fails, an explanation string may be 10.5.1. Recorded Results
This information, passed to the receiver in the Received-SPF: or
Authentication-Results: trace fields, may be returned to the client
MTA as an SMTP rejection message. If such an SMTP rejection message
is generated, the information from the trace fields has to be checked
for such problems as invalid characters and excessively long lines.
10.5.2. External Explanations
When the authorization check fails, an explanation string could be
included in the reject response. Both the sender and the rejecting included in the reject response. Both the sender and the rejecting
receiver need to be aware that the explanation was determined by the receiver need to be aware that the explanation was determined by the
publisher of the SPF record checked and, in general, not the publisher of the SPF record checked and, in general, not the
receiver. The explanation may contain malicious URLs, or it may be receiver. The explanation can contain malicious URLs, or it might be
offensive or misleading. offensive or misleading.
This is probably less of a concern than it may initially seem since Explanations returned to sender domains due to "exp" modifiers,
such messages are returned to the sender, and the explanation strings (Section 6.2), were generated by the sender policy published by the
come from the sender policy published by the domain in the identity domain holders themselves. As long as messages are only returned
claimed by that very sender. As long as the DSN is not redirected to with non-delivery notification ([RFC3464]) to domains publishing the
someone other than the actual sender, the only people who see explanation strings from their own DNS SPF records, the only affected
malicious explanation strings are people whose messages claim to be parties are the original publishers of the domain's SPF records.
from domains that publish such strings in their SPF records. In
practice, DSNs can be misdirected, such as when an MTA accepts an In practice, such non-delivery notifications can be misdirected, such
E-Mail and then later generates a DSN to a forged address, or when an as when an MTA accepts an email and only later generates the
E-Mail forwarder does not direct the DSN back to the original sender. notification to a forged address, or when an email forwarder does not
direct the bounce back to the original sender.
10.5.3. Macro Expansion
Macros (Section 8) allow senders to inject arbitrary text (any non-
null [US-ASCII] character) into receiver DNS queries. It is necesary
to be prepared for hostile or unexpected content.
10.6. Privacy Exposure 10.6. Privacy Exposure
Checking SPF records causes DNS queries to be sent to the domain Checking SPF records causes DNS queries to be sent to the domain
owner. These DNS queries, especially if they are caused by the owner. These DNS queries, especially if they are caused by the
"exists" mechanism, can contain information about who is sending "exists" mechanism, can contain information about who is sending
E-Mail and likely to which MTA the E-Mail is being sent. This can email and likely to which MTA the email is being sent. This can
introduce some privacy concerns, which may be more or less of an introduce some privacy concerns, which are more or less of an issue
issue depending on local laws and the relationship between the domain depending on local laws and the relationship between the domain owner
owner and the person sending the E-Mail. and the person sending the email.
11. Contributors and Acknowledgements 11. Contributors and Acknowledgements
This document is largely based on the work of Meng Weng Wong and Mark This document is largely based on the work of Meng Weng Wong, Mark
Lentczner. Although, as this section acknowledges, many people have Lentczner, and Wayne Schlitt. Although, as this section
contributed to this document, a very large portion of the writing and acknowledges, many people have contributed to this document, a very
editing are due to Meng and Mark. large portion of the writing and editing are due to Meng, Mark, and
Wayne.
This design owes a debt of parentage to [RMX] by Hadmut Danisch and This design owes a debt of parentage to [RMX] by Hadmut Danisch and
to [DMP] by Gordon Fecyk. The idea of using a DNS record to check to [DMP] by Gordon Fecyk. The idea of using a DNS record to check
the legitimacy of an E-Mail address traces its ancestry further back the legitimacy of an email address traces its ancestry further back
through messages on the namedroppers mailing list by Paul Vixie through messages on the namedroppers mailing list by Paul Vixie
[Vixie] (based on suggestion by Jim Miller) and by David Green [Vixie] (based on suggestion by Jim Miller) and by David Green
[Green]. [Green].
Philip Gladstone contributed the concept of macros to the Philip Gladstone contributed the concept of macros to the
specification, multiplying the expressiveness of the language and specification, multiplying the expressiveness of the language and
making per-user and per-IP lookups possible. making per-user and per-IP lookups possible.
The authors would also like to thank the literally hundreds of The authors of both this document and [RFC4408] would also like to
individuals who have participated in the development of this design. thank the literally hundreds of individuals who have participated in
They are far too numerous to name, but they include the following: the development of this design. They are far too numerous to name,
but they include the following:
The participants in the SPFbis working group.
The folks on the spf-discuss mailing list. The folks on the spf-discuss mailing list.
The folks on the SPAM-L mailing list. The folks on the SPAM-L mailing list.
The folks on the IRTF ASRG mailing list. The folks on the IRTF ASRG mailing list.
The folks on the IETF MARID mailing list. The folks on the IETF MARID mailing list.
The folks on #perl. The folks on #perl.
12. IANA Considerations 12. IANA Considerations
12.1. The SPF DNS Record Type 12.1. The SPF DNS Record Type
The IANA has assigned a new Resource Record Type and Qtype from the Per [RFC4408], the IANA assigned the Resource Record Type and Qtype
DNS Parameters Registry for the SPF RR type with code 99. from the DNS Parameters Registry for the SPF RR type with code 99.
The format of this type is identical to the TXT RR [RFC1035]. The
character content of the record is encoded as [US-ASCII]. Use of
this record type is obsolete for SPF Version 1.
IANA is requested to add an annotation to the SPF RRTYPE saying
"(OBSOLETE - use TXT)" in the DNS Parameters registry.
[NOTE TO RFC EDITOR: (to be changed to " ... has added ..." upon
publication)]
12.2. The Received-SPF Mail Header Field 12.2. The Received-SPF Mail Header Field
Per [RFC3864], the "Received-SPF:" header field is added to the IANA Per [RFC3864], the "Received-SPF:" header field is added to the IANA
Permanent Message Header Field Registry. The following is the Permanent Message Header Field Registry. The following is the
registration template: registration template:
Header field name: Received-SPF Header field name: Received-SPF
Applicable protocol: mail ([RFC2822]) Applicable protocol: mail ([RFC5322])
Status: Experimental Status: Standards Track
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): RFC 4408 Specification document(s): RFC XXXX
Related information: [NOTE TO RFC EDITOR: (this document)]
Requesting SPF Council review of any proposed changes and
additions to this field are recommended. For information about 12.3. SPF Modifier Registration
the SPF Council see http://www.openspf.org/Council
[RFC6652] created a new SPF Modifier Registration. IANA is requested
to change the reference for the exp and redirect modifiers from
[RFC4408] to this document. Their status should not be changed.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
April 2001. RFC 3463, January 2003.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January
2003.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, January 2005. RFC 3986, January 2005.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Specifications: ABNF", RFC 4234, October 2005. Architecture", RFC 4291, February 2006.
[US-ASCII] American National Standards Institute (formerly United [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5451] Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", RFC 5451, April 2009.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[US-ASCII]
American National Standards Institute (formerly United
States of America Standards Institute), "USA Code for States of America Standards Institute), "USA Code for
Information Interchange, X3.4", 1968. Information Interchange, X3.4", 1968.
ANSI X3.4-1968 has been replaced by newer versions with slight ANSI X3.4-1968 has been replaced by newer versions with
modifications, but the 1968 version remains definitive for slight modifications, but the 1968 version remains
the Internet. definitive for the Internet.
13.2 Informative References 13.2. Informative References
[DMP] Fecyk, G., "Designated Mailers Protocol".
Work In Progress
[Green] Green, D., "Domain-Authorized SMTP Mail", 2002.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August [RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983,
1996. August 1996.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
"OpenPGP Message Format", RFC 2440, November 1998. NCACHE)", RFC 2308, March 1998.
[RFC2554] Myers, J., "SMTP Service Extension for Authentication", [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
RFC 2554, March 1999. specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
January 2003.
[RFC3696] Klensin, J., "Application Techniques for Checking and [RFC3696] Klensin, J., "Application Techniques for Checking and
Transformation of Names", RFC 3696, February 2004. Transformation of Names", RFC 3696, February 2004.
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain
Name System (DNS)", RFC 3833, August 2004. Name System (DNS)", RFC 3833, August 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3834] Moore, K., "Recommendations for Automatic Responses to
Extensions (S/MIME) Version 3.1 Message Specification", Electronic Mail", RFC 3834, August 2004.
RFC 3851, July 2004.
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
RFC 4409, April 2006. for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RMX] Danish, H., "The RMX DNS RR Type for light weight sender [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
authentication", Work In Progress (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
[Vixie] Vixie, P., "Repudiating MAIL FROM", 2002. [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension
for Authentication", RFC 4954, July 2007.
[Green] Green, D., "Domain-Authorized SMTP Mail", 2002. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
February 2010.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, November 2011.
[RFC6647] Kucherawy, M. and D. Crocker, "Email Greylisting: An
Applicability Statement for SMTP", RFC 6647, June 2012.
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF)
Authentication Failure Reporting Using the Abuse Reporting
Format", RFC 6652, June 2012.
[RFC6686] Kucherawy, M., "Resolution of the Sender Policy Framework
(SPF) and Sender ID Experiments", RFC 6686, July 2012.
[RMX] Danisch, H., "The RMX DNS RR Type for light weight sender
authentication".
Work In Progress
[Vixie] Vixie, P., "Repudiating MAIL FROM", 2002.
Appendix A. Collected ABNF Appendix A. Collected ABNF
This section is normative and any discrepancies with the ABNF This section is normative and any discrepancies with the ABNF
fragments in the preceding text are to be resolved in favor of this fragments in the preceding text are to be resolved in favor of this
grammar. grammar.
See [RFC4234] for ABNF notation. Please note that as per this ABNF See [RFC5234] for ABNF notation. Please note that as per this ABNF
definition, literal text strings (those in quotes) are case- definition, literal text strings (those in quotes) are case-
insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx". insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
record = version terms *SP record = version terms *SP
version = "v=spf1" version = "v=spf1"
terms = *( 1*SP ( directive / modifier ) ) terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~" qualifier = "+" / "-" / "?" / "~"
skipping to change at page 42, line 38 skipping to change at page 57, line 38
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ] MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
PTR = "ptr" [ ":" domain-spec ] PTR = "ptr" [ ":" domain-spec ]
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ] IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ] IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string unknown-modifier = name "=" macro-string
; where name is not any known modifier
ip4-cidr-length = "/" 1*DIGIT ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ] dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9 qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99 / %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199 / "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249 / "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255 / "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0 ; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 3513], section 2.2> ip6-network = <as per [RFC 4291], section 2.2>
; e.g., 2001:DB8::CD30 ; e.g., 2001:DB8::CD30
domain-spec = macro-string domain-end domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) / toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum ) ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions ; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2) ; (see [RFC3696], Section 2 for background)
alphanum = ALPHA / DIGIT alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP ) explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal ) macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" ) macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-" / "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E macro-literal = %x21-24 / %x26-7E
; visible characters except "%" ; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" / macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t" "c" / "r" / "t" / "v"
transformers = *DIGIT [ "r" ] transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "=" delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." ) name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] header-field = "Received-SPF:" [CFWS] result FWS [comment FWS]
[ key-value-list ] CRLF [ key-value-list ] CRLF
result = "Pass" / "Fail" / "SoftFail" / "Neutral" / result = "pass" / "fail" / "softfail" / "neutral" /
"None" / "TempError" / "PermError" "none" / "temperror" / "permerror"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair ) key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"] [";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string ) key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" / key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" / "problem" / "receiver" / identity /
mechanism / "x-" name / name mechanism / name
identity = "mailfrom" ; for the "MAIL FROM" identity identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity / "helo" ; for the "HELO" identity
/ name ; other identities / name ; other identities
dot-atom = <unquoted word as per [RFC2822]> ALPHA = <A-Z / a-z as per [RFC5234]>
quoted-string = <quoted string as per [RFC2822]> DIGIT = <0-9 as per [RFC5234]>
comment = <comment string as per [RFC2822]> SP = <space character as per [RFC5234]>
CFWS = <comment or folding white space as per [RFC2822]> domain = <fully qualified domain as per [RFC5321]>
FWS = <folding white space as per [RFC2822]> dot-atom = <unquoted word as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC2822]> quoted-string = <quoted string as per [RFC5322]>
comment = <comment string as per [RFC5322]>
CFWS = <comment or folding white space as per [RFC5322]>
FWS = <folding white space as per [RFC5322]>
CRLF = <standard end-of-line token as per [RFC5322]>
authserv-id = <authserv-id per [RFC5451]>
reasonspec = <reason per [RFC5451]>
Appendix B. Extended Examples Appendix B. Extended Examples
These examples are based on the following DNS setup: These examples are based on the following DNS setup:
; A domain with two mail servers, two hosts ; A domain with two mail servers, two hosts
; and two servers at the domain name ; and two servers at the domain name
$ORIGIN example.com. $ORIGIN example.com.
@ MX 10 mail-a @ MX 10 mail-a
MX 20 mail-b MX 20 mail-b
skipping to change at page 44, line 46 skipping to change at page 60, line 46
; A rogue reverse IP domain that claims to be ; A rogue reverse IP domain that claims to be
; something it's not ; something it's not
$ORIGIN 0.0.10.in-addr.arpa. $ORIGIN 0.0.10.in-addr.arpa.
4 PTR bob.example.com. 4 PTR bob.example.com.
B.1. Simple Examples B.1. Simple Examples
These examples show various possible published records for These examples show various possible published records for
example.com and which values if <ip> would cause check_host() to example.com and which values if <ip> would cause check_host() to
return "Pass". Note that <domain> is "example.com". return "pass". Note that <domain> is "example.com".
v=spf1 +all v=spf1 +all
-- any <ip> passes -- any <ip> passes
v=spf1 a -all v=spf1 a -all
-- hosts 192.0.2.10 and 192.0.2.11 pass -- hosts 192.0.2.10 and 192.0.2.11 pass
v=spf1 a:example.org -all v=spf1 a:example.org -all
-- no sending hosts pass since example.org has no A records -- no sending hosts pass since example.org has no A records
v=spf1 mx -all v=spf1 mx -all
-- sending hosts 192.0.2.129 and 192.0.2.130 pass -- sending hosts 192.0.2.129 and 192.0.2.130 pass
v=spf1 mx:example.org -all v=spf1 mx:example.org -all
-- sending host 192.0.2.140 passes -- sending host 192.0.2.140 passes
v=spf1 mx mx:example.org -all v=spf1 mx mx:example.org -all
-- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
v=spf1 mx/30 mx:example.org/30 -all v=spf1 mx/30 mx:example.org/30 -all
-- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
v=spf1 ptr -all v=spf1 ptr -all
-- sending host 192.0.2.65 passes (reverse DNS is valid and is in -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
example.com) example.com)
-- sending host 192.0.2.140 fails (reverse DNS is valid, but not -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
in example.com) in example.com)
-- sending host 10.0.0.4 fails (reverse IP is not valid) -- sending host 10.0.0.4 fails (reverse IP is not valid)
v=spf1 ip4:192.0.2.128/28 -all v=spf1 ip4:192.0.2.128/28 -all
-- sending host 192.0.2.65 fails -- sending host 192.0.2.65 fails
-- sending host 192.0.2.129 passes -- sending host 192.0.2.129 passes
B.2. Multiple Domain Example B.2. Multiple Domain Example
These examples show the effect of related records: These examples show the effect of related records:
example.org: "v=spf1 include:example.com include:example.net -all" example.org: "v=spf1 include:example.com include:example.net -all"
This record would be used if mail from example.org actually came This record would be used if mail from example.org actually came
through servers at example.com and example.net. Example.org's through servers at example.com and example.net. Example.org's
designated servers are the union of example.com's and example.net's designated servers are the union of example.com's and example.net's
skipping to change at page 46, line 10 skipping to change at page 62, line 12
These records allow a set of domains that all use the same mail These records allow a set of domains that all use the same mail
system to make use of that mail system's record. In this way, only system to make use of that mail system's record. In this way, only
the mail system's record needs to be updated when the mail setup the mail system's record needs to be updated when the mail setup
changes. These domains' records never have to change. changes. These domains' records never have to change.
B.3. DNSBL Style Example B.3. DNSBL Style Example
Imagine that, in addition to the domain records listed above, there Imagine that, in addition to the domain records listed above, there
are these: are these:
$ORIGIN _spf.example.com. mary.mobile-users A $ORIGIN _spf.example.com.
127.0.0.2 fred.mobile-users A 127.0.0.2 mary.mobile-users A 127.0.0.2
fred.mobile-users A 127.0.0.2
15.15.168.192.joel.remote-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2
16.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
The following records describe users at example.com who mail from The following records describe users at example.com who mail from
arbitrary servers, or who mail from personal servers. arbitrary servers, or who mail from personal servers.
example.com: example.com:
v=spf1 mx v=spf1 mx
include:mobile-users._spf.%{d} include:mobile-users._spf.%{d}
skipping to change at page 47, line 5 skipping to change at page 63, line 5
"-include:ip4._spf.%{d} " "-include:ip4._spf.%{d} "
"-include:ptr._spf.%{d} " "-include:ptr._spf.%{d} "
"+all" ) "+all" )
ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all" ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
ptr._spf.example.com. SPF "v=spf1 -ptr +all" ptr._spf.example.com. SPF "v=spf1 -ptr +all"
This example shows how the "-include" mechanism can be useful, how an This example shows how the "-include" mechanism can be useful, how an
SPF record that ends in "+all" can be very restrictive, and the use SPF record that ends in "+all" can be very restrictive, and the use
of De Morgan's Law. of De Morgan's Law.
Authors' Addresses Appendix C. Change History
Meng Weng Wong Changes since RFC 4408 (to be removed prior to publication)
Singapore
EMail: mengwong+spf@pobox.com Moved to standards track
Wayne Schlitt Authors updated
4615 Meredeth #9
Lincoln Nebraska, NE 68506
United States of America
EMail: wayne@schlitt.net IESG Note regarding experimental use replaced with discussion of
URI: http://www.schlitt.net/spf/ results
Full Copyright Statement Process errata:
Copyright (C) The Internet Society (2006). Resolved Section 2.5.7 PermError on invalid domains after macro
expansion errata in favor of documenting that different clients
produce different results.
This document is subject to the rights, licenses and restrictions Add %v macro to ABNF grammar
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an Replace "uric" by "unreserved"
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Recommend an SMTP reply code for optional permerror rejections
The IETF takes no position regarding the validity or scope of any Correct syntax in Received-SPF examples
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Fix unknown-modifier clause is too greedy in ABNF
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any Correct use of empty domain-spec on exp modifier
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement Fix minor typo errata
Funding for the RFC Editor function is provided by the IETF Convert to spfbis working group draft,
Administrative Support Activity (IASA). draft-ietf-spfbis-4408bis-00
Addressed Ticket #1, RFC 4408 Section 2.5.6 - Temporary errors by
giving the option to turn repeated SERVFAIL into permerror and
adding RFC 2308 reference.
Clarified text about IPv4 mapped addresses to resolve test suite
ambiguity
Clarified ambiguity about result when more than 10 "mx" or "ptr"
records are returned for lookup to specify permerror. This
resolves one of the test suite ambiguities
Made all references to result codes lower case per issue #7
Adjusted section 2.2 Requirement to check mail from per issue #15
Added missing "v" element in macro-letter in the collected ABNF
per issue #16 - section 8.1 was already fixed in the pre-WG draft
Marked ptr and "p" macro deprecated/SHOULD NOT use per issue #27
Expunged lower case may from the draft per issue #8
Expunged "x-" name as an obsolete concept
Updated obslete references: RFC2821 to RFC5321, RFC2822 to
RFC5322, and RFC4234 to RFC5234
Refer to RFC6647 to describe greylisting instead of trying to
describe it directly.
Updated informative references to the current versions.
Added definition for deprecated since there are questions.
Start to rework section 9 with some RFC5598 terms.
Added mention of RFC 6552 feedback reports in section 9.
Added draft-ietf-spfbis-experiment as an informational reference.
Drop Type SPF.
Try and clarify informational nature of RFC3696
Fix ABNF nits and add missing definitions per Bill's ABNF checker.
Make DNS lookup time limit SHOULD instead of MAY.
Reorganize and clarify processing limits. Move hard limits to new
section 4.6.4, Evaluation Limits. Move advice to non-normative
section 9.
Removed paragraph in section 10.1 about limiting total data
volumes as it is unused (and removable per the charter) and serves
no purpose (it isn't something that actually can be implemented in
any reasonable way).
Added text and figures from Alessandro Vesely in section 9.1 to
better explain DNS resource limits.
Multiple editorial fixes from Murray Kucherawy's review.
Also based on Murray's review, reworked SMTP identity definitions
and made RFC 5598 a normative reference instead of informative.
This is a downref that will have to be mentioned in the last call.
Added RFC 3834 as an informative reference about backscatter.
Added IDN requirements and normative reference to RFC 5890 to deal
with the question "like DKIM did it.:
Added informative reference to RFC 4632 for CIDR and use CIDR
prefix length instead of CIDR-length to match its terminology.
Added RFC 5782 informative reference on DNSxLs to support
improving the exists description.
Added text on creating a Authentication-Results header field that
matches the Received-SPF header field information and added a
normative reference to RFC 5451.
Added informative reference to RFC 2782 due to SRV mention.
Added informative reference to RFC 3464 due to DSN mention.
Added informative reference to RFC 5617 for it's DNS wildcard use.
Added informative reference to RFC 5782 to enhance the explanation
of how the exists mechanism works. Clarified the intended match/
no-match method.
Added new sections on Receiver policy for SPF pass, fail, and
permerror.
Added new section 9 discussion on treatment of bounces and the
significance of HELO records.
Added request to IANA to update the SPF modifier registry.
Author's Address
Scott Kitterman
Kitterman Technical Services
3611 Scheel Dr
Ellicott City, MD 21042
United States of America
Email: scott@kitterman.com
 End of changes. 318 change blocks. 
943 lines changed or deleted 1353 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--nextPart42364935.Jmi9YR0pFl-- From tim@eudaemon.net Sun Dec 16 18:34:15 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FEE321F85FD for ; Sun, 16 Dec 2012 18:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LV3K6B-F+zMy for ; Sun, 16 Dec 2012 18:34:14 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id A688C21F85F3 for ; Sun, 16 Dec 2012 18:34:14 -0800 (PST) Received: from [10.0.1.3] (sctv-72-158.mounet.com [216.145.72.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 521F5CB46 for ; Sun, 16 Dec 2012 21:34:46 -0500 (EST) From: Tim Draegen Content-Type: multipart/alternative; boundary="Apple-Mail=_42AD2A94-6DAB-44C3-B90D-93FDF27E3C75" Message-Id: Date: Sun, 16 Dec 2012 21:34:12 -0500 To: "spfbis@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [spfbis] a tool to map/diagnose SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 02:34:15 -0000 --Apple-Mail=_42AD2A94-6DAB-44C3-B90D-93FDF27E3C75 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Heyo WG, I just finished pushing out a tool to help map and diagnose SPF records. = I made this to help in my quest to demystify how SPF records work (and = how they break and therefore need to be fixed). Here are three domains that show errors of different sorts. I've = already reached out to appropriate parties about these errors. I am in = no ways trying to shame any organizations, merely trying to show that = more tools are needed to help people do the right thing. FSROUND.ORG http://dmarcian.com/spf-survey/fsround.org OUTLOOK.COM http://dmarcian.com/spf-survey/outlook.com EXACTTARGET.COM http://dmarcian.com/spf-survey/exacttarget.com Have fun! =3D- Tim --Apple-Mail=_42AD2A94-6DAB-44C3-B90D-93FDF27E3C75 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Heyo WG,

I just finished pushing out a tool to = help map and diagnose SPF records.  I made this to help in my = quest to demystify how SPF records work (and how they break and = therefore need to be fixed).

Here are three domains that show = errors of different sorts.  I've already reached out = to appropriate parties about these errors.  I am in no ways = trying to shame any organizations, merely trying to show that more tools = are needed to help people do the right thing.



= --Apple-Mail=_42AD2A94-6DAB-44C3-B90D-93FDF27E3C75-- From R.E.Sonneveld@sonnection.nl Mon Dec 17 13:15:59 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D398321F88A3 for ; Mon, 17 Dec 2012 13:15:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfIEZbsstypy for ; Mon, 17 Dec 2012 13:15:58 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 4F47021F8897 for ; Mon, 17 Dec 2012 13:15:57 -0800 (PST) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0MF700N001QJGK00@helium.mailtransaction.com>; Mon, 17 Dec 2012 22:15:55 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0MF700H0B1QJIO00@helium.mailtransaction.com>; Mon, 17 Dec 2012 22:15:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 2B675123054; Mon, 17 Dec 2012 22:15:54 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rf-QJJAPeyT1; Mon, 17 Dec 2012 22:15:51 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 38B7A123050; Mon, 17 Dec 2012 22:15:51 +0100 (CET) Message-id: <50CF8B86.6000404@sonnection.nl> Date: Mon, 17 Dec 2012 22:15:50 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-version: 1.0 To: Tim Draegen References: In-reply-to: Content-type: multipart/alternative; boundary=------------090307090104050003020309 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1355778955; bh=pCcX8qem+s311iqQ8O94QC0ku3OYNhyrK0MUplbcQ10=; h=Message-id:Date:From:Reply-to:MIME-version:To:Cc:Subject: References:In-reply-to:Content-type; b=azhiqgEXc0ajQbe2xIWmEPaXWB1QZS9VulnzIQUtcpmjE1HHSv4TxwMHl70ilZ10n EFFFiXDsZuTnlHjT1FGmC03+0d8knF59ZE71gIKx7ZV78NRU23D1nwSq28Jc1G7KD0 rGNVFCh7pCcuxWTHVnepjxKiReSBqg0bVzdGzPCM= X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0MF700N001QJGK00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] a tool to map/diagnose SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:15:59 -0000 This is a multi-part message in MIME format. --------------090307090104050003020309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, Tim, On 12/17/2012 03:34 AM, Tim Draegen wrote: > Heyo WG, > > I just finished pushing out a tool to help map and diagnose SPF > records. I made this to help in my quest to demystify how SPF records > work (and how they break and therefore need to be fixed). > > Here are three domains that show errors of different sorts. I've > already reached out to appropriate parties about these errors. I am > in no ways trying to shame any organizations, merely trying to show > that more tools are needed to help people do the right thing. > > > FSROUND.ORG > http://dmarcian.com/spf-survey/fsround.org > > OUTLOOK.COM > http://dmarcian.com/spf-survey/outlook.com > > EXACTTARGET.COM > http://dmarcian.com/spf-survey/exacttarget.com > > > Have fun! thanks for providing this tool. Like the other tools you provide us with, it looks great! One question: if I check my own domain (sonnection.nl), I get a correct result with '1 DNS queries required to resolve record'. However, the 'mx' part of the SPF record is not resolved to IP address(es). Resolving mx would result in additional DNS lookups and the total number would be more than 1. Am I misinterpreting the output of the tool, or should mx resolution be part of the picture? Regards, /rolf --------------090307090104050003020309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi, Tim,

On 12/17/2012 03:34 AM, Tim Draegen wrote:
Heyo WG,

I just finished pushing out a tool to help map and diagnose SPF records.  I made this to help in my quest to demystify how SPF records work (and how they break and therefore need to be fixed).

Here are three domains that show errors of different sorts.  I've already reached out to appropriate parties about these errors.  I am in no ways trying to shame any organizations, merely trying to show that more tools are needed to help people do the right thing.


Have fun!

thanks for providing this tool. Like the other tools you provide us with, it looks great! One question: if I check my own domain (sonnection.nl), I get a correct result with '1 DNS queries required to resolve record'. However, the 'mx' part of the SPF record is not resolved to IP address(es). Resolving mx would result in additional DNS lookups and the total number would be more than 1. Am I misinterpreting the output of the tool, or should mx resolution be part of the picture?

Regards,
/rolf

--------------090307090104050003020309-- From tim@eudaemon.net Mon Dec 17 14:03:48 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA48621F8548 for ; Mon, 17 Dec 2012 14:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuR-ABx+Jsg7 for ; Mon, 17 Dec 2012 14:03:47 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5472921F8432 for ; Mon, 17 Dec 2012 14:03:47 -0800 (PST) Received: from [10.0.1.3] (sctv-72-158.mounet.com [216.145.72.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id F13FBCB46; Mon, 17 Dec 2012 17:04:14 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_14CC11CE-934C-43C5-B852-62D8C3113921" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Draegen In-Reply-To: <50CF8B86.6000404@sonnection.nl> Date: Mon, 17 Dec 2012 17:03:41 -0500 Message-Id: <5DB3B39B-868B-4DB2-87E0-E61091319DB0@eudaemon.net> References: <50CF8B86.6000404@sonnection.nl> To: R.E.Sonneveld@sonnection.nl X-Mailer: Apple Mail (2.1499) Cc: "spfbis@ietf.org" Subject: Re: [spfbis] a tool to map/diagnose SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:03:48 -0000 --Apple-Mail=_14CC11CE-934C-43C5-B852-62D8C3113921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 17, 2012, at 4:15 PM, "Rolf E. Sonneveld" = wrote: > thanks for providing this tool. Like the other tools you provide us = with, it looks great! One question: if I check my own domain = (sonnection.nl), I get a correct result with '1 DNS queries required to = resolve record'. However, the 'mx' part of the SPF record is not = resolved to IP address(es). Resolving mx would result in additional DNS = lookups and the total number would be more than 1. Am I misinterpreting = the output of the tool, or should mx resolution be part of the picture? Thanks rolf! If you click on the node, it'll expand to show all of the "leaf" IP = addresses for the various mechanisms. Doing that will show: mx:88.198.59.243 mx:88.198.59.230 mx:88.198.59.241 mx:78.46.16.237 mx:78.46.16.213 mx:78.46.16.236 HTH, =3D- Tim --Apple-Mail=_14CC11CE-934C-43C5-B852-62D8C3113921 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 R.E.Sonneveld@sonnection.nl> wrote:
thanks for providing this tool. Like = the other tools you provide us with, it looks great! One question: if I = check my own domain (sonnection.nl),= I get a correct result with '1 DNS queries required to resolve = record'. However, the 'mx' part of the SPF record is not resolved to IP = address(es). Resolving mx would result in additional DNS lookups and the = total number would be more than 1. Am I misinterpreting the output of = the tool, or should mx resolution be part of the = picture?

Thanks = rolf!

If you click on the node, it'll expand to = show all of the "leaf" IP addresses for the various mechanisms. =  Doing that will show:

mx:88.198.59.243
mx:88.198.59.230
mx:88.198.59.241
mx:78.46.16.237
mx:78.46.16.213
mx:78.46.16.236

HTH,
=3D- = Tim

= --Apple-Mail=_14CC11CE-934C-43C5-B852-62D8C3113921-- From R.E.Sonneveld@sonnection.nl Mon Dec 17 14:27:08 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B53E421F887C for ; Mon, 17 Dec 2012 14:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LgRcbTfUyBdC for ; Mon, 17 Dec 2012 14:27:07 -0800 (PST) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 66E4B21F882B for ; Mon, 17 Dec 2012 14:27:06 -0800 (PST) Received: from process-dkim-sign-daemon.helium.mailtransaction.com by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0MF700100515KP00@helium.mailtransaction.com>; Mon, 17 Dec 2012 23:27:05 +0100 (CET) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by helium.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0MF700H13515R700@helium.mailtransaction.com>; Mon, 17 Dec 2012 23:27:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 51CB3123055; Mon, 17 Dec 2012 23:27:05 +0100 (CET) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id frRe-_37rQ7g; Mon, 17 Dec 2012 23:27:03 +0100 (CET) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id B963912301D; Mon, 17 Dec 2012 23:27:03 +0100 (CET) Message-id: <50CF9C37.4000406@sonnection.nl> Date: Mon, 17 Dec 2012 23:27:03 +0100 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-version: 1.0 To: Tim Draegen References: <50CF8B86.6000404@sonnection.nl> <5DB3B39B-868B-4DB2-87E0-E61091319DB0@eudaemon.net> In-reply-to: <5DB3B39B-868B-4DB2-87E0-E61091319DB0@eudaemon.net> Content-type: multipart/alternative; boundary=------------090308050102050703090704 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1355783225; bh=QKHHe7L4uk+Rz2KySWhOsHiI7ayjjGaZQJwTCKb+UKI=; h=Message-id:Date:From:Reply-to:MIME-version:To:Cc:Subject: References:In-reply-to:Content-type; b=OL2wxs3493diLXuSiUOI6h1E6ZndlYctoWOu+lMNWJcVK6ETI3cAvQHI1NXNCSwQP BmpkY+nKgh6UZQGPNW2dmBTMSytD6MUC9ZUUA4oFmnm99SoObEl/kJ1ksbf7tt9tRn JAmCvdegAQaQeGn2POYgsLeBUYmx+Go01pnDui94= X-DKIM: OpenDKIM Filter v2.4.3 helium.mailtransaction.com 0MF700100515KP00 Cc: "spfbis@ietf.org" Subject: Re: [spfbis] a tool to map/diagnose SPF records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:27:08 -0000 This is a multi-part message in MIME format. --------------090308050102050703090704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/17/2012 11:03 PM, Tim Draegen wrote: > On Dec 17, 2012, at 4:15 PM, "Rolf E. Sonneveld" > > wrote: >> thanks for providing this tool. Like the other tools you provide us >> with, it looks great! One question: if I check my own domain >> (sonnection.nl ), I get a correct result with >> '1 DNS queries required to resolve record'. However, the 'mx' part of >> the SPF record is not resolved to IP address(es). Resolving mx would >> result in additional DNS lookups and the total number would be more >> than 1. Am I misinterpreting the output of the tool, or should mx >> resolution be part of the picture? > > Thanks rolf! > > If you click on the node, it'll expand to show all of the "leaf" IP > addresses for the various mechanisms. Doing that will show: > > mx:88.198.59.243 > > > mx:88.198.59.230 > > > mx:88.198.59.241 > > > mx:78.46.16.237 > > > mx:78.46.16.213 > > > mx:78.46.16.236 > > > HTH, Sure! So, the '1 DNS queries required' is pertaining to the MX lookup, not the TXT/SPF query for the domain? /rolf --------------090308050102050703090704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/17/2012 11:03 PM, Tim Draegen wrote:
On Dec 17, 2012, at 4:15 PM, "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl> wrote:
thanks for providing this tool. Like the other tools you provide us with, it looks great! One question: if I check my own domain (sonnection.nl), I get a correct result with '1 DNS queries required to resolve record'. However, the 'mx' part of the SPF record is not resolved to IP address(es). Resolving mx would result in additional DNS lookups and the total number would be more than 1. Am I misinterpreting the output of the tool, or should mx resolution be part of the picture?

Thanks rolf!

If you click on the node, it'll expand to show all of the "leaf" IP addresses for the various mechanisms.  Doing that will show:

mx:88.198.59.243
mx:88.198.59.230
mx:88.198.59.241
mx:78.46.16.237
mx:78.46.16.213
mx:78.46.16.236

HTH,

Sure! So, the '1 DNS queries required' is pertaining to the MX lookup, not the TXT/SPF query for the domain?

/rolf

--------------090308050102050703090704-- From tim@eudaemon.net Mon Dec 17 18:52:22 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9821E8040 for ; Mon, 17 Dec 2012 18:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0PtNzM9rLAmw for ; Mon, 17 Dec 2012 18:52:22 -0800 (PST) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4121E8037 for ; Mon, 17 Dec 2012 18:52:21 -0800 (PST) Received: from [10.0.1.3] (sctv-72-158.mounet.com [216.145.72.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id BC2B1CB46 for ; Mon, 17 Dec 2012 21:52:53 -0500 (EST) From: Tim Draegen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <537AAB39-B814-4F6C-9E5F-D9233DEDDA8C@eudaemon.net> Date: Mon, 17 Dec 2012 21:52:20 -0500 To: "spfbis@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [spfbis] technically invalid netblocks in SPF Records X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 02:52:22 -0000 Hi Group, I recently added code to detect invalid netblock declarations, = specifically if host bits are set. This specific error happens *a lot*. I'm curious to understand what = this means, if anything, to the SPF stacks of the world. I can't = imagine there's much impact, but maybe there's just some background = radiation of failures that happen due to this. I'll likely expose this as a "Warning". Any other guidance/insight = would be much appreciated! =3D- Tim From sm@elandsys.com Tue Dec 18 07:22:17 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC8521F8A92 for ; Tue, 18 Dec 2012 07:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azC4qEABTq8t for ; Tue, 18 Dec 2012 07:22:17 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB57021F8A6C for ; Tue, 18 Dec 2012 07:22:14 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.154.158]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id qBIFM0eU008016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Dec 2012 07:22:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1355844132; bh=bGm4dQz5Zx0eZ5wvtqx4pYvH9qO1+RdoBqfMMBsi/go=; h=Date:To:From:Subject:In-Reply-To:References; b=rFGK9e+WL+epBGnMWy/dXHdQyI2DGTAWqm+ydTygn01qMT7Nk4zbpROZ/EYHciAMV nxBiLg69k4nNPaW/bCxtAw7ZUzsjTZ1goG2EWiU/dDA+/bucWpjnAZFSjvNcrvLubM puHt30G/EKQu2vR0CQJeM7uCxy0E0JP4mH5cApkY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1355844132; i=@elandsys.com; bh=bGm4dQz5Zx0eZ5wvtqx4pYvH9qO1+RdoBqfMMBsi/go=; h=Date:To:From:Subject:In-Reply-To:References; b=yM60T84IAlcHn9I1eaEMNaY4qe6OiVadMWleqDo3oXLchJFSeJgkPb3gOpLxAwJnw dcM8vxXR8TrV2CpZJ7rWoEzZGMbChW7V6blDdajRHK2bFsX6pzsACFd9BuVtm12G+C cP0pOCxkZdahwdNtCpBkEEhyKfm5iN8RBAC31UMk= Message-Id: <6.2.5.6.2.20121218071117.0aad1310@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 18 Dec 2012 07:21:09 -0800 To: spfbis@ietf.org From: S Moonesamy In-Reply-To: <13162108.dfXztYiDo9@scott-latitude-e6320> References: <20121123204745.GB56042@crankycanuck.ca> <4350053.YsP51LBrxt@scott-latitude-e6320> <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> <13162108.dfXztYiDo9@scott-latitude-e6320> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:22:18 -0000 Hi Scott, Thanks for the diff ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03070.html ). Murray Kucherawy already indicated that he was ready to assist with version -09. Could you provide a tentative date for when version -09 will be ready for review? Regards, S. Moonesamy From spf2@kitterman.com Tue Dec 18 07:25:11 2012 Return-Path: X-Original-To: spfbis@ietfa.amsl.com Delivered-To: spfbis@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A121F8AA4 for ; Tue, 18 Dec 2012 07:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7i7hW5XDdal for ; Tue, 18 Dec 2012 07:25:10 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) by ietfa.amsl.com (Postfix) with ESMTP id 1F81121F8A81 for ; Tue, 18 Dec 2012 07:25:10 -0800 (PST) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 2FC66D0405F; Tue, 18 Dec 2012 09:25:09 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1355844309; bh=I2/tdl9ZT4WK6/gq1OwBaXSPclw/OEb4TxU7A+BcU6U=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Wu73zuZe9e9paWY822DEMVDHpjR0fqgVquqSoqCMQ8nUR/66+x/D3XgXgubKL0xqd IJbpmqO21cdl7KmaXKMplRZUQqeRXasWeuY8IGXp6vm1U/Dsdsy7ZZTVpXdq54VXEG bXfjuFYG74+W7f27Y1eX2U1u3/GKH13ZY5XHcxmM= Received: from [IPV6:2600:1003:b01b:f3e9:220:555d:a40d:5344] (unknown [IPv6:2600:1003:b01b:f3e9:220:555d:a40d:5344]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 27DD8D04092; Tue, 18 Dec 2012 09:25:07 -0600 (CST) User-Agent: K-9 Mail for Android In-Reply-To: <6.2.5.6.2.20121218071117.0aad1310@resistor.net> References: <20121123204745.GB56042@crankycanuck.ca> <4350053.YsP51LBrxt@scott-latitude-e6320> <6.2.5.6.2.20121213084755.0b7c88c8@resistor.net> <13162108.dfXztYiDo9@scott-latitude-e6320> <6.2.5.6.2.20121218071117.0aad1310@resistor.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Tue, 18 Dec 2012 10:25:01 -0500 To: spfbis@ietf.org Message-ID: <4bba8e74-2c12-4c44-99db-891279958573@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [spfbis] Follow-up after IETF 85 X-BeenThere: spfbis@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SPFbis discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:25:11 -0000 S Moonesamy wrote: >Hi Scott, > >Thanks for the diff ( >http://www.ietf.org/mail-archive/web/spfbis/current/msg03070.html ). > >Murray Kucherawy already indicated that he was ready to assist with >version -09. Could you provide a tentative date for when version -09 >will be ready for review? I expect to have time next work to get it sorted. Scott K