Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
S Moonesamy <sm+ietf@elandsys.com> Sat, 24 August 2013 10:18 UTC
Return-Path: <sm@elandsys.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 C6BD421F9D56 for <ietf@ietfa.amsl.com>; Sat, 24 Aug 2013 03:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level:
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 j33z6k3GaPrP for <ietf@ietfa.amsl.com>; Sat, 24 Aug 2013 03:18:18 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8E321F9D39 for <ietf@ietf.org>; Sat, 24 Aug 2013 03:18:16 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.226.232.200]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r7OAHtGX021244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 03:18:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1377339489; bh=xXWOHuDWquXiff+5gplidPIIEx2uZQH8bHKdOainAC8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QHm1bZ9cURbYPY/l0MD7D3SxGTs5f6xUXcEnKBi3fBh8DSP4ArH34MRmdCjapoBaR kOGCjPh2CCyl4gpgMCbg8rO09r6N0A4/Ne8MSAImcKRG5TRPC/B4phlXUDeF2F2nmH oV+ugcOzhHl2CJWMHqvgWaeVF4o6RQe1Zn3o1CEA=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1377339489; i=@elandsys.com; bh=xXWOHuDWquXiff+5gplidPIIEx2uZQH8bHKdOainAC8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gMCZful4Z0LmpOBHKJ7fbuOCe5F1iDSMzxuXSlKe71yFxomeoLZlePTRwkwBLS/eF VBvr4ee7695UKEyNpUlJCUNQwSd1XZHqY4F37XVvJcCyzdM2+aSis1KDDJxb3vaR1y mWGeR1CzLojLncS0gFbiZ7kB5yzfnB/2MCrT8hMY=
Message-Id: <6.2.5.6.2.20130823234808.0b7cfed0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 24 Aug 2013 03:16:30 -0700
To: Douglas Otis <doug.mtview@gmail.com>
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard
In-Reply-To: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com>
References: <9884B9CD-0ED3-4D89-A100-58D05EA4BC98@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: ietf@ietf.org
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: Sat, 24 Aug 2013 10:18:19 -0000
Hi Doug, At 13:07 23-08-2013, Douglas Otis wrote: >The SPFbis document improperly conflates DNS terminology with >identical terms invented by this document. Examples are terms used >to describe mechanisms having the same identifier differentiated >between mechanisms and DNS resource records by using lower and upper >case respectively. References to SPF records are differentiated by >a textual prefix and not by TYPE as defined by DNS. Could you provide some examples of the above as I would like to clearly understand the argument? >In addition, the MARID WG NEVER reached consensus. A follow-on >group operating outside of the IETF required a promise of support to >subscribe to their mailing list. When one looks at how SPF is >commonly used, the pre-existing APL resource record offered an >effective alternative, but was oppose by a particular vendor >unwilling to fully implement DNS. Currently this vendor is seldom >used to directly interface with MTAs on the Internet and no longer >justifies the use of the TXT records. As such, the SPF Resource >Record should not have been deprecated. There are other messages on the Last Call about the SPF Resource Record. I'll take up the above together with the other comments. >This draft should be made Informational and not Standards Track. I suggest providing arguments for that. >Section 4.6.4 fails to offer a sufficiently clear warning about >potential magnitudes of DNS transactions initiated by a single SPF >evaluation where two are recommended to occur one for the separate >identifiers. In fact, this section appears to make assurances no >more that 10 DNS queries will result and is widely misunderstood. There is a discussion about Section 4.6.4 at http://www.ietf.org/mail-archive/web/spfbis/current/msg03305.html >4.6.4. DNS Lookup Limits > >Was: >,-- >SPF implementations MUST limit the total number of mechanisms and >modifiers ("terms") that cause any DNS query to 10 during SPF >evaluation. >'-- > >Change to: >,--- >SPF evaluation must limit the number of mechanisms, and the modifier >term 'redirect' to occur in no more than10 instances within the >evaluation process. The mechanisms 'ip4', ip6', and 'all' are >excluded from this instance limitation. Each mechanism is permitted >to resolve subsequent resource record sets (RRsets) that MUST not >contain more than 10 resource records to complete a match check. >When the number of instances exceeds 10, or when subsequent >resolutions exceeds 10, check_host() MUST produce a "permerror" >result. > >The maximum number of DNS transactions initiated by an SPF >evaluation is therefore 1 for the initial SPF resource record, 10 for >each mechanism times 10 transactions needed to complete a matching >process for a total of 111 DNS transactions. This number excludes >those required by DNS to fulfill a request and those required by an >EXP modifier. I'll list the above as not addressed yet. >The recommended 20 second evaluation timeout imposes a maximum >network distance of less than 27,000 kilometers or a little more than >half the circumference of the Earth. Even a 60 millisecond delay can >result in more than a 6.6 seconds consumed by the round trip >overhead needed for each SPF evaluation. During the WGLC Murray Kucherawy asked a question about the 20 second evaluation timeout ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03700.html ). The answer was that the timeout is already in RFC 4408. >The overall resulting maximum number of DNS transactions for >both "HELO" and "MAIL FROM" is 222 DNS transactions. Since >check_host() introduces macros and name expansions that >combine mechanisms and modifiers in a manner not directly >supported by DNS, the entire set and sequence of SPF based >DNS transactions is required for each evaluation. While SPF now >has a 2 limit of void lookups, use of synthetic domains has become >a popular technique for tracking traffic which can be used by >malefactors to overcome this SPF void lookup limit. The draft agenda for the IETF 83 session was posted to the SPFBIS mailing list on March 14, 2012. One of the items on that agenda was "DNS amplification attacks" ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01021.html ). It would have been good more discussion of the issue (Issue #24) from a DNS perspective. As there has been numerous comments about the DNS angle during this Last Call, maybe an IETF participant will be able to provide some input about the above. >Once DNSsec becomes a requirement, SPF will have created an >inordinate number of transactions and overall traffic per message >exchange that will impose a SIGNIFICANT reflected amplification risk. draft-ietf-spfbis-4408bis-19 does not have any DNSSEC requirement. >'--- > >Related information: > ><random-string>cdr-ds.metric.gstatic.com ><random-string>.g.vm.akamaistream.net >are domains on sizable networks that act as a wildcards. In the >second instance, the wildcard points to a CNAME that then resolves >an A record. Such use compared against >http://tools.ietf.org/html/draft-otis-spf-dos-exploit-01 produces a >much larger amplification than the x320 gain estimated. Use of >DNSsec further increases this gain estimate. Although details >differ from case to case, the synthetic domain technique is seeing >greater use. One of the initial reasons for using TXT records >without any prefix was to permit use of wildcards. This dangerous >feature means SPF allows malefactors to leverage any large TXT >resource record that otherwise would not have been >problematic. Again this risk increases when DNSsec becomes required >and represents another reason for not deprecating the SPF resource record type. I welcome comments from other IETF participants about the above. >Remove this misleading paragraph within section 4.6.4: >,--- >When evaluating the "mx" mechanism, the number of "MX" resource >records queried is included in the overall limit of 10 mechanisms/ >modifiers that cause DNS lookups described above. The evaluation of >each "MX" record MUST NOT result in querying more than 10 address >records, either "A" or "AAAA" resource records. If this limit is >exceeded, the "mx" mechanism MUST produce a "permerror" result. >'--- > >MX resource records do not contain IP addresses. >Per RFC1035 the structure for an MX record is roughly as follows: > >A 16 bit PREFERENCE (distance) value followed by an MTA hostname. > >A DNS MX reply may offer A records for the hostnames in the >Additional Section however per: >Per RFC2181 Section 5.4: >,--- >Servers must never merge RRs from a response with RRs in their >cache to form an RRSet. If a response contains data that would form >an RRSet with data in a server's cache the server must either ignore >the RRs in the response, or discard the entire RRSet currently in the >cache, as appropriate. >'--- > >This will not prove ideal for SPF with respect to effective use of DNS. > >Also hostnames contained within MX resource record might be within >any domain, and not necessarily the same domain as that of the base SPF record. > >Per RFC2181 5.4.1. Ranking data >An authoritative answer from a reply should replace cached data that >had been obtained from additional information in an earlier reply. >However additional information from a reply will be ignored if the >cache contains data from an authoritative answer or a zone file. I agree that MX resource records do not contain IP addresses. There is a thread at http://www.ietf.org/mail-archive/web/spfbis/current/msg03305.html about reasonable DNS error limits. I could not spot the problem in the paragraph that is described as misleading. An example to illustrate the problem might make it clearer. >Mistake. > >Section 3.4 > >Second paragraph: > >Similarly, the sizes for replies to all queries related to SPF have >to be evaluated to fit in a single 512 octet UDP packet. > >s/UDP packet/DNS message/ My understanding of the working group discussion is that the intent is to have the DNS reply fit within a UDP packet. >Per RFC1035 >Section 2.3.4. Size limits >UDP messages 512 octets or less > > >Section 4.2.1. UDP usage >Messages carried by UDP are restricted to 512 bytes (not counting >the IP or UDP headers). > >The DNS message size limitation is not the same as a UDP packet >limit as suggested in Section 3.4. I am not sure whether the above refers to the "450 octets". I'll note a comment from Andrew Sullivan ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03103.html ) so that I don't have to search for it again. >The SPFbis WG charter permitted removal of unused protocol elements >where the "ptr" mechanism was deprecated and the SPF resource type >was removed. Use of SPF's very dangerous macro feature currently has >less than 0.053% of the domains making use of these macros and >clearly falls below the WG removal threshold. We have also been >told by a few very large providers that SPF records containing any >macro reference are ignored for reasons related to both efficiency >and security. Marcos also inhibit the primary use by large >providers which is to compile the domain's IP address list. There was an appeal about the meaning of the word "unused" ( http://www.ietf.org/mail-archive/web/spfbis/current/msg02167.html ). I'll highlight a comment from Pete Resnick: "There's also the comment from Doug Otis about the local-part macro. I'm inclined to declare that out of scope, maybe after a recharter. That's not documenting current practice, but is an overt change." There are some threads about local part macros: http://www.ietf.org/mail-archive/web/spfbis/current/msg00911.html http://www.ietf.org/mail-archive/web/spfbis/current/msg01870.html There is a short thread and a few other threads about the "ptr" mechanism ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00808.html http://www.ietf.org/mail-archive/web/spfbis/current/msg00811.html http://www.ietf.org/mail-archive/web/spfbis/current/msg03184.html ). There is the following text in the write-up: "There was some controversy about whether the use of macros was a security risk and whether to deprecate the PTR feature. There was a formal appeal of the SPFBIS WG chair' interpretation of the charter, specifically regarding the removal of "unused" features. The two features in particular which drove the appeal were the PTR feature and the local-part macro feature. These features were not removed from the document given that the appeal was denied by the Responsible Area Director." I hope that the above explains the decision. >The WG should have been told to focus on security and at better >insuring interchange to achieve a safer stance moving forward. The working group was reminded about BCP 72. Regards, S. Moonesamy (as document shepherd)
- 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