Re: [ietf-dkim] SSP issues
Jim Fenton <fenton@cisco.com> Thu, 31 May 2007 17:37 UTC
Return-path: <ietf-dkim-bounces@mipassoc.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtoaC-0003bs-74 for ietf-dkim-archive@lists.ietf.org; Thu, 31 May 2007 13:37:08 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtoaA-0002bY-Iv for ietf-dkim-archive@lists.ietf.org; Thu, 31 May 2007 13:37:08 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4VHZbD1030879; Thu, 31 May 2007 10:35:45 -0700
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4VHZSx2030826 for <ietf-dkim@mipassoc.org>; Thu, 31 May 2007 10:35:28 -0700
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 31 May 2007 10:35:24 -0700
X-IronPort-AV: i="4.14,599,1170662400"; d="scan'208"; a="3624042:sNHT31204140"
Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4VHZO8Z022382; Thu, 31 May 2007 10:35:24 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l4VHZM2K028465; Thu, 31 May 2007 17:35:24 GMT
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 10:35:03 -0700
Received: from fenton-mac.cisco.com ([10.32.251.8]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 May 2007 10:35:03 -0700
Message-ID: <465F073D.3070802@cisco.com>
Date: Thu, 31 May 2007 10:34:53 -0700
From: Jim Fenton <fenton@cisco.com>
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Bill.Oxley@cox.com
Subject: Re: [ietf-dkim] SSP issues
References: <198A730C2044DE4A96749D13E167AD37012A5BFE@MOU1WNEXMB04.vcorp.ad.vrsn.com> <465EDB0E.4030409@cisco.com> <BB621D48443A854A89D86528F915864C042F4C9E@CATL0MS02.corp.cox.com>
In-Reply-To: <BB621D48443A854A89D86528F915864C042F4C9E@CATL0MS02.corp.cox.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 May 2007 17:35:03.0221 (UTC) FILETIME=[054F7650:01C7A3AA]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6722; t=1180632924; x=1181496924; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20<fenton@cisco.com> |Subject:=20Re=3A=20[ietf-dkim]=20SSP=20issues |Sender:=20; bh=D52qhuW1T1oLOuphP/RxIm+Im3/Y+sw9Jse1Fb70rkk=; b=p/U5jZgCMZEAeRnIPxJdBqHP/SxGSp+nEEdVxzP7n6cN0vcCpE4DzyBv0Y+F+T3uqd3l024j 8kPoyFLC5fKQG24c4fIqoSHxO5dsz+zo5Bsgw74V5LIdKTTIP/vSxb5J;
Authentication-Results: sj-dkim-4; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; );
X-Songbird: Clean, Clean
Cc: ietf-dkim@mipassoc.org
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7
The problem is that the default needs to be "I do send mail", and "I don't sign everything", since that is the current situation. In other words, the lack of an SSP record corresponding to "badguy.foo.com" cannot be interpreted as suspicious, since it could simply be someone who hasn't implemented SSP and doesn't have a record for that reason. -Jim Bill.Oxley@cox.com wrote: > Please excuse my lack of DNS knowledge here > Ssp.foo.com returns "I send no mail" > Would work in the same fashion as mx.foo.com, a query returning a > result. If a bad actor wanted to claim badguy.foo.com and an ssp query > did not return data from ssp.badguy.foo.com it then becomes a local > policy decision on whether to deliver or not. I must be missing > something. > Thanks, > > Bill Oxley > Messaging Engineer > Cox Communications > > -----Original Message----- > From: ietf-dkim-bounces@mipassoc.org > [mailto:ietf-dkim-bounces@mipassoc.org] On Behalf Of Jim Fenton > Sent: Thursday, May 31, 2007 10:26 AM > To: Hallam-Baker, Phillip > Cc: IETF DKIM WG > Subject: Re: [ietf-dkim] SSP issues > > Hallam-Baker, Phillip wrote: > >>> [mailto:ietf-dkim-bounces@mipassoc.org] On Behalf Of Jim Fenton >>> >>> (2) SSP record type (TXT vs. something new). Only 4 messages >>> in discussion, mostly saying "if you support TXT, don't >>> bother with anything else." Again, no clear consensus. >>> >>> >> I see no value in an SSP record type. The downside for DKIM is serious >> > - we are gated on new deployments of DNS server code. The downside for > the DNS described above is equally serious. > >> >> > > If we would be gated on new deployments of DNS server code, wouldn't > this be equally true for XPTR records? > >> As a general rule: deployment of a new Internet protocol or protocol >> > enhancement such as DKIM should not require consumption of any finite > infrastructure resource. DNS RRs are one such resource. > >> >> > > I would have expected this comment from the DNS directorate if there was > threat of running out of DNS RRs, but much the opposite: the IAB "DNS > choices" draft recommends creation and use of new RRs. > >> The only objection made to using TXT that has been sustained is the >> > wildcard issue and that has been answered by XPTR. The principled > approach here is to use a new RR to extend the DNS infrastructure so it > never needs future extension for other projects with similar goals. > >> I think that we should only do TXT. The consequence of this is that >> > any email sender can express the policy 'I sign all mail from > example.com' without modifying their DNS. The sand in the shoe is that > they have to upgrade their DNS server to express the policy 'All mail > from *.example.com is signed'. > >> >> > > I'm not clear on what "only do TXT" means in this context -- do you mean > a directly referenced TXT record or one retrieved via an XPTR lookup or > both? > >> I accept the sand in the shoe reluctantly for the following reasons: >> >> 1) I don't think that the policy 'All mail from *.example.com is >> > signed' is legitimate, I can see a need for the policy 'No mail is sent > from *.example.com' but that is out of scope. I can see how this can > happen due to split DNS but anyone operating DKIM in this mode should > either enter the DNS nodes in the external DNS or do the appropriate > mapping before they sign. > >> 2) Regardless of the wildcard mechanism employed (new RR, XPTR, >> > whatever) administrative wildcards are going to be essential on a zone > of any size. > >> >> > > I think I know from context and from talking with you what > "administrative wildcards" are, but is this a generally used term? If > not, you might want to explain. > >> 3) There is an advantage to DKIM in encouraging deployment of DNS >> > servers capable of DNSSEC. > >> >> > > Yes, but I don't see how that is relevant here. > > > >>> (3) Upward query vs. wildcard publication. 27 messages in >>> discussion from 15 people. Most of the discussion was a >>> rehash of the idea of associating semantics with DNS >>> zone-cuts, which we had already discussed and rejected. I >>> have also been trying to get an opinion from DNSOP on the >>> idea of a one-level upward search (which I think solves 90% >>> of the problem), but haven't gotten any response. >>> >>> So I don't know what to write in a revision of the draft. I >>> could just write my opinions, but that's basically what's in >>> the draft-allman-dkim-ssp-02 draft already and doesn't make >>> any progress toward unifying the different proposals. I want >>> to get something done soon, well before the July 2 deadline. >>> >>> >> I think that this is where we reach the 'non-negotiable' issue for the >> > DNS cabal. Misimplementation of upward query is a major cause of load on > the DNS. The DNS cabal will complain loudly on this issue and they will > actually have a case. > >> >> > > "...is a major cause": currently? I don't see how we can design any > protocol that is misimplementation-proof. > >> What does make sense is to have a policy: >> 'All mail from {example.com, alice.example.com, bob.example.com} >> > is signed' > >> OTHERWISE 'No mail is sent from *.example.com' >> >> I can't see where I would be signing mail from a domain name with no >> > external existence. > >> OK here we come to a strange observation I made to Jim earlier. DKIM >> > does not require a wildcard for DKIM signature policies. 'I sign > everything in *.example.com' does not make sense, the wildcard that does > make sense is 'Nomail is sent from *.example.com'. Which is of course > out of scope, so maybe the whole wildcard issue is out of scope for DKIM > policy and is only in scope for DKIM policy extensions (e.g. NOMAIL). > >> >> > > Agree that the NOMAIL policy is the more interesting one to express with > a wildcard. There are some cases where it might be convenient to > express a signing policy for subdomains, but in every case I can think > of it's practical for the subdomains to publish their own SSP record. > > -Jim > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
- [ietf-dkim] SSP issues Jim Fenton
- Re: [ietf-dkim] SSP issues Scott Kitterman
- Re: [ietf-dkim] SSP issues Michael Thomas
- Re: [ietf-dkim] SSP issues william(at)elan.net
- Re: [ietf-dkim] SSP issues Douglas Otis
- Re: [ietf-dkim] SSP issues Scott Kitterman
- Re: [ietf-dkim] SSP issues william(at)elan.net
- Re: [ietf-dkim] SSP issues Michael Thomas
- Re: [ietf-dkim] SSP issues Douglas Otis
- Re: [ietf-dkim] SSP issues Hector Santos
- Re: [ietf-dkim] SSP issues Steve Atkins
- Re: [ietf-dkim] SSP issues John Levine
- Re: [ietf-dkim] SSP issues John L
- Re: [ietf-dkim] SSP issues John L
- Re: [ietf-dkim] SSP issues Graham Murray
- Re: [ietf-dkim] Domain Lists versus SSP Wildcards Douglas Otis
- RE: [ietf-dkim] SSP issues Hallam-Baker, Phillip
- Re: [ietf-dkim] SSP issues Jim Fenton
- Re: [ietf-dkim] SSP issues Jim Fenton
- RE: [ietf-dkim] SSP issues Bill.Oxley
- Re: [ietf-dkim] SSP issues Jim Fenton
- RE: [ietf-dkim] SSP issues Bill.Oxley
- Re: [ietf-dkim] Domain Lists versus SSP wildcards Douglas Otis
- Re: [ietf-dkim] SSP issues Stephen Farrell
- Re: [ietf-dkim] SSP issues Jim Fenton
- Re: [ietf-dkim] SSP issues Arvel Hathcock
- Re: [ietf-dkim] SSP issues Hector Santos
- Re: [ietf-dkim] SSP issues Steve Atkins
- Re: [ietf-dkim] SSP issues Hector Santos
- Re: [ietf-dkim] SSP issues TXT and no wildcards. Douglas Otis
- Re: [ietf-dkim] SSP issues Eliot Lear
- Re: [ietf-dkim] SSP issues Hector Santos
- Re: [ietf-dkim] SSP issues Eliot Lear
- [ietf-dkim] Single Organization TXT Lookup with M… Hector Santos
- [ietf-dkim] Re: Single Organization TXT Lookup wi… Douglas Otis
- Re: [ietf-dkim] SSP issues Scott Kitterman
- Re: [ietf-dkim] SSP issues Steve Atkins
- Re: [ietf-dkim] SSP issues Scott Kitterman
- Re: [ietf-dkim] SSP issues Douglas Otis
- Re: [ietf-dkim] SSP issues Steve Atkins
- Re: [ietf-dkim] SSP issues Scott Kitterman
- Re: [ietf-dkim] SSP issues J.D. Falk
- Re: [ietf-dkim] SSP issues Scott Kitterman
- Re: [ietf-dkim] SSP issues Steve Atkins
- Re: [ietf-dkim] SSP issues Dave Crocker
- Re: [ietf-dkim] SSP issues John Levine
- Re: [ietf-dkim] SSP issues Steve Atkins
- Re: [ietf-dkim] TXT wildcards SSP issues John Levine
- Re: [ietf-dkim] TXT wildcards SSP issues Steve Atkins
- Re: [ietf-dkim] SSP issues Douglas Otis
- Re: [ietf-dkim] TXT wildcards SSP issues william(at)elan.net
- Re: [ietf-dkim] TXT wildcards SSP issues John Levine
- RE: [ietf-dkim] SSP issues Hallam-Baker, Phillip
- RE: [ietf-dkim] SSP issues Hallam-Baker, Phillip
- RE: [ietf-dkim] SSP issues Hallam-Baker, Phillip
- RE: [ietf-dkim] TXT wildcards SSP issues Hallam-Baker, Phillip
- MX dot RE: [ietf-dkim] TXT wildcards SSP issues Hallam-Baker, Phillip
- Re: MX dot RE: [ietf-dkim] TXT wildcards SSP issu… Steve Atkins
- RE: MX dot RE: [ietf-dkim] TXT wildcards SSP issu… Hallam-Baker, Phillip
- Re: [ietf-dkim] TXT wildcards SSP issues Scott Kitterman
- MX dot was (Re: [ietf-dkim] TXT wildcards SSP iss… Steve Atkins
- Re: [ietf-dkim] TXT wildcards SSP issues Douglas Otis
- Re: [ietf-dkim] TXT wildcards SSP issues Scott Kitterman
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Scott Kitterman
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Eliot Lear
- Re: [ietf-dkim] TXT wildcards SSP issues Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Steve Atkins
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Scott Kitterman
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Stephen Farrell
- Re: [ietf-dkim] SSP issues Steve Atkins
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Charles Lindsey
- RE: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hallam-Baker, Phillip
- Re: [ietf-dkim] Re: Single Organization TXT Looku… Damon
- Re: [ietf-dkim] SSP issues Damon
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Michael Thomas
- Re: [ietf-dkim] Re: Single Organization TXT Looku… Douglas Otis
- Re: [ietf-dkim] SSP issues Jim Fenton
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Damon
- Re: [ietf-dkim] SSP issues Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Stephen Farrell
- Re: [ietf-dkim] SSP issues Michael Thomas
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… stephen.farrell
- RE: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Bill.Oxley
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- [ietf-dkim] I think we can punt the hard stuff as… Hallam-Baker, Phillip
- [ietf-dkim] Re: I think we can punt the hard stuf… Michael Thomas
- [ietf-dkim] RE: I think we can punt the hard stuf… Hallam-Baker, Phillip
- [ietf-dkim] Re: I think we can punt the hard stuf… Michael Thomas
- [ietf-dkim] RE: I think we can punt the hard stuf… Hallam-Baker, Phillip
- Re: [ietf-dkim] I think we can punt the hard stuf… Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- [ietf-dkim] Re: I think we can punt the hard stuf… Michael Thomas
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- RE: [ietf-dkim] RE: I think we can punt the hard … Hallam-Baker, Phillip
- Re: [ietf-dkim] SSP issues Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- RE: [ietf-dkim] RE: I think we can punt the hard … Hallam-Baker, Phillip
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- RE: [ietf-dkim] RE: I think we can punt the hard … Hallam-Baker, Phillip
- Re: [ietf-dkim] RE: I think we can punt the hard … Stephen Farrell
- Re: [ietf-dkim] RE: I think we can punt the hard … Stephen Farrell
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- RE: [ietf-dkim] RE: I think we can punt the hard … Bill.Oxley
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Damon
- RE: [ietf-dkim] RE: I think we can punt the hard … Hallam-Baker, Phillip
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- RE: [ietf-dkim] RE: I think we can punt the hard … Hallam-Baker, Phillip
- RE: [ietf-dkim] RE: I think we can punt the hard … Bill.Oxley
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Charles Lindsey
- Re: [ietf-dkim] RE: I think we can punt the hard … Stephen Farrell
- RE: [ietf-dkim] RE: I think we can punt the hard … Bill.Oxley
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Damon
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- [ietf-dkim] lets add one more shall we? Bill.Oxley
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Stephen Farrell
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] lets add one more shall we? Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Stephen Farrell
- Re: [ietf-dkim] lets add one more shall we? Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Stephen Farrell
- RE: [ietf-dkim] RE: I think we can punt the hard … Hallam-Baker, Phillip
- [ietf-dkim] "I sign everything" != "No mail" Michael Thomas
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Jon Callas
- [ietf-dkim] SSP DOMAIN Discovery Relationship to … Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Steve Atkins
- RE: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Bill.Oxley
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Damon
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Michael Thomas
- Re: [ietf-dkim] lets add one more shall we? Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Steve Atkins
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Jon Callas
- Re: [ietf-dkim] RE: I think we can punt the hard … Jim Fenton
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Jim Fenton
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: [ietf-dkim] lets add one more shall we? Charles Lindsey
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: [ietf-dkim] lets add one more shall we? Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Jim Fenton
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… william(at)elan.net
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Damon
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Steve Atkins
- [ietf-dkim] Zone Files Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Jim Fenton
- Re: [ietf-dkim] lets add one more shall we? Charles Lindsey
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Jon Callas
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Jon Callas
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- Re: [ietf-dkim] Zone Files Charles Lindsey
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Wietse Venema
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- RE: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Bill.Oxley
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: [ietf-dkim] Zone Files Hector Santos
- Re: [ietf-dkim] Zone Files william(at)elan.net
- Re: [ietf-dkim] Zone Files Steve Atkins
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… J.D. Falk
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… SM
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- RE: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Patrick Peterson
- RE: [ietf-dkim] RE: I think we can punt the hard … Patrick Peterson
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Jim Fenton
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard … Jim Fenton
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … John Levine
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Wietse Venema
- Re: [ietf-dkim] RE: I think we can punt the hard … Douglas Otis
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… John Levine
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Hector Santos
- Re: [ietf-dkim] lets add one more shall we? Jeff Macdonald
- Re: [ietf-dkim] RE: I think we can punt the hard … Jeff Macdonald
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard … Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard … John L
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Douglas Otis
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Jim Fenton
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: [ietf-dkim] RE: I think we can punt the hard … Hector Santos
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Steve Atkins
- Re: MX dot was (Re: [ietf-dkim] TXT wildcards SSP… Douglas Otis