From ietf-dkim-bounces@mipassoc.org Fri Sep 07 14:46:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITiqp-0007Xk-Ny for ietf-dkim-archive@lists.ietf.org; Fri, 07 Sep 2007 14:46:43 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITiqo-0000XQ-EG for ietf-dkim-archive@lists.ietf.org; Fri, 07 Sep 2007 14:46:43 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l87Igd51014346; Fri, 7 Sep 2007 11:43:03 -0700 Received: from ns0.neustar.com (ns0.neustar.com [156.154.16.158]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l87IgZkm014341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Sep 2007 11:42:35 -0700 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C429F328CD; Fri, 7 Sep 2007 18:42:48 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ITin2-0000wq-Mo; Fri, 07 Sep 2007 14:42:48 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Fri, 07 Sep 2007 14:42:48 -0400 Cc: Internet Architecture Board , dkim mailing list , dkim chair , RFC Editor Subject: [ietf-dkim] Document Action: 'Requirements for a DKIM Signing Practices Protocol' to Informational RFC X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb The IESG has approved the following document: - 'Requirements for a DKIM Signing Practices Protocol ' as an Informational RFC This document is the product of the Domain Keys Identified Mail Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-requirements-05.txt Technical Summary DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisified (MUST), and those that are highly desirable (SHOULD). Working Group Summary This document serves as the roadmap for the development of the DKIM signing practices protocol specification. The working group made a strong effort to separate core requirements for an SSP protocol from any functionality where reasonable alternatives could be identified. WG consensus solidly supports the requirments specified in this document, although some members felt additional requirements should added. Protocol Quality Tim Polk reviewed this specification for the IESG. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Sep 07 23:30:11 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITr1P-0005Gb-MM for ietf-dkim-archive@lists.ietf.org; Fri, 07 Sep 2007 23:30:11 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITr1O-0004xp-7z for ietf-dkim-archive@lists.ietf.org; Fri, 07 Sep 2007 23:30:11 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l883SIw4032704; Fri, 7 Sep 2007 20:28:25 -0700 Received: from mail.123aspx.com (www.123aspx.com [64.85.16.245]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l883SG4L032687 for ; Fri, 7 Sep 2007 20:28:16 -0700 Received: from amh-bb-dynamic-pppoe8-29.dsl.airstreamcomm.net [208.157.184.30] by mail.123aspx.com with SMTP; Fri, 7 Sep 2007 21:15:23 -0700 Message-ID: <01a601c7f1c8$375885d0$0301a8c0@test93> From: "dave" To: Date: Fri, 7 Sep 2007 22:27:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [ietf-dkim] domain keys, the h tag, and the reflector at sendmail.net X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Hi, (If this isn't the right list, please let me know where I can ask this question) As an educational experiance, I'm writing my own domain keys signer. I'm using the reflector at sendmail ( sa-test[at]sendmail.net ) for testing. Everything is working fine, except when I try to use the "h" tag. Then my domain-keys signature fails as BAD. I'm going off of the spec: draft-delany-domainkeys-base-06, which I believe is the latest spec for domain keys. I hope I'm asking the right questions here, so, feel free to ask for clarification. It's my understanding that I use only the headers that are listed in the "h" tag, and sign as if those were the only headers that existed. for example, let's say I use the email sample found in the base-06 spec. It has the following headers (hopefully this doesn't wrap too bad): ------------ Start Sample -------- From: "Joe SixPack" To: "Suzie Q" Subject: Is dinner ready? Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) Message-ID: <20030712040037.46341.5F8J@football.example.com> [body goes here] ------------ End Sample -------- If the "h" tag is created like: h="subject:from"; It's my understanding that I would actually sign this content: ------------ Start Sample -------- Subject: Is dinner ready? From: "Joe SixPack" [body goes here] ------------ End Sample -------- Is that correct? In other words, I concatonate the "subject" and "from" headers (in that order), add my blank line, and then the body. I then sign that combination. Thanks! Dave _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Tue Sep 11 17:22:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IVDBS-0007jq-MD for ietf-dkim-archive@lists.ietf.org; Tue, 11 Sep 2007 17:22:10 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IVDBR-0007Yy-8A for ietf-dkim-archive@lists.ietf.org; Tue, 11 Sep 2007 17:22:10 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8BLJIfc031652; Tue, 11 Sep 2007 14:19:38 -0700 Received: from knecht.neophilic.com (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8BLJGSF031635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Sep 2007 14:19:17 -0700 Received: from [10.0.2.3] (natted.sendmail.com [63.211.143.38]) by knecht.neophilic.com (8.14.1/8.13.6) with ESMTP id l8BLJA6r039405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 11 Sep 2007 14:19:10 -0700 (PDT) (envelope-from eric+dkim@sendmail.org) Date: Tue, 11 Sep 2007 14:19:08 -0700 From: Eric Allman To: dave Subject: Re: [ietf-dkim] domain keys, the h tag, and the reflector at sendmail.net Message-ID: <4FC93F48C3E4DF5213AE0BD7@irma.neophilic.com> In-Reply-To: <01a601c7f1c8$375885d0$0301a8c0@test93> References: <01a601c7f1c8$375885d0$0301a8c0@test93> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-2.3 required=4.0 tests=ALL_TRUSTED,BAYES_00, DATE_IN_FUTURE_48_96 autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on knecht.neophilic.com 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Since no one else seems to want to bite, I will.... --On September 7, 2007 10:27:40 PM -0500 dave wrote: > Hi, > (If this isn't the right list, please let me know where I can ask > this question) Well, this really isn't the right list, since DomainKeys and DKIM are not the same thing (although they are closely related). At this point I would recommend you be implementing DKIM rather than DK. That seems to be the direction the industry is going. > As an educational experiance, I'm writing my own domain keys > signer. I'm using the reflector at sendmail ( > sa-test[at]sendmail.net ) for testing. Everything is working fine, > except when I try to use the "h" tag. Then my domain-keys signature > fails as BAD. I'm going off of the spec: > draft-delany-domainkeys-base-06, which I believe is the latest spec > for domain keys. Actually RFC 4870 is as close as it gets to an official version. > I hope I'm asking the right questions here, so, feel free to ask for > clarification. > > It's my understanding that I use only the headers that are listed > in the "h" tag, and sign as if those were the only headers that > existed. Based on my recollection, that is correct. It is definitely true in DKIM. > for example, let's say I use the email sample found in the base-06 > spec. It has the following headers (hopefully this doesn't wrap too > bad): > > ------------ Start Sample -------- > From: "Joe SixPack" > To: "Suzie Q" > Subject: Is dinner ready? > Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) > Message-ID: <20030712040037.46341.5F8J@football.example.com> > > [body goes here] > ------------ End Sample -------- > > If the "h" tag is created like: > > h="subject:from"; > > It's my understanding that I would actually sign this content: > ------------ Start Sample -------- > Subject: Is dinner ready? > From: "Joe SixPack" > > [body goes here] > ------------ End Sample -------- > > Is that correct? In other words, I concatonate the "subject" and > "from" headers (in that order), add my blank line, and then the > body. I then sign that combination. It looks like that's correct based on a (very quick) scan of RFC 4870. eric _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Mon Sep 17 18:03:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXOh9-0006ri-UD for ietf-dkim-archive@lists.ietf.org; Mon, 17 Sep 2007 18:03:56 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IXOh0-0002cx-Kk for ietf-dkim-archive@lists.ietf.org; Mon, 17 Sep 2007 18:03:52 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8HLxnKY017488; Mon, 17 Sep 2007 15:00:09 -0700 Received: from ns4.neustar.com (ns4.neustar.com [156.154.24.139]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8HLxllW017476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Sep 2007 14:59:47 -0700 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0A3B22AC3F; Mon, 17 Sep 2007 22:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IXOdN-0000nR-PG; Mon, 17 Sep 2007 18:00:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 17 Sep 2007 18:00:01 -0400 Cc: ietf-dkim@mipassoc.org Subject: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-01.txt X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : DKIM Sender Signing Practices Author(s) : E. Allman, et al. Filename : draft-ietf-dkim-ssp-01.txt Pages : 18 Date : 2007-09-17 DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in [RFC4871]. This document describes the records that senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dkim-ssp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dkim-ssp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-09-17175915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dkim-ssp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dkim-ssp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-09-17175915.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html --NextPart-- From ietf-dkim-bounces@mipassoc.org Sat Sep 22 21:01:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZFqv-0004HS-Km for ietf-dkim-archive@lists.ietf.org; Sat, 22 Sep 2007 21:01:41 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZFqm-0004OZ-6u for ietf-dkim-archive@lists.ietf.org; Sat, 22 Sep 2007 21:01:38 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8N0ucKN026934; Sat, 22 Sep 2007 17:56:50 -0700 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8N0uX6Y026931 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 22 Sep 2007 17:56:35 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZFlz-0000Cc-5y for ietf-dkim@mipassoc.org; Sun, 23 Sep 2007 00:56:35 +0000 Received: from 1cust43.tnt3.hbg2.deu.da.uu.net ([149.225.14.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Sep 2007 00:56:35 +0000 Received: from nobody by 1cust43.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Sep 2007 00:56:35 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-dkim@mipassoc.org From: "Frank Ellermann" Date: Sun, 23 Sep 2007 02:56:13 +0200 Organization: http://purl.net/xyzzy Lines: 31 Message-ID: References: <468ED9B3.8070602@dcrocker.net> <200707071705.48160.ietf-dkim@kitterman.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Subject: [ietf-dkim] Re: DKIM signature can mean it's safe to generate bounce? X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Scott Kitterman wrote ten weeks ago: > On Friday 06 July 2007 20:09, Dave Crocker wrote: >> It seems to me that if a message has a DKIM signature and the signing >> domain matches the domain in the rfc2821.MailFrom command, then it is >> safe to generate a bounce message to that address. >> By 'safe' I mean that one can be confident that the mail will not go >> to an unwitting victim of a spoofed address. [...] > I expect if limited to the case where 2821 Mail From domain is the=20 > same as the signing domain it would likely be reasonably effective. =20 > SPF Pass would (if available) give you the same or better confidence. Better because you'd already have this confidence after SMTP MAIL FROM without DKIM crypto looking at the 2822 header. SPF also allows to aggregate more than one "sending provider", that's rather tricky with DKIM or BATV.=20 OTOH you'd never see an SPF PASS behind "taditional" (aka "broken by 1123 5.3.6a") forwarding, where Dave's approach based on DKIM would still work. The scenarios aren't equivalent, Dave's method is more or less limited to cases starting out with 2822-From =3D MAIL FROM, but after that it survives forwarding. =20 If a mailing list manages to invalidate the DKIM signature Dave's approach won't work. But the list could very easily guarantee it's own SPF PASS, so in practice receivers can handle most sound cases. Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Sep 22 21:42:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IZGUQ-0006Of-Gv for ietf-dkim-archive@lists.ietf.org; Sat, 22 Sep 2007 21:42:30 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IZGUP-00059Z-81 for ietf-dkim-archive@lists.ietf.org; Sat, 22 Sep 2007 21:42:30 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8N1d9Gk004510; Sat, 22 Sep 2007 18:39:09 -0700 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8N1d50T004491 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 22 Sep 2007 18:39:07 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1IZGRJ-00054w-IS for ietf-dkim@mipassoc.org; Sun, 23 Sep 2007 01:39:17 +0000 Received: from 1cust43.tnt3.hbg2.deu.da.uu.net ([149.225.14.43]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Sep 2007 01:39:17 +0000 Received: from nobody by 1cust43.tnt3.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Sep 2007 01:39:17 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-dkim@mipassoc.org From: "Frank Ellermann" Date: Sun, 23 Sep 2007 03:38:56 +0200 Organization: http://purl.net/xyzzy Lines: 28 Message-ID: References: <46A76413.6060206@altn.com> <77442E31-D9F3-4961-B54B-C0296B9E536A@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust43.tnt3.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Cc: ietf-smtp@imc.org Subject: [ietf-dkim] Re: Thoughts on latest SSP draft X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Douglas Otis wrote (2007-07-25 on the DKIM list): > At this point in time, it should be rather rare for incoming SMTP =20 > servers to depended upon a AAAA record for locating their servers. =20 > The DKIM WG should push to have A or AAAA record discovery =20 > deprecated. Deprecating address record discovery techniques will =20 > eventually simplify where policy needs to be published. At some =20 > point in the future, not publishing an MX record for the originating =20 > domain might cause a message to be rejected. Hi, scanning old messages I saw that you said this more than once on the DKIM mailing list. I'm also aware that Meng Weng Wong and others proposed something in this direction on the SPF and MARID list back in 2004. It's also related to the expired "null-MX" I-D, and because of that it might affect various "NOMAIL" solutions (4408 "v=3Dspf1 -all" and Phil's I-D.hallambaker-nomail). I'm not strictly against it, quite the contrary. *But* AFAIK it's not planned to remove the "A fallback" from 2821bis, in fact 2821bis will augment all discussions of A records with AAAA for IPv6 compatibility. If you and others feel that the no-MX fallback should be limited to IPv4 in 2821bis, as it arguably is in 2821, then please say so on the SMTP list. Fixing the SMTP spec. for IPv6-only senders is something between tricky and impossible, and your proposal could shift this task from impossible towards tricky. Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Wed Sep 26 18:40:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IafYG-0000Hf-VR for ietf-dkim-archive@lists.ietf.org; Wed, 26 Sep 2007 18:40:16 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IafY7-0002mu-G7 for ietf-dkim-archive@lists.ietf.org; Wed, 26 Sep 2007 18:40:13 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8QMVZEY021414; Wed, 26 Sep 2007 15:31:45 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8QMVX3w021408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 15:31:33 -0700 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) by harry.mail-abuse.org (Postfix) with ESMTP id D0208414D6; Wed, 26 Sep 2007 15:31:42 -0700 (PDT) In-Reply-To: References: <46A76413.6060206@altn.com> <77442E31-D9F3-4961-B54B-C0296B9E536A@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06344C5B-8C7D-408C-A795-FD1580837729@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] Re: Thoughts on latest SSP draft Date: Wed, 26 Sep 2007 15:31:42 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) Cc: ietf-dkim@mipassoc.org, ietf-smtp@imc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 On Sep 22, 2007, at 6:38 PM, Frank Ellermann wrote: > Douglas Otis wrote (2007-07-25 on the DKIM list): > >> At this point in time, it should be rather rare for incoming SMTP >> servers to depended upon a AAAA record for locating their servers. >> The DKIM WG should push to have A or AAAA record discovery >> deprecated. Deprecating address record discovery techniques will >> eventually simplify where policy needs to be published. At some >> point in the future, not publishing an MX record for the >> originating domain might cause a message to be rejected. > > Hi, scanning old messages I saw that you said this more than once > on the DKIM mailing list. I'm also aware that Meng Weng Wong and > others proposed something in this direction on the SPF and MARID > list back in 2004. It's also related to the expired "null-MX" I-D, > and because of that it might affect various "NOMAIL" solutions > (4408 "v=spf1 -all" and Phil's I-D.hallambaker-nomail). Email policy solutions assume policy can be asserted for parent domains and all sub-domains. This is done with DNS wildcard records, by walking some portion of the DNS tree, or checking for discovery records. Any existing node within DNS prevents synthesis of a DNS wildcard policy record. As such, either the domain tree must be walked, a policy record needs to be published at every existing node, or at every possible discovery record. Publishing a policy record adjacent every existing node will be difficult to manage. Walking even a small portion of the label tree might negatively impact SLD and TLDs. The level of impact would depend upon consistency of the implementation of the negative caching of the missing address record transactions. Some domains disable negative caching for faster transient error recovery. > I'm not strictly against it, quite the contrary. *But* AFAIK it's > not planned to remove the "A fallback" from 2821bis, in fact > 2821bis will augment all discussions of A records with AAAA for > IPv6 compatibility. AAAA record discovery could be excluded in 2821bis and require the use of MX records. One solution for resolving whether email policy might apply can then be validated by discovering an MX record. At some point, even A records for discovery should be deprecated. The presences of address records should not necessitate the publishing email policy. > If you and others feel that the no-MX fallback should be limited to > IPv4 in 2821bis, as it arguably is in 2821, then please say so on > the SMTP list. Fixing the SMTP spec. for IPv6-only senders is > something between tricky and impossible, and your proposal could > shift this task from impossible towards tricky. The impact of the deprecation would not cause discovery to fail, as A records could still be used. The impact would likely be felt when acceptance of a message fails due to the lack of an MX record. Systems sending diagnostic messages within an organization might be white-listed to alleviate the publishing of an MX record. Often, these systems are not intended to communicate with some random set of domains. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Wed Sep 26 18:58:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iafq2-0004u7-Kd for ietf-dkim-archive@lists.ietf.org; Wed, 26 Sep 2007 18:58:38 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iafpw-0003DB-Ky for ietf-dkim-archive@lists.ietf.org; Wed, 26 Sep 2007 18:58:38 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8QMvAtM026088; Wed, 26 Sep 2007 15:57:11 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8QMv8Pm026080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Sep 2007 15:57:08 -0700 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) by harry.mail-abuse.org (Postfix) with ESMTP id AE6D44143D; Wed, 26 Sep 2007 15:57:24 -0700 (PDT) In-Reply-To: References: <468ED9B3.8070602@dcrocker.net> <200707071705.48160.ietf-dkim@kitterman.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <381F4199-B5AE-4755-A8D3-A951F49D77D8@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] Re: DKIM signature can mean it's safe to generate bounce? Date: Wed, 26 Sep 2007 15:57:23 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 On Sep 22, 2007, at 5:56 PM, Frank Ellermann wrote: > Scott Kitterman wrote ten weeks ago: > >> On Friday 06 July 2007 20:09, Dave Crocker wrote: >>> It seems to me that if a message has a DKIM signature and the >>> signing domain matches the domain in the rfc2821.MailFrom >>> command, then it is safe to generate a bounce message to that >>> address. > >>> By 'safe' I mean that one can be confident that the mail will not >>> go to an unwitting victim of a spoofed address. > [...] >> I expect if limited to the case where 2821 Mail From domain is the >> same as the signing domain it would likely be reasonably effective. > >> SPF Pass would (if available) give you the same or better confidence. > > Better because you'd already have this confidence after SMTP MAIL > FROM without DKIM crypto looking at the 2822 header. SPF also > allows to aggregate more than one "sending provider", that's rather > tricky with DKIM or BATV. This can be done with DKIM using a strategy that can bridge policy domains. See: http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt Unlike SPF, the tpa-ssp method scales without invoking hundreds of DNS transactions. This draft extends the current SSP draft. > OTOH you'd never see an SPF PASS behind "taditional" (aka "broken > by 1123 5.3.6a") forwarding, where Dave's approach based on DKIM > would still work. The scenarios aren't equivalent, Dave's method > is more or less limited to cases starting out with 2822-From = MAIL > FROM, but after that it survives forwarding. > > If a mailing list manages to invalidate the DKIM signature Dave's > approach won't work. But the list could very easily guarantee it's > own SPF PASS, so in practice receivers can handle most sound cases. The use of the From is sure to create problems for mailing-lists. As with SPF, SSP also lacks policy scope which is unfortunate. This could be repaired by extending SSP policy with drafts like TPA. Unfortunately, these extensions are unlikely to be incorporated and more convoluted work-arounds will likely be used. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Sep 27 04:45:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaozg-00063M-7I for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 04:45:12 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaozZ-0007OG-OT for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 04:45:12 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8R8gPPY015539; Thu, 27 Sep 2007 01:42:26 -0700 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8R8gK7R015520 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 27 Sep 2007 01:42:23 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iaow2-0007me-UC for ietf-dkim@mipassoc.org; Thu, 27 Sep 2007 08:41:26 +0000 Received: from 1cust147.tnt2.hbg2.deu.da.uu.net ([149.225.12.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 08:41:26 +0000 Received: from nobody by 1cust147.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 08:41:26 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-dkim@mipassoc.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 10:38:56 +0200 Organization: http://purl.net/xyzzy Lines: 83 Message-ID: References: <46A76413.6060206@altn.com><77442E31-D9F3-4961-B54B-C0296B9E536A@mail-abuse.org> <06344C5B-8C7D-408C-A795-FD1580837729@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust147.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Cc: ietf-smtp@imc.org Subject: [ietf-dkim] 2821bis and AAAA (was: Thoughts on latest SSP draft) X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Douglas Otis wrote: > Email policy solutions assume policy can be asserted for parent =20 > domains and all sub-domains. Not for SPF, and it took me some time to figure this out in 2004: A receiver getting mail with an alleged evelope sender x@y.example can reject it as soon as it's clear that there's no MX, no A, and no AAAA for y.example. Zone cuts, DNS tree walks, or SPF aren't needed for this decision. Email policy solutions like SPF don't need to worry about "impossible" sub-domains, the receicers are anyway obliged to reject mail from an "impossible" x@y.example at least temporarily, otherwise they couldn't report later errors. In theory they could accept it if they're sure that there will be no problem with final delivery, and that triggered auto responses going to /dev/null are no issue, but that's already deep in the territory of "receiver policies". Sender policies can focus on domains with an MX, plus A or AAAA cases for domains without MX. They don't need to cover complete subtrees. If the MX or A / AAAA is a wildcard the corresponding policy also needs to be a wildcard. =20 > a policy record needs to be published at every existing node For some definitions of "existing" by "has MX, A, or AAAA", yes. OTOH receivers could check that the A / AAAA without MX cases have an SMTP listening on port 25, and otherwise decide that an alleged envelope sender address isn't acceptable for the purpose of sending later error reports to the originator "as indicated by the reverse path", the keystone of SMTP. This check might be simpler than trying to find and interprete sender policies, and the A / AAAA without MX cases should be rare. > Publishing a policy record adjacent every existing node will > be difficult to manage. It depends on what you want. If you never use any @www.example address in email, and there's no MX for or SMTP at www.example, you could decide that's good enough. An admin for bank.example likely decides that www.bank.example has to be covered. > Walking even a small portion of the label tree might negatively > impact SLD and TLDs. Yes, tree walks are odd when they cross zone cuts, that's not limited to TLDs and SLDs like ac.uk. >> AFAIK it's not planned to remove the "A fallback" from 2821bis, >> in fact 2821bis will augment all discussions of A records with >> AAAA for IPv6 compatibility. =20 > AAAA record discovery could be excluded in 2821bis and require > the use of MX records. Okay, for that section 2.3.5 at the moment offers: | Only resolvable, fully-qualified, domain names (FQDNs) are=20 | permitted when domain names are used in SMTP. In other words, | names that can be resolved to MX RRs or address (i.e. A or=20 | AAAA) RRs (as discussed in Section 5) are permitted, as are | CNAME RRs whose targets can be resolved, in turn, to MX or=20 | address RRs.=20 For your proposal it should say ..."MX RRs or IPv4 addresses (i.e. A) are permitted"..."resolved, in turn, to MX or IPv4 address RRs." And the details in section 5 would have to fixed, limiting the "no-MX" procedure to the legacy IPv4 case, plus something about IPv4 addresses as they're seen in an IPv6 environment. > At some point, even A records for discovery should be=20 > deprecated. I'm pretty sure that the 2821bis author would insist on saying that this point isn't *now*. But for IPv6 (and any IPvFuture) there might be enough wiggle room. Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Sep 27 05:43:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iaptm-0006Wj-Gp for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 05:43:10 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iaptl-0000a2-7r for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 05:43:10 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8R9eUS0028660; Thu, 27 Sep 2007 02:40:30 -0700 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8R9eR8C028654 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 27 Sep 2007 02:40:29 -0700 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Iapq7-0006UJ-5d for ietf-dkim@mipassoc.org; Thu, 27 Sep 2007 09:39:23 +0000 Received: from 1cust147.tnt2.hbg2.deu.da.uu.net ([149.225.12.147]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 09:39:23 +0000 Received: from nobody by 1cust147.tnt2.hbg2.deu.da.uu.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 27 Sep 2007 09:39:23 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-dkim@mipassoc.org From: "Frank Ellermann" Date: Thu, 27 Sep 2007 11:36:32 +0200 Organization: http://purl.net/xyzzy Lines: 36 Message-ID: References: <468ED9B3.8070602@dcrocker.net><200707071705.48160.ietf-dkim@kitterman.com> <381F4199-B5AE-4755-A8D3-A951F49D77D8@mail-abuse.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 1cust147.tnt2.hbg2.deu.da.uu.net X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Subject: [ietf-dkim] TPA-SSP (was: DKIM signature can mean it's safe to generate bounce?) X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Douglas Otis wrote: =20 > See: http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt Oops, I didn't know this style of URL, Henrik's tools are amazing. =20 > Unlike SPF, the tpa-ssp method scales without invoking hundreds > of DNS transactions. This draft extends the current SSP draft. As always "hundreds" is nonsense. Minor nit, maybe s/*FWS/[FWS]/g in your draft, I think you never want more than one FWS in a row. Please add some examples, I almost missed the point where you're=20 using the base32( sha-1( lcase( signing-domain ))) construct. Let's say mail "from" (one or more of your scopes) domain.example is sent via third party signers isp1.example and isp2.example, what are those signers and later receivers supposed to do, and when is whatever they do okay from the POV of domain.example ? > The use of the From is sure to create problems for mailing-lists. > As with SPF, SSP also lacks policy scope which is unfortunate. For SPF in the sense of v=3Dspf1 it's fine, it's limited to SMTP, HELO + MAIL FROM need no complex scopes. The PRA and 4405 cases are also clear if publishers stay away from %h (HELO) macros in their PRA policies. You only run into problems when you're talking about something=20 like 2822-From, neither PRA nor envelope sender. BTW, I think you could replace your "O" by PRA with a reference to RFC 4407. If there's one thing we don't need it's "yet another definition of 'originator'". Frank _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Sep 27 15:14:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IayoX-0003ka-Hj for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 15:14:21 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IayoR-0008Dj-5t for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 15:14:21 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RJC0DO032647; Thu, 27 Sep 2007 12:12:09 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RJBwFS032633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Sep 2007 12:11:58 -0700 Received: from [10.2.164.149] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) by harry.mail-abuse.org (Postfix) with ESMTP id 4E8474159A; Thu, 27 Sep 2007 12:12:14 -0700 (PDT) In-Reply-To: References: <46A76413.6060206@altn.com><77442E31-D9F3-4961-B54B-C0296B9E536A@mail-abuse.org> <06344C5B-8C7D-408C-A795-FD1580837729@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1C74B638-4926-4A1F-AA56-36D7D6AB837E@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] 2821bis and AAAA (was: Thoughts on latest SSP draft) Date: Thu, 27 Sep 2007 12:12:13 -0700 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) Cc: ietf-dkim@mipassoc.org, ietf-smtp@imc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 On Sep 27, 2007, at 1:38 AM, Frank Ellermann wrote: > Douglas Otis wrote: > >> Email policy solutions assume policy can be asserted for parent >> domains and all sub-domains. > > Not for SPF, and it took me some time to figure this out in 2004: > > A receiver getting mail with an alleged evelope sender x@y.example > can reject it as soon as it's clear that there's no MX, no A, and > no AAAA for y.example. Zone cuts, DNS tree walks, or SPF aren't > needed for this decision. Email policy solutions like SPF don't > need to worry about "impossible" sub-domains, the receicers are > anyway obliged to reject mail from an "impossible" x@y.example at > least temporarily, otherwise they couldn't report later errors. Increasing levels of spam is requiring receivers to add resources. Additional transactions for random domains will amplify the need for additional resources. In addition to checking for a policy record of some sort, A, AAAA, and MX records must also be queried. Every message referencing a randomly spoofed domain will thereby lead to a series of expensive DNS transactions. DNS overhead could be reduced by 2/3 thirds at least by requiring an MX record for acceptance. This would preclude A or AAAA record for acceptance. The impact of this change should be limited to message acceptance. >> a policy record needs to be published at every existing node > > For some definitions of "existing" by "has MX, A, or AAAA", yes. > > OTOH receivers could check that the A / AAAA without MX cases have > an SMTP listening on port 25, and otherwise decide that an alleged > envelope sender address isn't acceptable for the purpose of sending > later error reports to the originator "as indicated by the reverse > path", the keystone of SMTP. This check might be simpler than > trying to find and interprete sender policies, and the A / AAAA > without MX cases should be rare. Attempting to also connect to an SMTP server would also require receivers to increase resources. To limit the impact of this increase, specialized caching would be needed. Unlike DNS, each SMTP connection requires TCP setup. Many of the inbound systems are overloaded with spam, where without retries, a failure to connect will reduce email's delivery integrity. In addition, inbound connections should be held during this process. >> Publishing a policy record adjacent every existing node will be >> difficult to manage. > > It depends on what you want. If you never use any @www.example > address in email, and there's no MX for or SMTP at www.example, you > could decide that's good enough. An admin for bank.example likely > decides that www.bank.example has to be covered. The goal would be to limit spoofing. This requires every address record to have an adjacent policy record that indicates this address record is not used for email. Policy records of every sort would need to be published adjacent to each address record. Cluttering zones with email policy records is sub-optimal. This problem is best resolved by requiring MX records. >> Walking even a small portion of the label tree might negatively >> impact SLD and TLDs. > > Yes, tree walks are odd when they cross zone cuts, that's not > limited to TLDs and SLDs like ac.uk. Currently checking for MX, A, and AAAA records would be required to avoid tree walking. >>> AFAIK it's not planned to remove the "A fallback" from 2821bis, >>> in fact 2821bis will augment all discussions of A records with >>> AAAA for IPv6 compatibility. > >> AAAA record discovery could be excluded in 2821bis and require the >> use of MX records. > > Okay, for that section 2.3.5 at the moment offers: > > | Only resolvable, fully-qualified, domain names (FQDNs) are > | permitted when domain names are used in SMTP. In other words, > | names that can be resolved to MX RRs or address (i.e. A or > | AAAA) RRs (as discussed in Section 5) are permitted, as are > | CNAME RRs whose targets can be resolved, in turn, to MX or > | address RRs. > > For your proposal it should say ..."MX RRs or IPv4 addresses (i.e. > A) are permitted"..."resolved, in turn, to MX or IPv4 address RRs." At least. It would be nice to obtain enough consensus that would allow use of A records to hereby be deprecated. I suspect this must be done in a separate draft, or by de-facto behaviour. > And the details in section 5 would have to fixed, limiting the "no- > MX" procedure to the legacy IPv4 case, plus something about IPv4 > addresses as they're seen in an IPv6 environment. That would still demand an inordinate level of policy records. >> At some point, even A records for discovery should be deprecated. > > I'm pretty sure that the 2821bis author would insist on saying that > this point isn't *now*. But for IPv6 (and any IPvFuture) there > might be enough wiggle room. I agree. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Sep 27 18:21:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib1jn-0007rF-T2 for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:21:39 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib1jh-00040a-KM for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:21:39 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMJoLQ002948; Thu, 27 Sep 2007 15:19:58 -0700 Received: from ns1.qubic.net (ns1.qubic.net [208.185.248.67]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMJnNF002942 for ; Thu, 27 Sep 2007 15:19:49 -0700 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.2.Alpha0/8.14.2.Alpha0) with ESMTP id l8RMJXST028038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 15:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1190931590; x=1191017990; bh=OcPu6M+7vOKoLGWehkkd+/qZgnZNVdYCfkov c/wfFL4=; h=DomainKey-Signature:Message-Id:X-Mailer:Date:To:From: Subject:Cc:Mime-Version:Content-Type; b=qEZaHvJJjD0aUmsDxUskj+ZlPp fzlLcpOqOs6VYv79ulrUMXk6gSAUEHpCH74Gb7/s3OUeZR9lRd1e5JP7oDUXNaCUD3p u6x+kKq3J1gGS+BC989Pq9n/x3iT184zL0BD92qVhI1VVCokBmYRDCffE7IB2YXXYLW lZ6zabLFhbM= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=geaw6yxmgktcCQIuxSNTRDLx8PQHhAUMDImKg4qGviJWtjovup+iy8cyXSqX0duAL 3LJZYyI3ma1vT/Am+1K19oBZiFOou14xir7w0EBUzJ5Qku4010eKmeGhfJqxPzRF8b+ n81MuVvF5/l/tJbpsyAn3S/U5Jq6KFPkbetym8A= Message-Id: <6.2.5.6.2.20070927145025.02f2aea8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 27 Sep 2007 14:52:27 -0700 To: ietf-dkim@mipassoc.org From: SM Subject: Fwd: Re: [ietf-dkim] 2821bis and AAAA (was: Thoughts on latest SSP draft) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: John C Klensin X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c This message has been forwarded to the DKIM list. >Date: Thu, 27 Sep 2007 16:36:04 -0400 >From: John C Klensin > >(someone will probably need to forward this to the DKIM list; >I'm not subscribed to it) > >--On Thursday, 27 September, 2007 12:12 -0700 Douglas Otis > wrote: > > >... > > In addition to checking for a policy record of some sort, A, > > AAAA, and MX records must also be queried. Every message > > referencing a randomly spoofed domain will thereby lead to a > > series of expensive DNS transactions. DNS overhead could be > > reduced by 2/3 thirds at least by requiring an MX record for > > acceptance. This would preclude A or AAAA record for > > acceptance. The impact of this change should be limited to > > message acceptance. > >I think you have the cart and horse turned around backward. If >(and I'm not going to express an opinion at this point), one >really needs MX records if DKIM (and its near and distant >header-signing relatives) are to be supported in a reasonable >and efficient way, then it would be perfectly sensible to impose >that requirement on DKIM users. In other words, one makes >provision, in the DKIM specs, that, > > (i) if one is going to insert DKIM header records, one > MUST have MX records for the appropriate hosts. > > (ii) if one encounters DKIM header records, does an MX > lookup, and does not get one or more MX records back, > then one SHOULD just give up and treat the DKIM records > as trash (whatever that happens to imply). > >This makes the "mandatory MX" issue a DKIM (and friends) issue, >not a requirement that zillions of hosts that do "MX, then >address" lookups consistent with 2821 (and 1123, and...) change >what they are doing because of some proposed words in 2821bis >that change a 20-odd-year-old spec. Won't happen, whether >2821bis is changed or not. > >#include > > john _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Sep 27 18:27:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib1p7-0005v4-Da for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:27:09 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib1p6-00047y-4B for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:27:09 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMPS0j004032; Thu, 27 Sep 2007 15:25:28 -0700 Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMPRRJ004026 for ; Thu, 27 Sep 2007 15:25:27 -0700 X-IronPort-AV: E=Sophos;i="4.21,205,1188802800"; d="scan'208";a="402473189" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 27 Sep 2007 15:25:44 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l8RMPhUM027374 for ; Thu, 27 Sep 2007 15:25:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8RMPhTm013084 for ; Thu, 27 Sep 2007 22:25:43 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, 27 Sep 2007 15:25:42 -0700 Received: from dhcp-171-71-97-219.cisco.com ([171.71.97.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 15:25:42 -0700 Message-ID: <46FC2DE4.5070702@cisco.com> Date: Thu, 27 Sep 2007 15:25:40 -0700 From: Jim Fenton User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: IETF DKIM WG X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 22:25:42.0753 (UTC) FILETIME=[573D1D10:01C80155] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1357; t=1190931943; x=1191795943; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20 |Subject:=20The=20(really)=20latest=20SSP=20draft |Sender:=20; bh=wdnPVDEP1BpwZlx//j2dPL1ClgoOR2ovis6Atq+TBSY=; b=i9reD5cIxevaJjc/30F0J10Mk6EgcJelOhvN6G79Bzlv5vmS0c3s6cpdEba6REVmG4EAtI+k uGIp2oVbg7wSDEjzwN9776EZAtX4qdflcvIMjtaVg1rbUiJD5T+ePWX45Pdukp4qRc/mNn6MQ8 8ahxpy4Wuu6+iCkPeJ/9LK7qM=; Authentication-Results: sj-dkim-1; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [ietf-dkim] The (really) latest SSP draft X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 The list has been uncharacteristically silent since I submitted an update to the SSP draft 10 days ago, so I thought I'd point out the new draft (draft-ietf-dkim-ssp-01) and a few of the highlights (more complete info on the changes are in section B.1). The most significant change is a new tag, called "handling", that represents what I called the SSP "Strong" Option in my presentation at IETF 69. As I mentioned at the time, we needed a better word than "strong", and this is what Eric and I came up with. It takes one of two values: "process", the default, means to do what you would normally do with a message that is Suspicious. "block" is a way for a domain to express the preference that messages violating SSP be dealt with more harshly, such as by deleting, bouncing, or rejecting them. Section 5, "Third-party Signatures and Mailing Lists", has been removed since it belongs better in the Overview document(s). Note to overview authors: hint, hint. Most of the other changes in the document, which are numerous, are to tighten up the wording rather than to introduce anything new or different. For example, when user-granularity SSP was in the document, SSP applied to an "entity" which was either a user or a domain. the word "domain" is sufficient, and clearer, now. Comments appreciated as always! -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Sep 27 18:44:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib26G-0008TZ-0S for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:44:52 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib26B-0004Vo-OA for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:44:48 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMh97h007090; Thu, 27 Sep 2007 15:43:10 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMh8J7007087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 27 Sep 2007 15:43:08 -0700 Received: from mtcc13.mtcc.com (rtp-isp-nat1.cisco.com [64.102.254.33]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l8RMhJ0l006445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 15:43:21 -0700 Message-ID: <46FC323A.4000607@mtcc.com> Date: Thu, 27 Sep 2007 15:44:10 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Jim Fenton References: <46FC2DE4.5070702@cisco.com> In-Reply-To: <46FC2DE4.5070702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); Cc: IETF DKIM WG Subject: [ietf-dkim] Step 9 (was: The (really) latest SSP draft) X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Step 9 of the SSP lookup algorithm sez: 9. If the value of the SSP "dkim" tag is "all", and one or more Verifier Acceptable Third-Party Signatures are present on the message, the message is not Suspicious and the algorithm terminates. I don't see the motivation for this, and it's definitely not in the requirements. A receiver is always completely at liberty to whitelist, blacklist, greylist, pink-polka-dotted-list a third party signature regardless of what the originating domains says. What unique value does a signer bring to an across the board statement about all third party signatures? I can't think of a single use case that I'd alter processing based on that information. Mike Jim Fenton wrote: > The list has been uncharacteristically silent since I submitted an > update to the SSP draft 10 days ago, so I thought I'd point out the new > draft (draft-ietf-dkim-ssp-01) and a few of the highlights (more > complete info on the changes are in section B.1). > > The most significant change is a new tag, called "handling", that > represents what I called the SSP "Strong" Option in my presentation at > IETF 69. As I mentioned at the time, we needed a better word than > "strong", and this is what Eric and I came up with. It takes one of two > values: "process", the default, means to do what you would normally do > with a message that is Suspicious. "block" is a way for a domain to > express the preference that messages violating SSP be dealt with more > harshly, such as by deleting, bouncing, or rejecting them. > > Section 5, "Third-party Signatures and Mailing Lists", has been removed > since it belongs better in the Overview document(s). Note to overview > authors: hint, hint. > > Most of the other changes in the document, which are numerous, are to > tighten up the wording rather than to introduce anything new or > different. For example, when user-granularity SSP was in the document, > SSP applied to an "entity" which was either a user or a domain. the > word "domain" is sufficient, and clearer, now. > > Comments appreciated as always! > > -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 From ietf-dkim-bounces@mipassoc.org Thu Sep 27 18:52:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib2Df-0001RJ-Fv for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:52:31 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib2De-0004gA-73 for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:52:31 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMpNJu008149; Thu, 27 Sep 2007 15:51:23 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMpLYT008146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 27 Sep 2007 15:51:21 -0700 Received: from mtcc13.mtcc.com (rtp-isp-nat1.cisco.com [64.102.254.33]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l8RMpYnf007227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 15:51:37 -0700 Message-ID: <46FC342D.5030009@mtcc.com> Date: Thu, 27 Sep 2007 15:52:29 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Jim Fenton Subject: Step 2 (Re: [ietf-dkim] The (really) latest SSP draft) References: <46FC2DE4.5070702@cisco.com> In-Reply-To: <46FC2DE4.5070702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); Cc: IETF DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Here you mention that "one or more valid SSP records". In later steps (7?) you don't subsequently say which record to choose if there is more than one. I suppose that the first one is as good as any, but it should at least be explicit. Mike Jim Fenton wrote: > The list has been uncharacteristically silent since I submitted an > update to the SSP draft 10 days ago, so I thought I'd point out the new > draft (draft-ietf-dkim-ssp-01) and a few of the highlights (more > complete info on the changes are in section B.1). > > The most significant change is a new tag, called "handling", that > represents what I called the SSP "Strong" Option in my presentation at > IETF 69. As I mentioned at the time, we needed a better word than > "strong", and this is what Eric and I came up with. It takes one of two > values: "process", the default, means to do what you would normally do > with a message that is Suspicious. "block" is a way for a domain to > express the preference that messages violating SSP be dealt with more > harshly, such as by deleting, bouncing, or rejecting them. > > Section 5, "Third-party Signatures and Mailing Lists", has been removed > since it belongs better in the Overview document(s). Note to overview > authors: hint, hint. > > Most of the other changes in the document, which are numerous, are to > tighten up the wording rather than to introduce anything new or > different. For example, when user-granularity SSP was in the document, > SSP applied to an "entity" which was either a user or a domain. the > word "domain" is sufficient, and clearer, now. > > Comments appreciated as always! > > -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 From ietf-dkim-bounces@mipassoc.org Thu Sep 27 18:58:25 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib2JN-0002ND-CF for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:58:25 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib2JJ-0004op-Pl for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 18:58:25 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMvBGN008889; Thu, 27 Sep 2007 15:57:11 -0700 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMvAJU008874 for ; Thu, 27 Sep 2007 15:57:10 -0700 X-IronPort-AV: E=Sophos;i="4.21,205,1188802800"; d="scan'208";a="529035399" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2007 15:57:26 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l8RMvQjr004770; Thu, 27 Sep 2007 15:57:26 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8RMvQTm008037; Thu, 27 Sep 2007 22:57:26 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 15:57:26 -0700 Received: from dhcp-171-71-97-219.cisco.com ([171.71.97.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 15:57:26 -0700 Message-ID: <46FC3554.70305@cisco.com> Date: Thu, 27 Sep 2007 15:57:24 -0700 From: Jim Fenton User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Michael Thomas References: <46FC2DE4.5070702@cisco.com> <46FC323A.4000607@mtcc.com> In-Reply-To: <46FC323A.4000607@mtcc.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 22:57:26.0355 (UTC) FILETIME=[C5DFBA30:01C80159] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2606; t=1190933846; x=1191797846; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20 |Subject:=20Re=3A=20Step=209 |Sender:=20; bh=XNnyQnt2iTANkzED6bzzU81Mw0yIfBUhpYdt7/QzmYU=; b=SVqpJ99jJvA773ZtgWQELYrKwE0XQzN+vi/PRaqT+SLy0ie+K1El8YM6VlpjUr9qPysyJnKP vDmBxFhPcJKIRQwZOIWd+PT8jhM6ciWF6VfuJDiMW7fDdZ3vhMKjqdcQ; Authentication-Results: sj-dkim-2; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IETF DKIM WG Subject: [ietf-dkim] Re: Step 9 X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c The key words here are Verifier Acceptable. The verifier gets to specify which signatures are Verifier Acceptable, which gives it precisely the liberty you describe. -Jim Michael Thomas wrote: > Step 9 of the SSP lookup algorithm sez: > > 9. If the value of the SSP "dkim" tag is "all", and one or more > Verifier Acceptable Third-Party Signatures are present on the > message, the message is not Suspicious and the algorithm > terminates. > > I don't see the motivation for this, and it's definitely not in the > requirements. A > receiver is always completely at liberty to whitelist, blacklist, > greylist, > pink-polka-dotted-list a third party signature regardless of what the > originating > domains says. What unique value does a signer bring to an across the > board > statement about all third party signatures? I can't think of a single > use case that I'd > alter processing based on that information. > > Mike > > > Jim Fenton wrote: >> The list has been uncharacteristically silent since I submitted an >> update to the SSP draft 10 days ago, so I thought I'd point out the new >> draft (draft-ietf-dkim-ssp-01) and a few of the highlights (more >> complete info on the changes are in section B.1). >> >> The most significant change is a new tag, called "handling", that >> represents what I called the SSP "Strong" Option in my presentation at >> IETF 69. As I mentioned at the time, we needed a better word than >> "strong", and this is what Eric and I came up with. It takes one of two >> values: "process", the default, means to do what you would normally do >> with a message that is Suspicious. "block" is a way for a domain to >> express the preference that messages violating SSP be dealt with more >> harshly, such as by deleting, bouncing, or rejecting them. >> >> Section 5, "Third-party Signatures and Mailing Lists", has been removed >> since it belongs better in the Overview document(s). Note to overview >> authors: hint, hint. >> >> Most of the other changes in the document, which are numerous, are to >> tighten up the wording rather than to introduce anything new or >> different. For example, when user-granularity SSP was in the document, >> SSP applied to an "entity" which was either a user or a domain. the >> word "domain" is sufficient, and clearer, now. >> >> Comments appreciated as always! >> >> -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 From ietf-dkim-bounces@mipassoc.org Thu Sep 27 19:00:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib2LV-0007sV-OX for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 19:00:37 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib2LU-0004rO-Eu for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 19:00:37 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMxQ4q009127; Thu, 27 Sep 2007 15:59:26 -0700 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RMxJnj009107 for ; Thu, 27 Sep 2007 15:59:19 -0700 X-IronPort-AV: E=Sophos;i="4.21,205,1188802800"; d="scan'208";a="529036115" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 27 Sep 2007 15:59:35 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l8RMxZmc007350; Thu, 27 Sep 2007 15:59:35 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l8RMxIUE009736; Thu, 27 Sep 2007 22:59:35 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 15:59:34 -0700 Received: from dhcp-171-71-97-219.cisco.com ([171.71.97.219]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Sep 2007 15:59:34 -0700 Message-ID: <46FC35D5.4020501@cisco.com> Date: Thu, 27 Sep 2007 15:59:33 -0700 From: Jim Fenton User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Michael Thomas Subject: Re: Step 2 (Re: [ietf-dkim] The (really) latest SSP draft) References: <46FC2DE4.5070702@cisco.com> <46FC342D.5030009@mtcc.com> In-Reply-To: <46FC342D.5030009@mtcc.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Sep 2007 22:59:34.0622 (UTC) FILETIME=[1253B7E0:01C8015A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=510; t=1190933975; x=1191797975; 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 |Subject:=20Re=3A=20Step=202=20(Re=3A=20[ietf-dkim]=20The=20(really)=20la test=20SSP=20draft) |Sender:=20; bh=aFUXTsT73Us1bB2IqRvYo7bl4Yn6bdsVsBQbP4lqk3U=; b=OLw8widBmg9XSupCOGKpzgAOg4jdt3GFrRrGnqCZ9DUydWVqFN3WKK8Ga6PjIFNgvyMcFcXH vL6zXLlQmEQl9In/F1Rv9oAxQOREo1PB0Zt1UvKTh3kcUiJdwidc2pG1; Authentication-Results: sj-dkim-4; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: IETF DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Agreed. Hence the note immediately before the Table of Contents: > (Unresolved Issues/To Be Done) > > Need to consider handling of multiple responses to a DNS query for > the SSP record. -Jim Michael Thomas wrote: > Here you mention that "one or more valid SSP records". In later steps > (7?) > you don't subsequently say which record to choose if there is more than > one. I suppose that the first one is as good as any, but it should at > least be > explicit. > > Mike > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Sep 27 19:05:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ib2Qf-00038I-8o for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 19:05:57 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ib2Qe-00050l-04 for ietf-dkim-archive@lists.ietf.org; Thu, 27 Sep 2007 19:05:57 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RN4Dvt010199; Thu, 27 Sep 2007 16:04:13 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8RN4CRl010196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 27 Sep 2007 16:04:12 -0700 Received: from mtcc13.mtcc.com (rtp-isp-nat1.cisco.com [64.102.254.33]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l8RN4PjY008549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2007 16:04:27 -0700 Message-ID: <46FC3730.3080004@mtcc.com> Date: Thu, 27 Sep 2007 16:05:20 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Jim Fenton References: <46FC2DE4.5070702@cisco.com> <46FC323A.4000607@mtcc.com> <46FC3554.70305@cisco.com> In-Reply-To: <46FC3554.70305@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); Cc: IETF DKIM WG Subject: [ietf-dkim] Re: Step 9 X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Jim Fenton wrote: > The key words here are Verifier Acceptable. The verifier gets to > specify which signatures are Verifier Acceptable, which gives it > precisely the liberty you describe. > We're not communicating. What might a receiver do differently with a third party signature with and without the "all"? I can't think of anything. Also: there are two orthogonal things going on with "all": the general proposition from the originator that they sign everything, and this third party signature thing. At the very least, they should be decoupled. Mike > -Jim > > Michael Thomas wrote: > >> Step 9 of the SSP lookup algorithm sez: >> >> 9. If the value of the SSP "dkim" tag is "all", and one or more >> Verifier Acceptable Third-Party Signatures are present on the >> message, the message is not Suspicious and the algorithm >> terminates. >> >> I don't see the motivation for this, and it's definitely not in the >> requirements. A >> receiver is always completely at liberty to whitelist, blacklist, >> greylist, >> pink-polka-dotted-list a third party signature regardless of what the >> originating >> domains says. What unique value does a signer bring to an across the >> board >> statement about all third party signatures? I can't think of a single >> use case that I'd >> alter processing based on that information. >> >> Mike >> >> >> Jim Fenton wrote: >> >>> The list has been uncharacteristically silent since I submitted an >>> update to the SSP draft 10 days ago, so I thought I'd point out the new >>> draft (draft-ietf-dkim-ssp-01) and a few of the highlights (more >>> complete info on the changes are in section B.1). >>> >>> The most significant change is a new tag, called "handling", that >>> represents what I called the SSP "Strong" Option in my presentation at >>> IETF 69. As I mentioned at the time, we needed a better word than >>> "strong", and this is what Eric and I came up with. It takes one of two >>> values: "process", the default, means to do what you would normally do >>> with a message that is Suspicious. "block" is a way for a domain to >>> express the preference that messages violating SSP be dealt with more >>> harshly, such as by deleting, bouncing, or rejecting them. >>> >>> Section 5, "Third-party Signatures and Mailing Lists", has been removed >>> since it belongs better in the Overview document(s). Note to overview >>> authors: hint, hint. >>> >>> Most of the other changes in the document, which are numerous, are to >>> tighten up the wording rather than to introduce anything new or >>> different. For example, when user-granularity SSP was in the document, >>> SSP applied to an "entity" which was either a user or a domain. the >>> word "domain" is sufficient, and clearer, now. >>> >>> Comments appreciated as always! >>> >>> -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 From ietf-dkim-bounces@mipassoc.org Fri Sep 28 06:51:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbDRS-00073e-C3 for ietf-dkim-archive@lists.ietf.org; Fri, 28 Sep 2007 06:51:30 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbDRM-0004Od-3l for ietf-dkim-archive@lists.ietf.org; Fri, 28 Sep 2007 06:51:30 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8SAnAkh028468; Fri, 28 Sep 2007 03:49:18 -0700 Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8SAn8SH028436 for ; Fri, 28 Sep 2007 03:49:08 -0700 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id A8D9E6800D; Fri, 28 Sep 2007 11:49:19 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A060D2A4C11; Fri, 28 Sep 2007 11:49:19 +0100 Received: from [127.0.0.1] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 978E46800D; Fri, 28 Sep 2007 11:49:19 +0100 (IST) Message-ID: <46FCDC38.5070000@cs.tcd.ie> Date: Fri, 28 Sep 2007 11:49:28 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jim Fenton Subject: Re: [ietf-dkim] The (really) latest SSP draft References: <46FC2DE4.5070702@cisco.com> In-Reply-To: <46FC2DE4.5070702@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A160D2A4C11 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.57.6 VDF=9.106.10) Cc: IETF DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Jim Fenton wrote: > The most significant change is a new tag, called "handling", that > represents what I called the SSP "Strong" Option in my presentation at > IETF 69. As I mentioned at the time, we needed a better word than > "strong", and this is what Eric and I came up with. It takes one of two > values: "process", the default, means to do what you would normally do > with a message that is Suspicious. "block" is a way for a domain to > express the preference that messages violating SSP be dealt with more > harshly, such as by deleting, bouncing, or rejecting them. I guess this isn't something that's explicitly covered in the requirements draft, so I think we need to see if folks want the feature supported or not. (Thanks for highlighting it Jim.) So, do we want to allow ssp statements to say "handling=block" or some equivalent? S. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Sep 28 13:50:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbJyu-0007iD-Ox for ietf-dkim-archive@lists.ietf.org; Fri, 28 Sep 2007 13:50:28 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbJyt-0008Qb-BP for ietf-dkim-archive@lists.ietf.org; Fri, 28 Sep 2007 13:50:28 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8SHmVTD027203; Fri, 28 Sep 2007 10:48:39 -0700 Received: from knecht.neophilic.com (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8SHmT3J027199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Sep 2007 10:48:29 -0700 Received: from [10.0.2.35] ([10.0.2.35]) by knecht.neophilic.com (8.14.1/8.13.6) with ESMTP id l8SHmblq026932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Sep 2007 10:48:39 -0700 (PDT) (envelope-from eric+dkim@sendmail.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sendmail.org; s=default; t=1191001721; bh=khXLufOhz5taWsfK8R+9FDdbQq+e4F1BeSqbXyU f3N8=; h=Date:From:To:cc:Subject:Message-ID:In-Reply-To:References: X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:X-Spam-Status:X-Spam-Checker-Version; b=qWPOj5 QXRyl+gJMHDDYllnRyxqclXb5TkFCZ3CjD3aXEKiSt+ZIHf+3P3yWK1E7C0L8dslgPB vp1BvB7mhHTcQ== Date: Fri, 28 Sep 2007 10:48:26 -0700 From: Eric Allman To: Michael Thomas , Jim Fenton Subject: Re: [ietf-dkim] Re: Step 9 Message-ID: <0F43776D5A98B6ADF5F32B56@rieux.neophilic.com> In-Reply-To: <46FC3730.3080004@mtcc.com> References: <46FC2DE4.5070702@cisco.com> <46FC323A.4000607@mtcc.com> <46FC3554.70305@cisco.com> <46FC3730.3080004@mtcc.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-1.9 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_FUTURE_12_24 autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on knecht.neophilic.com Cc: IETF DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.9 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 > Jim Fenton wrote: >> The key words here are Verifier Acceptable. The verifier gets to >> specify which signatures are Verifier Acceptable, which gives it >> precisely the liberty you describe. >> > > We're not communicating. What might a receiver do differently with > a third party signature with and without the "all"? I can't think > of anything. You're forgetting the "strict" case. Without step 9, the algorithm would fall through to step 10 ("The message is Suspicious and the algorithm terminates"). Step 9 explicitly allows the third party signature in the "all" case, but not in the "strict" case. Note that the valid first party signature case was handled in step 1, and the "dkim=unknown" case was handled in step 8, so by step 9 we're down to either no valid signature or a valid third party signature, and a dkim tag of "all", "strict", or something else due to a malformed SSP record. It might be easier to understand (and nearly semantically equivalent) if steps 9 and 10 read: 9. If the SSP "dkim" tag is "strict", or if no Verifier Acceptable Third-Party Signatures are present on the message and the SSP "dkim" tag is "all", the message is Suspicious and the algorithm terminates. 10. The message is not Suspicious and the algorithm terminates. eric _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Sep 28 13:55:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IbK3x-0001N5-7r for ietf-dkim-archive@lists.ietf.org; Fri, 28 Sep 2007 13:55:41 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IbK3q-00007g-VK for ietf-dkim-archive@lists.ietf.org; Fri, 28 Sep 2007 13:55:41 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8SHsKbt029492; Fri, 28 Sep 2007 10:54:20 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8SHsHTR029480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Sep 2007 10:54:18 -0700 Received: from [10.2.164.149] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) by harry.mail-abuse.org (Postfix) with ESMTP id E014441461; Fri, 28 Sep 2007 10:54:31 -0700 (PDT) In-Reply-To: <5D5E4F0EEB0DB5E2747FE2EE@p3.JCK.COM> References: <46A76413.6060206@altn.com> <77442E31-D9F3-4961-B54B-C0296B9E536A@mail-abuse.org> <06344C5B-8C7D-408C-A795-FD1580837729@mail-abuse.org> <1C74B638-4926-4A1F-AA56-36D7D6AB837E@mail-abuse.org> <5D5E4F0EEB0DB5E2747FE2EE@p3.JCK.COM> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0FD75BA9-1FFC-462F-BBF3-612706C8DF6E@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] 2821bis and AAAA (was: Thoughts on latest SSP draft) Date: Fri, 28 Sep 2007 10:54:30 -0700 To: John C Klensin X-Mailer: Apple Mail (2.752.2) Cc: Frank Ellermann , ietf-dkim@mipassoc.org, ietf-smtp@imc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.9 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe On Sep 27, 2007, at 1:36 PM, John C Klensin wrote: [In so many words, I said deprecating A and AAAA records for SMTP discovery would allows email policy records be limited to MX record locations.] > I think you have the cart and horse turned around backward. If > (and I'm not going to express an opinion at this point), one really > needs MX records if DKIM (and its near and distant header-signing > relatives) are to be supported in a reasonable and efficient way, > then it would be perfectly sensible to impose that requirement on > DKIM users. In other words, one makes provision, in the DKIM > specs, that, > > (i) if one is going to insert DKIM header records, one > MUST have MX records for the appropriate hosts. Email policy records are published to cover cases for when some added email requirement is _not_ met. Email policy records pose a degree of risk and added overhead when they must be separately discovered. It would be much safer to limit a discovery process to that of MX records. Several possible policy discoveries can thereby be eliminated by mandating use of MX records for the discovery of all public (port 25) SMTP servers. Any desired policy would then be adjacent to discovery (MX) record. This scheme could work with many other protocols. > (ii) if one encounters DKIM header records, does an MX > lookup, and does not get one or more MX records back, > then one SHOULD just give up and treat the DKIM records > as trash (whatever that happens to imply). Woe! Turn the cart around. Policy is needed when additional requirements are desired. A DKIM header is better confirmed with the offered key. Not having a DKIM header is when policy is needed. > This makes the "mandatory MX" issue a DKIM (and friends) issue, not > a requirement that zillions of hosts that do "MX, then address" > lookups consistent with 2821 (and 1123, and...) change what they > are doing because of some proposed words in 2821bis that change a > 20-odd-year-old spec. Won't happen, whether 2821bis is changed or > not. Email is faltering under an ever increasing onslaught of organized abuse often using forged domains. 2821bis is proposing a change where now AAAA records are to be allowed for discovery. This change adds to the overhead related to discerning valid email domains for little other benefit. Perhaps soon messages from domains lacking MX records will be refused. Even DSNs are being dropped. Times have changed. It is far less expensive and much safer to not wonder whether an address record might locate an SMTP server. 20 years ago an address record at an email domain was much more likely to point to an SMTP server. This is no longer a safe assumption. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Sep 30 15:15:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic4GR-00054P-C3 for ietf-dkim-archive@lists.ietf.org; Sun, 30 Sep 2007 15:15:39 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic4GE-00078V-2x for ietf-dkim-archive@lists.ietf.org; Sun, 30 Sep 2007 15:15:34 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8UJD7mg002117; Sun, 30 Sep 2007 12:13:15 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8UJD6Ze002114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 30 Sep 2007 12:13:06 -0700 Received: from crabapple.local (63-170-119-13.dsl.volcano.net [63.170.119.13]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l8UJDJx4003070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Sep 2007 12:13:21 -0700 Message-ID: <46FFF58F.4000901@mtcc.com> Date: Sun, 30 Sep 2007 12:14:23 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eric Allman Subject: Re: [ietf-dkim] Re: Step 9 References: <46FC2DE4.5070702@cisco.com> <46FC323A.4000607@mtcc.com> <46FC3554.70305@cisco.com> <46FC3730.3080004@mtcc.com> <0F43776D5A98B6ADF5F32B56@rieux.neophilic.com> In-Reply-To: <0F43776D5A98B6ADF5F32B56@rieux.neophilic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); Cc: IETF DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Eric Allman wrote: >> Jim Fenton wrote: >>> The key words here are Verifier Acceptable. The verifier gets to >>> specify which signatures are Verifier Acceptable, which gives it >>> precisely the liberty you describe. >>> >> >> We're not communicating. What might a receiver do differently with >> a third party signature with and without the "all"? I can't think >> of anything. > > You're forgetting the "strict" case. > > Without step 9, the algorithm would fall through to step 10 ("The > message is Suspicious and the algorithm terminates"). Step 9 > explicitly allows the third party signature in the "all" case, but not > in the "strict" case. Note that the valid first party signature case > was handled in step 1, and the "dkim=unknown" case was handled in step > 8, so by step 9 we're down to either no valid signature or a valid > third party signature, and a dkim tag of "all", "strict", or something > else due to a malformed SSP record. > > It might be easier to understand (and nearly semantically equivalent) > if steps 9 and 10 read: > > 9. If the SSP "dkim" tag is "strict", or if no Verifier Acceptable > Third-Party Signatures are present on the message and the SSP "dkim" > tag is "all", the message is Suspicious and the algorithm terminates. > > 10. The message is not Suspicious and the algorithm terminates. The main problem I'm having is tying "all" to third party signatures whatsoever. The requirements make no mention of "all" being tied to them, and I -- again -- don't see what the value is for the _originator_ to make any statement about them. "All" is a function of the originator's practices alone. Whether a useful (to the receiver) third party signature is tacked on in transit is completely out of its hands. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Sep 30 16:15:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic5CV-0008Lm-LL for ietf-dkim-archive@lists.ietf.org; Sun, 30 Sep 2007 16:15:39 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic5CU-0000HJ-Cv for ietf-dkim-archive@lists.ietf.org; Sun, 30 Sep 2007 16:15:39 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8UKDkrv012008; Sun, 30 Sep 2007 13:13:57 -0700 Received: from knecht.neophilic.com (dsl081-247-036.sfo1.dsl.speakeasy.net [64.81.247.36]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8UKDeNX012004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 30 Sep 2007 13:13:41 -0700 Received: from [10.0.2.35] ([10.0.2.35]) by knecht.neophilic.com (8.14.1/8.13.6) with ESMTP id l8UKDUB8053545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 30 Sep 2007 13:13:43 -0700 (PDT) (envelope-from eric+dkim@sendmail.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sendmail.org; s=default; t=1191183229; bh=uWGtBOkLJj9nzzC39na6aksDGtp4xAllnZxiyOW 5UHg=; h=Date:From:To:cc:Subject:Message-ID:In-Reply-To:References: X-Mailer:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-Disposition:X-Spam-Status:X-Spam-Checker-Version; b=UksDcd WnjVHbLbHToGbSQWkAnfMoje472YT1Rn8TVsKgDEqiTq5imvOQMyKHB8ZsUvdscEGiS Cgy6AgidZ8vDA== Date: Sun, 30 Sep 2007 13:13:11 -0700 From: Eric Allman To: Michael Thomas Subject: Re: [ietf-dkim] Conflicts between -ssp-requirements and -ssp (was: Step 9) Message-ID: <0339A987EB8BBCB686660F90@rieux.neophilic.com> In-Reply-To: <46FFF58F.4000901@mtcc.com> References: <46FC2DE4.5070702@cisco.com> <46FC323A.4000607@mtcc.com> <46FC3554.70305@cisco.com> <46FC3730.3080004@mtcc.com> <0F43776D5A98B6ADF5F32B56@rieux.neophilic.com> <46FFF58F.4000901@mtcc.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-2.3 required=4.0 tests=ALL_TRUSTED,BAYES_00, DATE_IN_FUTURE_48_96 autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on knecht.neophilic.com Cc: IETF DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d It sounds like you are arguing that "all" should be "strict" and "strict" should be eliminated; as a corollary, no Third Party Signatures should be accepted under any circumstances. That's a valid argument, but it has nothing to do with whether the -ssp draft is accurate. I note however that -ssp-requirements doesn't seem to cover the Third Party Signature case at all. Section 2 defines "Third Party Signature" but then never uses the term. In fact, although the one line description of Problem Scenario 1 reads "Is All Mail Signed with DKIM?", and section 4.1 seems to cover the case of a Third Party Signature (at least, it doesn't mandate a First Party Signature), sections 2 and 5.3 point 3 define "DKIM Signing Complete" as requiring a First Party Signature. In short, it appears that -req doesn't permit third party signatures under any circumstances. I'm not sure this was the intent of the working group. Reading the documents in this light, it's pretty clear that -ssp and -req are in conflict. The WG needs to decide on which way it wants to go. eric --On September 30, 2007 12:14:23 PM -0700 Michael Thomas wrote: > The main problem I'm having is tying "all" to third party > signatures whatsoever. The requirements make no mention of "all" > being tied to them, and I -- again -- don't see what the value is > for the _originator_ to make any statement about them. "All" is a > function of the originator's practices alone. Whether a useful (to > the receiver) third party signature is tacked on in transit is > completely out of its hands. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Sep 30 16:39:53 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic5Zx-0006UJ-Ph for ietf-dkim-archive@lists.ietf.org; Sun, 30 Sep 2007 16:39:53 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic5Zu-0000r4-0d for ietf-dkim-archive@lists.ietf.org; Sun, 30 Sep 2007 16:39:53 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8UKcbNw015894; Sun, 30 Sep 2007 13:38:37 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l8UKcZou015883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 30 Sep 2007 13:38:35 -0700 Received: from crabapple.local (63-170-119-13.dsl.volcano.net [63.170.119.13]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l8UKcfnX011934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Sep 2007 13:38:42 -0700 Message-ID: <47000990.5070408@mtcc.com> Date: Sun, 30 Sep 2007 13:39:44 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/20070728 Thunderbird/2.0.0.6 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Eric Allman Subject: Re: [ietf-dkim] Conflicts between -ssp-requirements and -ssp References: <46FC2DE4.5070702@cisco.com> <46FC323A.4000607@mtcc.com> <46FC3554.70305@cisco.com> <46FC3730.3080004@mtcc.com> <0F43776D5A98B6ADF5F32B56@rieux.neophilic.com> <46FFF58F.4000901@mtcc.com> <0339A987EB8BBCB686660F90@rieux.neophilic.com> In-Reply-To: <0339A987EB8BBCB686660F90@rieux.neophilic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); Cc: IETF DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Eric Allman wrote: > It sounds like you are arguing that "all" should be "strict" and > "strict" should be eliminated; > as a corollary, no Third Party Signatures should be accepted under any > circumstances. That's a valid argument, but it has nothing to do with > whether the -ssp draft is accurate. No. Strict seems consistent with the requirements. For "all", the problem I'm having is tying the statement "I sign everything" to any other statement, including "I think that 3rd party signatures are groovy". They are not inherently linked, and the SSP draft shouldn't do that. I can very easily say "I sign everything" and have no opinion whatsoever about other kinds of signatures. > > I note however that -ssp-requirements doesn't seem to cover the Third > Party Signature case at all. Section 2 defines "Third Party > Signature" but then never uses the term. In fact, although the one > line description of Problem Scenario 1 reads "Is All Mail Signed with > DKIM?", and section 4.1 seems to cover the case of a Third Party > Signature (at least, it doesn't mandate a First Party Signature), > sections 2 and 5.3 point 3 define "DKIM Signing Complete" as requiring > a First Party Signature. In short, it appears that -req doesn't > permit third party signatures under any circumstances. I'm not sure > this was the intent of the working group. It doesn't permit 3rd party signatures for _SSP_ itself. That doesn't say anything about third party signatures in general which receivers are perfectly at liberty to use or not use as they see fit. I'm pretty sure we've been through this ad nauseum about third party signatures with SSP and that the consensus was that we didn't want to go there. Look at the archives about whether we needed enumerated lists of 3rd party signers for example -- that was rejected. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Sep 30 20:13:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ic8uk-0003hI-S1 for ietf-dkim-archive@lists.ietf.org; Sun, 30 Sep 2007 20:13:34 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ic8ue-0005nZ-Jc for ietf-dkim-archive@lists.ietf.org; Sun, 30 Sep 2007 20:13:34 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l910BX1g017730; Sun, 30 Sep 2007 17:11:41 -0700 Received: from winserver.com (ftp.catinthebox.net [208.247.131.9]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l910BNSQ017648 for ; Sun, 30 Sep 2007 17:11:27 -0700 Received: by winserver.com (Wildcat! SMTP Router v6.2.452.2) for ietf-dkim@mipassoc.org; Sun, 30 Sep 2007 20:13:06 -0400 Received: from hdev1 ([65.10.44.106]) by winserver.com (Wildcat! SMTP v6.2.452.2) with ESMTP id 946323612; Sun, 30 Sep 2007 20:13:05 -0400 Message-ID: <47003B30.7050102@santronics.com> Date: Sun, 30 Sep 2007 20:11:28 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Michael Thomas Subject: Re: [ietf-dkim] Conflicts between -ssp-requirements and -ssp References: <46FC2DE4.5070702@cisco.com> <46FC323A.4000607@mtcc.com> <46FC3554.70305@cisco.com> <46FC3730.3080004@mtcc.com> <0F43776D5A98B6ADF5F32B56@rieux.neophilic.com> <46FFF58F.4000901@mtcc.com> <0339A987EB8BBCB686660F90@rieux.neophilic.com> <47000990.5070408@mtcc.com> In-Reply-To: <47000990.5070408@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Michael Thomas wrote: > It doesn't permit 3rd party signatures for _SSP_ itself. That doesn't > say anything about third party signatures in general which receivers > are perfectly at liberty to use or not use as they see fit. I'm pretty > sure we've been through this ad nauseum about third party signatures with > SSP and that the consensus was that we didn't want to go there. No. There was no consensus. Major difference. > Look at the archives about whether we needed enumerated lists > of 3rd party signers for example -- that was rejected. No, for all intent and purposes, it was never given a chance because a) this key cogs never understood it, b) was confused by other REPUTATION designs ambitions and c) due to some wasted requirements document molded by a person who never believed in strict 3PS designs in the first place. No one should be surprise that the same critical issues highlighted nearly 3+ years ago is the same issue today. It can't be ignore and I have serious doubt DKIM will be seriously adopted in mass because 3PS was neglected and never adequately and seriously accepted for consideration by its cogs. Unfortunately, the decision was made to IGNORE those who have good and excellent input. So no, there was never never any serious consideration, thus any valid consensus one way or another. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html