Re: Macro Expansion (was: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
Douglas Otis <doug.mtview@gmail.com> Wed, 18 September 2013 18:20 UTC
Return-Path: <doug.mtview@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952AF11E80DE; Wed, 18 Sep 2013 11:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs3vF4jP+Udz; Wed, 18 Sep 2013 11:20:25 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 790FB21F9C9A; Wed, 18 Sep 2013 11:20:25 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id up15so7293976pbc.40 for <multiple recipients>; Wed, 18 Sep 2013 11:20:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6eFDg1BrMZy/NwQT1e4r/AkJlDx6kmWtkzB3ui6+W/M=; b=ITpgBUoVcTA0XKcSSSCDcGYerJ3pcT1p/zKzE+fY0NueF5WtxONqgW0WJTU6O/9xbj gz6m82EUgWpz0AiLGQPY+7D+/5LmX9UQWGJQpG/rW9J4oWkdQ7gOS3bsZy0kanZsFeHk gkRfe/vU7PygIMZqX/BGWOaP3a+vO/w7atpxkW10w4AiUTcCZEyRMiDKTFUSBpUE4lPZ eRUJJRQktMn7GiTB1UZbcfcELf5SwPmpfJRw3kX7XTrhCi6ByF773qlGElaXzY7T8DBX gov/BvM2A6+NFpDM7lLWHF4DvYUdNaQwmw5w69iKH2MREjnvRlSzxnf8Ft36hGPY8DlQ geHA==
X-Received: by 10.66.163.164 with SMTP id yj4mr44971994pab.91.1379528420222; Wed, 18 Sep 2013 11:20:20 -0700 (PDT)
Received: from [192.168.2.232] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id yh1sm4030453pbc.21.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 11:20:19 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Subject: Re: Macro Expansion (was: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard)
From: Douglas Otis <doug.mtview@gmail.com>
In-Reply-To: <6.2.5.6.2.20130916014542.0b496658@elandnews.com>
Date: Wed, 18 Sep 2013 11:20:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <6F17786D-77A9-4B15-BA6B-FFA40E1E02D6@gmail.com>
References: <6FC7A544-0AB5-4BC0-A0BF-D0D8D740D3B8@gmail.com> <6.2.5.6.2.20130916014542.0b496658@elandnews.com>
To: S Moonesamy <sm+ietf@elandsys.com>
X-Mailer: Apple Mail (2.1508)
Cc: spfbis@ietf.org, spfbis-chairs@tools.ietf.org, Pete Resnick <presnick@qti.qualcomm.com>, ietf@ietf.org, Scott Kitterman <spf2@kitterman.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Sep 2013 18:20:26 -0000
Dear SM, See comments inline. On Sep 16, 2013, at 9:00 AM, S Moonesamy <sm+ietf@elandsys.com> wrote: > Hi Doug, > At 21:55 11-09-2013, Douglas Otis wrote: >> Add to: >> 11.5.3. Macro Expansion >> ,--- >> It is not within SPF's purview whether IPv6 or DNSSEC is being used. IPv6 (RFC2460) increased the minimum MTU size to 1280 octets. DNSSEC is deployed with EDNS0 (RFC6891) to avoid TCP fallback. EDNS0 suggests an MTU increase between 1280 and 1410 octets offers a reasonable result starting from a request of 4096 octets. A 1410 MTU offers a 2.4 times payload increase over the assumed MTU of 576 octets and is widely supported by Customer Premise Equipment. With increased MTUs being used with DNS over UDP, network amplification concerns increase accordingly. >> >> SPF macros can utilize SPF parameters derived from email messages that can modulate the names being queried in several ways without publishing additional DNS resources. The SPF macro feature permits malefactors a means to covertly orchestrate directed DDoS attacks from an array of compromised systems while expending little of their own resources. >> >> Since SPF does not make use of a dedicated resource record type or naming convention, this leaves few solutions available to DNS operations in offering a means to mitigate possible abuse. This type of abuse becomes rather pernicious when used in conjunction with synthetic domains now popular for tracking users without using web cookies. >> >> However, email providers can mitigate this type of abuse by ignoring SPF records containing macros. Very few domains make use of macros, and ignoring these records result in neutral handling. Some large providers have admitted they make use of this strategy without experiencing any notable problem. AOL began their support of SPF by saying they would use SPF to construct whitelists prior to receipt of email. Clearly, such whitelisting practices tends to preclude benefits derived from macro use. >> '--- > > As background information I read draft-otis-spfbis-macros-nixed-01. I read the messages where EDNS0 was mentioned [1]. I read the messages on the thread starting with msg-id: 9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com. I have followed the discussions about macros ever since the SPFBIS WG was chartered. > > The above suggestion is to add text in the Security Considerations section of the draft. The problem being pointed out is, in simple terms, DNS amplification. The first (quoted) paragraph argues that there can be an acute problem because of EDNS0 as specified in the Internet Standard. > > The second paragraph starts with SPF macros can utilize SPF parameters derived from email messages". I do not understand that. From what I understand the rest of the second (quoted) paragraph argues that the SPF macro feature permits evildoers to use it as an attack vector. Since this was not understood, I'll attempt to clarify. An effort to keep these conversations fairly concise seems to lead to a level of confusion with those not familiar with DNS. DNS UDP traffic lacks congestion avoidance when used to covertly direct attacks. Residential systems represent a large component of compromised systems involved with email although data centers measured by overall traffic is increasing. Network amplification is measured by gains beyond exchanges initiating a higher volume of exchanges. DNS caching tends to reduce subsequent exchanges. SPFbis macros inhibit normal caching protections by imposing mechanisms not directly supported by DNS and having targets constructed from email message components. SPFbis mechanism names can be misleading since they are given a related manipulated DNS resource name. One SPFbis mechanism can represent more than 100 subsequent DNS transactions where normally resolving the resource would represent a single transaction. Publishing new targets within DNS resources to circumvent caching would normally be expensive and unlikely to provide remarkable gain. SPFbis macros change this equation significantly. SPFbis offers macros to translate code points, restructure host labels, build labels from the client IP address, make use of the local-part of the message return path or some label in the EHLO hostname, etc. In other words, SPFbis macros permit malefactors a means to modulate the target of their queries while still leveraging their own cached DNS records. This means a malefactors' DNS resources can be highly leveraged as a result of recipient SPFbis macro processing. Secondly, SPFbis also ignores the overall size of the resources being queried in many cases. The most egregious is perhaps that of the unlimited PTR RRsets which then results in a series of address RRset resolutions cascading down the hostname labels that happens for a maximum of 10 PTRs that might be offered on either a random or round robin basis. It would be extremely difficult to determine the number of transactions and overall traffic volume any single PTR mechanism might impose, for example. > The argument in the third (quoted) paragraph is that it is not possible to mitigate possible (DNS) abuse due to the SPF as it does not have a dedicated resource record type. Or a naming convention that might support mitigation efforts. > The fourth (quoted) paragraph argues that macros should be ignored. That paragraph also mentions that some large providers admitted to using that strategy. I am not aware of any public reports about that. As was said, AOL made their use of prefetching of SPF public at the beginning which precluded use of macros. Others have also adopted this practice but have not made their use public. > I read draft-otis-spfbis-macros-nixed-01 again to try and understand the problem. It seems to be the: > > '{%l}._spf.{%d} or exists:{%i}_spf.{%d} can be used in "specialized" > DNS servers able to understand encrypted local-parts' There is nothing in SPFbis that limits the structured use of DNS resources. In this example, it shows the expansion of the return path local-part, which represents a non-suspicious variable not derived from DNS, that can increase the leverage obtained in DNS related attacks. A similar attack might manipulate HELO hostname or MAIL FROM domain labels as well. > which is discussed in Appendix E of draft-ietf-spfbis-4408bis-20. > > Arthur Thisell commented about the "specialized DNS server". He mentioned that at the time that text was written two people came forward to say that they were doing that. During the SPFBIS discussions nobody stated that he or she has implemented or is using a "specialized" DNS server. > > I'll ask the person editing draft-ietf-spfbis-4408bis or the SPFBIS WG to provide some publicly verifiable cases where these examples are used. > > I assume that the SPFBIS WG and the Responsible Area Director have understood the mathematics relating to EDNS0 and DNS amplification. Anyone who has not understood that part is welcome to raise the issue on the SPFBIS mailing list. > > The discussion about the "dedicated resource record type" has led to agreement. I'll describe the agreement as something people can live with. In my opinion it is better not to start another discussion about that. > > I hope that what I wrote above clearly explains what I have understood and what I have not understood. > > Regards, > S. Moonesamy (as document shepherd) Regards, Douglas Otis
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John R Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- SPF TYPE support Hector Santos
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… HLS
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Murray S. Kucherawy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: SPF TYPE support Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: SPF TYPE support S Moonesamy
- Re: [spfbis] SPF TYPE support Ted Lemon
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: SPF TYPE support Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Randy Bush
- Re: SPF TYPE support Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] SPF TYPE support Hector Santos
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Hector Santos
- Re: [spfbis] prefixed names, was Last Call: <draf… John Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dotzero
- Re: [spfbis] prefixed names, was Last Call: <draf… Mark Andrews
- Re: [spfbis] prefixed names, was Last Call: <draf… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] SPF TYPE support S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Phillip Hallam-Baker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Eliot Lear
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Eliot Lear
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… manning bill
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Andrew Sullivan
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Alessandro Vesely
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Ted Lemon
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Hector Santos
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] there is no transitiion, was Last Ca… John Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] there is no transitiion, was Last Ca… Ted Lemon
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Olafur Gudmundsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Patrik Fältström
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Leslie
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Dave Crocker
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Dave Crocker
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Barry Leiba
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Stephen Farrell
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: Rude responses (Was: Last Call: <draft-ietf-s… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Mark Andrews
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Hector Santos
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… David Conrad
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Scott Kitterman
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Måns Nilsson
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Olafur Gudmundsson
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Scott Brim
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Thomas Narten
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Pete Resnick
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Murray S. Kucherawy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Barry Leiba
- RE: Rude responses (Was: Last Call: <draft-ietf-s… l.wood
- The Last Call social contract (was - Re: Rude res… Dave Crocker
- RE: The Last Call social contract (was - Re: Rude… l.wood
- RE: The Last Call social contract (was - Re: Rude… Dave Cridland
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Visibility of shepherd writeup Carsten Bormann
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John Levine
- Re: The Last Call social contract (was - Re: Rude… Scott Brim
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… S Moonesamy
- Re: The Last Call social contract (was - Re: Rude… Dave Crocker
- Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Se… Douglas Otis
- Re: The Last Call social contract (was - Re: Rude… Hector Santos
- Re: The Last Call social contract (was - Re: Rude… S Moonesamy
- Re: The Last Call social contract (was - Re: Rude… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: Rude responses (Was: Last Call: <draft-ietf-s… Abdussalam Baryun
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John R Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… John R Levine
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Jelte Jansen
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Scott Kitterman
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Scott Kitterman
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Scott Kitterman
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Overloaded TXT harmful (was" Re: [spfbis] Last Ca… John C Klensin
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Joe Abley
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bi… Pete Resnick
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Patrik Fältström
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Scott Kitterman
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Mark Andrews
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… John C Klensin
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Dave Crocker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… John C Klensin
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Dan Schlitt
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… John Levine
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… David Conrad
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… S Moonesamy
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt>… Douglas Otis
- Macro Expansion (was: Last Call: <draft-ietf-spfb… S Moonesamy
- Re: Macro Expansion (was: Last Call: <draft-ietf-… Douglas Otis
- Re: Macro Expansion Pete Resnick