Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O29GRR058448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 19:09:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9O29Gxn058446; Thu, 23 Oct 2008 19:09:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O295K4058428; Thu, 23 Oct 2008 19:09:15 -0700 (MST) (envelope-from markrcrispin@live.com) Received: from BLU126-W22 ([65.55.116.72]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Oct 2008 19:07:55 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_2b333ddd-2963-4a09-9d07-78b8bbdb2159_" X-Originating-IP: [206.124.149.116] From: Mark Crispin To: Douglas Otis , "Murray S. Kucherawy" CC: , , Mail-Vet-Discuss Subject: RE: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Thu, 23 Oct 2008 19:07:55 -0700 Importance: Normal In-Reply-To: References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> <4900C737.7070000@sendmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2008 02:07:55.0935 (UTC) FILETIME=[545D3AF0:01C9357D] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_2b333ddd-2963-4a09-9d07-78b8bbdb2159_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 > From: dotis@mail-abuse.org > Get rid of the sales hype describing everything as "authentication". =20 > Security is no time for muddled or misused terminology. There is no =20 > reason to mislead recipients any more than they already are. _________________________________________________________________ When your life is on the go=97take your life with you. http://clk.atdmt.com/MRT/go/115298558/direct/01/= --_2b333ddd-2963-4a09-9d07-78b8bbdb2159_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1

>=3B From: dotis@mail-abuse.org
>=3B Get rid of the sales = hype describing everything as "authentication".
>=3B Security is no= time for muddled or misused terminology. There is no
>=3B reason t= o mislead recipients any more than they already are.


Whe= n your life is on the go=97take your life with you. Try Windows Mobile=AE= today = --_2b333ddd-2963-4a09-9d07-78b8bbdb2159_-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O13Fhm055999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 18:03:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9O13FnC055998; Thu, 23 Oct 2008 18:03:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O134YW055987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 18:03:14 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 59765A9443D; Fri, 24 Oct 2008 01:03:01 +0000 (UTC) Cc: ietf-imapext@imc.org, ietf-smtp@imc.org, Mail-Vet-Discuss Message-Id: From: Douglas Otis To: "Murray S. Kucherawy" In-Reply-To: <4900C737.7070000@sendmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Thu, 23 Oct 2008 18:03:00 -0700 References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> <4900C737.7070000@sendmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 23, 2008, at 11:49 AM, Murray S. Kucherawy wrote: > Douglas Otis wrote: >> The ADSP draft inhibits an assurance regarding _what_ the signing >> domain authenticated! The Author Signature definition limits a >> signing-domain's associated "on-behalf-of" identifier to being an >> email address within the From header field or to being _blank_. >> As a result, any intra-domain abuse can not be safely identified. >> One would be mistaken to assume the From email-address is always >> what a signing domain authenticates. No other assumption would be >> available without incurring an impractical second signature that is >> likely ignored anyway. Should one care about the damage created by >> an incorrect assumption regarding authentication, even when the >> assumption is signed by the border MTA? Perhaps this could be call >> the Assumed-Authentication-Results header. : ) >> >> -Doug > > Doug, > > I'm pretty sure you're talking about the reliability/assertions of > ADSP or even DKIM. That's orthogonal to what we're discussing here > on mail-vet-discuss. This draft is about moving the evaluation > results from an MTA to MUAs in a consistent and reliable manner. > That the evaluations themselves could conceivably be flawed or > subverted is already discussed in Security Considerations for this > draft and is not within the scope of this document. I responded to a different message on mail-vet and dkim. Here is the portion that attempts to explain the concern: A security mechanism should not recklessly abuse the term Authentication. The term Authentication is _dangerously_ misleading for most methods logged by this header. The term "Authentication" should be replaced by a neutral term "method" within draft where possible. It would not be too misleading to use the terms "Authentication or Authorization" instead of just "Authentication" within a few sentences. A header label "Source-Results" would be less deceptive in respect to the nature of the results obtained. The term Authentication is being misused more than 60 times through out this draft (ignoring the title and header labels). Admittedly the word "authorized" is buried in the definition of some results, but this term will _never_ be evident to the user. Do you see the danger using the header label "Authentication-Results:"? The draft's introductory statement does not help much either: "At the time of publication of this draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the published e-mail authentication methods in common use." Authentication methods? Really? It is _dangerous_ and _misleading_ to suggest that an SMTP client _authorization_ method results in the "authentication" of the PRA, MAILFROM, the valid origination of the message as stated in this draft. An _unauthorized_ SMTP client MAY be an indication of the invalid use of a MAILFROM or PRA, however an authorized SMTP client must not be assumed to indicate the valid use of an email-address, as suggested by the overused term "Authentication" through out this draft. Describing an authorization method as being an authentication method results in a dangerous misrepresentation of the results produced for most of the methods currently defined, even for DKIM-ADSP at this time. Get rid of the sales hype describing everything as "authentication". Security is no time for muddled or misused terminology. There is no reason to mislead recipients any more than they already are. -Doug Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NInDAH037308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 11:49:13 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NInDox037307; Thu, 23 Oct 2008 11:49:13 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NIn1jS037288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Oct 2008 11:49:12 -0700 (MST) (envelope-from msk@sendmail.com) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m9NInfTj028332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Oct 2008 11:49:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1224787781; bh=ZIWDsLDfqovbcbs6WKsihAPQMDnYIztWu7x9 UiPFiao=; h=Received:X-DKIM:DKIM-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=PB9xyBRoEa 1JF/KddSuxr0xcsd8cVCdRVYLdlcNBs7CJLkuWSvTZiOdCTvsCqcBnMT6vKlvslwDpQ +CQu5pBqvNYirzyllOVP6D0zRc8bBgAy1s8NLh1q74zsTWxivaLj0zBFoK8pU8yPnVs 4I2k8vxHquY1PClpf9/D+BqKg7I= Received: from [10.210.202.7] ([10.210.202.7]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m9NImmBV029107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 11:48:50 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m9NImmBV029107 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1224787731; bh=ZIWDsLDfqovbcbs6WKsihAPQMDnYIztWu7x9 UiPFiao=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=akMYIQvcyyLP7+Dh0XZOV12 9osnqhwYx9C3zfdo3+nM471A2TrbbCahlMp3VqPs1OKY8aFc8QRegT+Hfc1e9utyiM4 2oblX8/+fI7LvQZdUPEmhAZNzDwE44uVMKJqag6WrcRH75SICVeVWRPR27CF4zWwLef rsakPFc5/CgKhs= Message-ID: <4900C737.7070000@sendmail.com> Date: Thu, 23 Oct 2008 11:49:27 -0700 From: "Murray S. Kucherawy" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Douglas Otis CC: Dave CROCKER , ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MM-Ex-RefId: 149371::081023114851-06A3EB90-2DC2386A/0-0/0-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Douglas Otis wrote: > The ADSP draft inhibits an assurance regarding _what_ the signing > domain authenticated! The Author Signature definition limits a > signing-domain's associated "on-behalf-of" identifier to being an > email address within the From header field or to being _blank_. As > a result, any intra-domain abuse can not be safely identified. One > would be mistaken to assume the From email-address is always what a > signing domain authenticates. No other assumption would be available > without incurring an impractical second signature that is likely > ignored anyway. Should one care about the damage created by an > incorrect assumption regarding authentication, even when the > assumption is signed by the border MTA? Perhaps this could be call > the Assumed-Authentication-Results header. : ) > > -Doug > Doug, I'm pretty sure you're talking about the reliability/assertions of ADSP or even DKIM. That's orthogonal to what we're discussing here on mail-vet-discuss. This draft is about moving the evaluation results from an MTA to MUAs in a consistent and reliable manner. That the evaluations themselves could conceivably be flawed or subverted is already discussed in Security Considerations for this draft and is not within the scope of this document. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9M06ESx027714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 17:06:14 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9M06Eds027713; Tue, 21 Oct 2008 17:06:14 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9M062jm027702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 17:06:13 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 5BCFAA9443C; Wed, 22 Oct 2008 00:06:02 +0000 (UTC) Cc: Dave CROCKER , ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Message-Id: From: Douglas Otis To: "Murray S. Kucherawy" In-Reply-To: <48F50E27.9080502@sendmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Tue, 21 Oct 2008 17:06:01 -0700 References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 14, 2008, at 2:24 PM, Murray S. Kucherawy wrote: > > Douglas Otis wrote: >> Agreed. However, when a domain attempts to assert control over the >> From header field using DKIM and ADSP, they must "pretend" to >> authenticate an email-address within the From header field. > > I don't think we're talking about any such assertions here. We're > only interested in protecting an Authentication-Results: header > added by a border MTA on inbound mail. Seems like ADSP and even > From: are somewhat irrelevant to this discussion. The ADSP draft inhibits an assurance regarding _what_ the signing domain authenticated! The Author Signature definition limits a signing-domain's associated "on-behalf-of" identifier to being an email address within the From header field or to being _blank_. As a result, any intra-domain abuse can not be safely identified. One would be mistaken to assume the From email-address is always what a signing domain authenticates. No other assumption would be available without incurring an impractical second signature that is likely ignored anyway. Should one care about the damage created by an incorrect assumption regarding authentication, even when the assumption is signed by the border MTA? Perhaps this could be call the Assumed-Authentication-Results header. : ) -Doug Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FAJA3F089353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 03:19:10 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9FAJAK3089351; Wed, 15 Oct 2008 03:19:10 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FAIwSo089316 for ; Wed, 15 Oct 2008 03:19:09 -0700 (MST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.3.452.5) for ietf-imapext@imc.org; Wed, 15 Oct 2008 06:20:31 -0400 Received: from hdev1 ([72.144.161.85]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 3721354984; Wed, 15 Oct 2008 06:20:29 -0400 Message-ID: <48F5C338.5000101@santronics.com> Date: Wed, 15 Oct 2008 06:17:28 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: Straw consensus call on auth-header draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I'd like to do a more explicit consensus call now to nail this down. > I've tried to identify the major points of attraction rather than every > variant, to see where people are leaning. Please reply with one of > these options, a variant, and explanation if you like: > > A) auth-header to not require any feature advertising or auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising > C) auth-header to normatively REQUIRE some kind of feature advertising "C" for having a reason for living (implementing it). Otherwise, whats the point? "A" will further create fuzzy unknowns about trust. While B is the middle ground, it is just as bad as A. > Separately, the unspecified feature advertising or auto-conf should be > (choose one or more): > 1) IMAP Capabilities advertising > 2) E/SMTP capabilities > 3) IMAP annotations > 4) Something else > 5) Nothing Thats just it. Whats it for? The only use I see for it is to pass intra-process (internal) state information, i.e. so that a 2nd trusted process doesn't have to "re-do" whatever the first trusted process did. For an Internal MUA (a trusted process), it can be used for state information. Why and When would a offline MUA, for example, trust and make use of this information? In terms of DKIM, does it replace the need for an MUA to do DKIM verification? -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EM4tDg040133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 15:04:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EM4t0b040130; Tue, 14 Oct 2008 15:04:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EM4hhS040106; Tue, 14 Oct 2008 15:04:54 -0700 (MST) (envelope-from steve@blighty.com) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id E26D8800C2; Tue, 14 Oct 2008 15:04:40 -0700 (PDT) Message-Id: <9E521D40-B2A6-4782-B9AA-D3A5D8773F55@blighty.com> From: Steve Atkins To: SMTP Interest Group , ietf-imapext@imc.org, Mail-Vet-Discuss In-Reply-To: <48F50E27.9080502@sendmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Tue, 14 Oct 2008 15:04:42 -0700 References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (I expect this message to be rejected by at least some of the mailing lists it was CCed to). On Oct 14, 2008, at 2:24 PM, Murray S. Kucherawy wrote: > > Douglas Otis wrote: >> Agreed. However, when a domain attempts to assert control over the >> From header field using DKIM and ADSP, they must "pretend" to >> authenticate an email-address within the From header field. > > I don't think we're talking about any such assertions here. We're > only interested in protecting an Authentication-Results: header > added by a border MTA on inbound mail. Seems like ADSP and even > From: are somewhat irrelevant to this discussion. > If it's added by a border MTA, so it's only seen by your network after the header is added, what are you protecting it against? Cheers, Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ELP1Zw036922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 14:25:01 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9ELP1hg036921; Tue, 14 Oct 2008 14:25:01 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ELOmJU036889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 14:25:00 -0700 (MST) (envelope-from msk@sendmail.com) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m9ELPCdG000839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 14:25:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1224019512; bh=ujT8QwH5fdaiMnFMa09sN5QtiZgPiP9TM5Ub uIH4xC8=; h=Received:X-DKIM:DKIM-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=phTB0hRRQ7 9a7QExGved090I4Anc97IEQPOnN1qqptL52v9l35aHI7Yp2gPP381CUSzXjH9q04YHT aXSqwU8+Ui3gMpoZtpKn8EUd8lxfNaFRC+km1qzjMUEmsSVvnwct4s3l7g23OY9JynL WWFPuXUE+lC4eYVcRCX1L81YAJA= Received: from [10.210.202.7] ([10.210.202.7]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m9ELOReK029287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 14:24:34 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m9ELOReK029287 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1224019476; bh=ujT8QwH5fdaiMnFMa09sN5QtiZgPiP9TM5Ub uIH4xC8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=eEdWOUmXgI12OHsqJlwBcvG 4688pSwlnM+Fk0Sf9gZbPopRnOfyB3CWls1PEUkpW/n9du0vxXWmv/xlFxG0nsVM13G EdgzkO6ojiVu4PYi/wk7mrJcHp1HEgpdYX6sSfwYrRFUwnG4H6uhB6L4Fnn//92ugBq LfkhB7cLZck6u8= Message-ID: <48F50E27.9080502@sendmail.com> Date: Tue, 14 Oct 2008 14:24:55 -0700 From: "Murray S. Kucherawy" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Douglas Otis CC: dcrocker@bbiw.net, ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> In-Reply-To: <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MM-Ex-RefId: 149371::081014142435-5AD7AB90-5CE9F3EB/0-0/0-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Douglas Otis wrote: > Agreed. However, when a domain attempts to assert control over the > From header field using DKIM and ADSP, they must "pretend" to > authenticate an email-address within the From header field. I don't think we're talking about any such assertions here. We're only interested in protecting an Authentication-Results: header added by a border MTA on inbound mail. Seems like ADSP and even From: are somewhat irrelevant to this discussion. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EGqRsj013773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 09:52:27 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EGqRr1013772; Tue, 14 Oct 2008 09:52:27 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EGqGmF013757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 09:52:26 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 194B7A94443; Tue, 14 Oct 2008 16:52:16 +0000 (UTC) Cc: dcrocker@bbiw.net, ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Message-Id: <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> From: Douglas Otis To: "Murray S. Kucherawy" In-Reply-To: <48F3A85B.8020906@sendmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Tue, 14 Oct 2008 09:52:13 -0700 References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 13, 2008, at 12:58 PM, Murray S. Kucherawy wrote: > > Dave CROCKER wrote: >> This begs the question: why bother to do the first validation; why >> not simply wait and let whoever would have validated the first >> instead validate the first? > > If the only authentication method being applied at a site is DKIM or > other things that don't care about the path, that works. But that's > a big "if", and moreover means all consumers of authentication > results data must now learn all local path-agnostic methods being > used to evaluate messages. > > The desire here is to secure arbitrary authentication results data > between the border MTA and the consuming MUA. DKIM is one way that > could be achieved, meaning the consumers need to learn one and only > one message authentication scheme in order to validate that one > piece of protected internal data. Agreed. However, when a domain attempts to assert control over the From header field using DKIM and ADSP, they must "pretend" to authenticate an email-address within the From header field. ADSP, using a false premise of email-address authentication, has impaired DKIM's on-behalf-of field which is essential for evaluating intra- domain abuse. If the source of a message is not abusive, there should be no reason to filter based upon content classifications. In the case of ADSP, there no basis upon which classifications can be trusted. The one exception would be for a perfect signing domain, otherwise these efforts represent an exercise in futility. -Doug Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EFwu2W009442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 08:58:56 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EFwufm009440; Tue, 14 Oct 2008 08:58:56 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EFwhCg009425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 08:58:54 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.1.118] (static-66-14-247-16.bdsl.verizon.net [66.14.247.16]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m9EFwek6001851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 08:58:41 -0700 Message-ID: <48F4B5B9.60202@dcrocker.net> Date: Tue, 14 Oct 2008 11:07:37 -0400 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Murray S. Kucherawy" CC: ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> In-Reply-To: <48F3A85B.8020906@sendmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/8423/Tue Oct 14 05:36:14 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 14 Oct 2008 08:58:43 -0700 (PDT) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Murray, Interesting and intriguing perspective. I like it. Perhaps I missed it, but I don't recall seeing such a coherent, focused and pragmatic requirements statement in this discussion, so far. But note that what you are describing has nothing specific to mail-vet. Really. You are describing a generic requirement for trusted information exchange between two nodes that are possibly within a trust domain. The fact that the information is, itself, security-related might affect some choices in the design, but not in a way that is specific to mail-vet (or the fact that it is security-releated...) The other that might be a bit different is to protect a specified header field. Again, I doubt that affects design choices all that much. So mail-vet *might* be motivating it, but it is really an independent technical requirement. It warrants an independent technical specification. Let me repeat this: To the extent that the current specification is for a data format, rather than an end-to-end exchange service, then an effort to satisfy this requirement belongs to a separate document. And, of course, there are *lots* of ways to satisfy it. That's a further reason to avoid burdening the current, core data spec with its details. d/ Murray S. Kucherawy wrote: > Dave CROCKER wrote: >> This begs the question: why bother to do the first validation; why >> not simply wait and let whoever would have validated the first instead >> validate the first? > > If the only authentication method being applied at a site is DKIM or > other things that don't care about the path, that works. But that's a > big "if", and moreover means all consumers of authentication results > data must now learn all local path-agnostic methods being used to > evaluate messages. > > The desire here is to secure arbitrary authentication results data > between the border MTA and the consuming MUA. DKIM is one way that > could be achieved, meaning the consumers need to learn one and only one > message authentication scheme in order to validate that one piece of > protected internal data. > -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9E11Hpt029917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 18:01:17 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9E11H7S029916; Mon, 13 Oct 2008 18:01:17 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9E115pL029902; Mon, 13 Oct 2008 18:01:16 -0700 (MST) (envelope-from sm@resistor.net) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id m9E10s7i006548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 18:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1223946064; x=1224032464; bh=Tt/cVfQkqnABDIIN0ReaRgJjzEGNYxI05qD0 O36ZbVo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=T4TFQpIduaQcYbkl0uVriQ+X27OXanREvi mRh2MAeq0+tzscI2ptT/bAW7oudv9s8/4jNYWlvOjNfUY1RTZLOSMV/mwUKkYl4cs1T LZeKmt5hOfCNBv2OSpAyXzJRQcP4UPXHxLca7iGlk9AqBqul3QOKA33ejU/5uEaPUre /74= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=0dLPOhxF9IkKp1bjulFpEisaT5XvhM9Bgdj8nCx6wWGWyqi+xyOqTvVF5LPYOTmst K9QWiFmmiM4xDQttJW4Ze9cGsuL/LxROM/v2UjnqOUh9f8l28brtk7jr+w7osjzw1pd 16R+G58z/14hz/xPBCOZrJ9FqEgDinc9pIYTF2M= Message-Id: <6.2.5.6.2.20081013174044.02ed0e58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 13 Oct 2008 18:00:15 -0700 To: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org From: SM Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:29 12-10-2008, Lisa Dusseault wrote: >I'd like to do a more explicit consensus call now to nail this >down. I've tried to identify the major points of attraction rather >than every variant, to see where people are leaning. Please reply >with one of these options, a variant, and explanation if you like: > >A) auth-header to not require any feature advertising or auto-configuration I'm for (A). >B) auth-header to normatively RECOMMEND some kind of feature advertising >C) auth-header to normatively REQUIRE some kind of feature advertising I gather that you are referring to advertising for the MUA through POP3 and IMAP. >Separately, the unspecified feature advertising or auto-conf should >be (choose one or more): >1) IMAP Capabilities advertising >2) E/SMTP capabilities >3) IMAP annotations >4) Something else >5) Nothing I'm for (5). Regards, -sm Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJw8Dc031341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:58:08 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DJw8XW031339; Mon, 13 Oct 2008 12:58:08 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJw6uX031327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 12:58:07 -0700 (MST) (envelope-from msk@sendmail.com) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m9DJwV5v022662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 12:58:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1223927912; bh=x3NzhqUxTxml7L20sLw7WkKokN1aEarIsX2x 05NdSYc=; h=Received:X-DKIM:DKIM-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=HcNTAhOXkf pNwX1bwLjJd4vu8nNEKz876SrBtlPjksEiDU1kaWG+FvXRCg8R/uf7YapUGYM4i5sy+ +Q7Toxvp/szK95cyeg8I8y4SBPydsS7lpgKEDHefbD48L7bWlFdDS6TPMllF32dnWUV 8dtgR7fSKbJ7ngMqmLFkqmFH5ec= Received: from [10.210.202.7] ([10.210.202.7]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m9DJvq7g025259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:57:52 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 fife.sendmail.com m9DJvq7g025259 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1223927876; bh=x3NzhqUxTxml7L20sLw7WkKokN1aEarIsX2x0 5NdSYc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=6z5rbqytB9+YHL7Nd012HPF d4TTUR7qjxaiOcHXsgHOoTV4R83Jx3YYFsBOeUOs0EqnwPTetckNjJjnYLlQ0cpCXjg ULvyQ9BMOp3z7euLX8RSewo8XkwBTysJO6Uvr2UfHRtPGQVddHsxp3PQvDKkMV6RYM8 L+il3Fi71YGCkg= Message-ID: <48F3A85B.8020906@sendmail.com> Date: Mon, 13 Oct 2008 12:58:19 -0700 From: "Murray S. Kucherawy" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dcrocker@bbiw.net CC: ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> In-Reply-To: <48F3A198.2080700@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MM-Ex-RefId: 149371::081013125756-75714B90-17C908C1/0-0/0-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave CROCKER wrote: > This begs the question: why bother to do the first validation; why > not simply wait and let whoever would have validated the first instead > validate the first? If the only authentication method being applied at a site is DKIM or other things that don't care about the path, that works. But that's a big "if", and moreover means all consumers of authentication results data must now learn all local path-agnostic methods being used to evaluate messages. The desire here is to secure arbitrary authentication results data between the border MTA and the consuming MUA. DKIM is one way that could be achieved, meaning the consumers need to learn one and only one message authentication scheme in order to validate that one piece of protected internal data. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJpGFr031033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:51:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DJpGDD031032; Mon, 13 Oct 2008 12:51:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJpF3X031021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:51:15 -0700 (MST) (envelope-from dcrocker@bbiw.net) Received: from [10.1.129.77] ([66.103.88.194]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m9DJpDqV026628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:51:14 -0700 Message-ID: <48F3A68F.4010002@bbiw.net> Date: Mon, 13 Oct 2008 15:50:39 -0400 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: Straw consensus call on auth-header draft References: <48F28BE6.1060509@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/8417/Mon Oct 13 00:34:29 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 13 Oct 2008 12:51:14 -0700 (PDT) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: >> So, please clarify how can a technical specification contain normative >> language to cover something that doesn't exist? More precisely, what >> does it mean to include such language, in terms of actual development >> or operation? What impact does such a statement have on the current >> specification? On use of it? > > Since that's not what I'm suggesting, I can't answer these questions. It isn't? Since your language was "normatively * some kind of feature advertising" then I am entirely confused. The feature advertising for this does not yet exist. You cite normatively referring to such advertising. How did I mis-characterize your query? >> The alternative seems to be to require the current specification to >> wait until there is an approved specification for >> advertising/configuration that can then, in turn, be recommended or >> required (presumably SHOULD OR MUST, respectively?) > > That could be. That's useful input, since it can level-set folks' expectations. >> pps. What are examples of similar mechanisms, for application-level >> advertising or auto-configuration, that are already in Internet-scale >> use? Knowing the answer to this can give some guidance about the >> likely risk of mandating such a mechanism here. > > IMAP and SMTP have lots of application-level capabilities advertising. > Sometimes this can aid auto-configuration. Hmmm. Maybe it's jet-lag. I'm not thinking of which ones you might have in mind. I'd really appreciate some particulars, for advertising security-related features that rely on being within a trust boundary and are widely adopted and used. What existing mechanisms qualify? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJUE1l030156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:30:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DJUEBY030154; Mon, 13 Oct 2008 12:30:14 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJU3eQ030138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:30:14 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [10.1.129.77] ([66.103.88.194]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m9DJU1iU026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:30:02 -0700 Message-ID: <48F3A198.2080700@dcrocker.net> Date: Mon, 13 Oct 2008 15:29:28 -0400 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Murray S. Kucherawy" CC: ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> In-Reply-To: <48F38765.30508@sendmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/8417/Mon Oct 13 00:34:29 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 13 Oct 2008 12:30:03 -0700 (PDT) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Murray S. Kucherawy wrote: > 4 would include DKIM signing. I'd be fine with adding a SHOULD there. SHOULD? You would specify a normative SHOULD for protecting a DKIM validation with a(nother) DKIM signature? This begs the question: why bother to do the first validation; why not simply wait and let whoever would have validated the first instead validate the first? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DHvBCB023337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 10:57:11 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DHvB32023334; Mon, 13 Oct 2008 10:57:11 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from leka.osafoundation.org (leka.osafoundation.org [64.127.108.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DHv06L023316; Mon, 13 Oct 2008 10:57:10 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2A6A43E3722; Mon, 13 Oct 2008 10:57:00 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs4EexzzhkyD; Mon, 13 Oct 2008 10:56:55 -0700 (PDT) Received: from [192.168.1.102] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 4CFBD3E36F0; Mon, 13 Oct 2008 10:56:55 -0700 (PDT) Cc: Lisa Dusseault , Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Message-Id: From: Lisa Dusseault To: dcrocker@bbiw.net In-Reply-To: <48F28BE6.1060509@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: Straw consensus call on auth-header draft Date: Mon, 13 Oct 2008 10:56:54 -0700 References: <48F28BE6.1060509@dcrocker.net> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 12, 2008, at 4:44 PM, Dave CROCKER wrote: > > > > Lisa Dusseault wrote: >> I'd like to do a more explicit consensus call now to nail this >> down. I've tried to identify the major points of attraction rather >> than every variant, to see where people are leaning. Please reply >> with one of these options, a variant, and explanation if you like: >> A) auth-header to not require any feature advertising or auto- >> configuration >> B) auth-header to normatively RECOMMEND some kind of feature >> advertising >> C) auth-header to normatively REQUIRE some kind of feature >> advertising > > > Lisa, > > Your alternatives B & C appear to seek normative technical language > that refers to something that does not exist. Further, a phrase > like "some kind of" makes it rather difficult to know whether the > 'requirement' is satisfied. Yes, this is correct. I realize this is somewhat of a charter-phase question, but that's a risk with individual submissions going for Proposed Standard -- the risk that without a consensus-based charter, the scope of the work will be questioned. > > It is generally ill-advised to have a specification make statements > about the unknown future, which of course means anything in the > future. It seems an even poorer choice to make that statement be > normative, without specifying the details of that future precisely. Agreed. > > So, please clarify how can a technical specification contain > normative language to cover something that doesn't exist? More > precisely, what does it mean to include such language, in terms of > actual development or operation? What impact does such a statement > have on the current specification? On use of it? Since that's not what I'm suggesting, I can't answer these questions. > > > The alternative seems to be to require the current specification to > wait until there is an approved specification for advertising/ > configuration that can then, in turn, be recommended or required > (presumably SHOULD OR MUST, respectively?) That could be. > > ps. But to conform to the precise confines of your exercise, I > suggest Alternative A, since there are many operational environments > for which manual configuration works just fine. In those > environments, advertising and configuration mechanisms add > complexity without benefit. > > > pps. What are examples of similar mechanisms, for application-level > advertising or auto-configuration, that are already in Internet- > scale use? Knowing the answer to this can give some guidance about > the likely risk of mandating such a mechanism here. IMAP and SMTP have lots of application-level capabilities advertising. Sometimes this can aid auto-configuration. Lisa Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DHbWPB021999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 10:37:32 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DHbWCT021998; Mon, 13 Oct 2008 10:37:32 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DHbLQt021970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 10:37:31 -0700 (MST) (envelope-from msk@sendmail.com) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m9DHbpZ2026915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 10:37:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1223919471; bh=t55z7AjyLjsHBplzBKDSikavzQdZUw0MMZaL 8ExHZdA=; h=Received:X-DKIM:DKIM-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=Ak0x1gbWVc jGO8oEIDfbbKK3V0IGHWr4QnV3QizRKtZ/1mKcf9o6TLgCkDV24wYvif5OmhLrXLoRE Bvpia9bY0eKKrxDTXj+8MCZJl8gLkQUYuf9OyYe1SMGFcCoFTU2FqLspQGGrNljbBLV XcXL5XQUvlAj3LOEe6B92iPNMG8= Received: from [10.210.202.7] ([10.210.202.7]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m9DHbFbO005359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 10:37:16 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 fife.sendmail.com m9DHbFbO005359 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1223919437; bh=t55z7AjyLjsHBplzBKDSikavzQdZUw0MMZaL8 ExHZdA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=Zv8sbn3fNqhzTNW/N8yNJoJ MSxzRqUmGAGxH6h2k1cwfGLFaf5ktdL9K+4Oc2H/4oTABHXrrcYMXdqMrG9R9Dlt7Yu bIQlsgHSLIVsCrAG7mPne8o93ANOqw9/SyVbO7ipERPeAX8fISlVw+TrdDRxMN2MSfW jlaKV/NtmFEnmE= Message-ID: <48F38765.30508@sendmail.com> Date: Mon, 13 Oct 2008 10:37:41 -0700 From: "Murray S. Kucherawy" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MM-Ex-RefId: 149371::081013103717-7571BB90-30BD82DE/0-0/0-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > A) auth-header to not require any feature advertising or auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising > C) auth-header to normatively REQUIRE some kind of feature advertising > I'm currently between A and B. I'm fine with referencing possible solutions, but I'm not sure I agree with the need for any normative language. > Separately, the unspecified feature advertising or auto-conf should be > (choose one or more): > 1) IMAP Capabilities advertising > 2) E/SMTP capabilities > 3) IMAP annotations > 4) Something else > 5) Nothing > I don't think 3 is relevant here. It specifies a different mechanism entirely. 1 & 2 are what the draft should mention as experimental possibilities. 4 would include DKIM signing. I'd be fine with adding a SHOULD there. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DA9ocL078276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 03:09:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DA9oA9078275; Mon, 13 Oct 2008 03:09:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DA9dPu078259; Mon, 13 Oct 2008 03:09:49 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.2.195] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 13 Oct 2008 11:09:37 +0100 Message-ID: <48F31E58.2030101@isode.com> Date: Mon, 13 Oct 2008 11:09:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I'd like to do a more explicit consensus call now to nail this down. > I've tried to identify the major points of attraction rather than > every variant, to see where people are leaning. Please reply with > one of these options, a variant, and explanation if you like: > > A) auth-header to not require any feature advertising or > auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising I am in favour of B, but I want it to be described informatively with examples. (I.e. I think having a SHOULD would be a mistake) > C) auth-header to normatively REQUIRE some kind of feature advertising > > Separately, the unspecified feature advertising or auto-conf should be > (choose one or more): > 1) IMAP Capabilities advertising > 2) E/SMTP capabilities > 3) IMAP annotations > 4) Something else > 5) Nothing > > Note that I've left document organization out of the poll. If people > feel strongly about that they can argue about it. 2) for auto-configuration. I am still deciding between 1) and 3) on IMAP side. If the information can be different for different messages, then a new IMAP capability is a wrong way to do this. In this case IMAP per-message annotations are a better fit, but I do have some concerns about deployability. > > Lisa > > > On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov > > wrote: > > Hi Murray, > Some quick comments about your IMAP proposal that uses ANNOTATE. > > >3. IMAP Server Implementation > > > > An [IMAP] server conforming to this specification MUST implement > > [ANNOTATE] and MUST report these annotations to the client if they > > are attached to the message(s) being requested. > > > > > The second MUST: I am not sure what you are trying to say here. If you > are saying that the new annotations must be reported whenever the > corresponding message body is send (or similar), then that is not how > the ANNOTATE extension works. > [...] > > >5.1. Formal Definition > > > > The content of the annotation, as defined using [ABNF], is as > > follows: > > > > authres = 1*( version ":" authserv-id ":" methodspec > > ":" propspec ) > > ; relays a single unit of authentication results > > ; information > > > > > Are you trying to list multiple authresults here? I think you are > missing some delimiter between individual values, e.g. SP. > > _______________________________________________ > 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 > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DA8Nib078144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 03:08:23 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DA8NdH078141; Mon, 13 Oct 2008 03:08:23 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DA8Bjt078060; Mon, 13 Oct 2008 03:08:22 -0700 (MST) (envelope-from arnt@oryx.com) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id EAF664AC95; Mon, 13 Oct 2008 12:08:07 +0200 (CEST) Received: from arnt@oryx.com (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1223892487-66249-3650 (5 recipients); Mon, 13 Oct 2008 12:08:07 +0200 Message-Id: <2QS9LqMYTRX1oMg1BXsm+A.md5@lochnagar.oryx.com> Date: Mon, 13 Oct 2008 12:06:29 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org, ietf-smtp@imc.org, mail-vet-discuss@mipassoc.org Subject: Re: Straw consensus call on auth-header draft Cc: Lisa Dusseault References: In-Reply-To: Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I read the auth-* drafts. Lisa Dusseault writes: > I'd like to do a more explicit consensus call now to nail this down. > I've tried to identify the major points of attraction rather than > every variant, to see where people are leaning. Please reply with > one of these options, a variant, and explanation if you like: > > A) auth-header to not require any feature advertising or auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising > C) auth-header to normatively REQUIRE some kind of feature advertising I don't like auth-header, but if any, then A. Comments and stuff. 1. Auth-header tells MTAs to add two (or more?) trace fields. The document doesn't specify order, so if it's not clear what was added by y below: Received: by x ... Authentication-Results: (1) ... (dkim stuff) Received: by y ... Authentication-Results: (2) ... (dkim stuff) Authentication-Results: (3) ... (iprev stuff) Received: by z ... Y might have added 1, 2 or 2+3, right? Difficult to handle. Particularly if the analysis code wants to detect or handle reordered headers. This could be fixed by adding a new level of hierarchy between header and field. Call it trace-field-group. But we have that for Resent-* and IMO that's one of the reasons Resent-* has faded from view. Another solution would be to write this information inside the Received field. 2. I've noticed that some DKIM implementations like to sign every field they see, which might include auth-headers. The auth-header draft says to remove old auth-headers, breaking such signatures. That conflict needs advice, or at least a security consideration. 3. The reason I don't like advertising is that many people use so very complex delivery chains. Transmitting capability advertising from start to end is hard. Better to design the stuff so that's not needed. 4. Why isn't there a sieve extension to let people filter mail on this? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9CNiqSX043868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 16:44:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9CNiqF2043867; Sun, 12 Oct 2008 16:44:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9CNieEf043850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 16:44:51 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.0.3] (adsl-68-122-70-138.dsl.pltn13.pacbell.net [68.122.70.138]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m9CNicq7024549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 16:44:39 -0700 Message-ID: <48F28BE6.1060509@dcrocker.net> Date: Sun, 12 Oct 2008 16:44:38 -0700 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: Straw consensus call on auth-header draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/8414/Sat Oct 11 20:30:50 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 12 Oct 2008 16:44:39 -0700 (PDT) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I'd like to do a more explicit consensus call now to nail this down. > I've tried to identify the major points of attraction rather than every > variant, to see where people are leaning. Please reply with one of > these options, a variant, and explanation if you like: > > A) auth-header to not require any feature advertising or auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising > C) auth-header to normatively REQUIRE some kind of feature advertising Lisa, Your alternatives B & C appear to seek normative technical language that refers to something that does not exist. Further, a phrase like "some kind of" makes it rather difficult to know whether the 'requirement' is satisfied. It is generally ill-advised to have a specification make statements about the unknown future, which of course means anything in the future. It seems an even poorer choice to make that statement be normative, without specifying the details of that future precisely. So, please clarify how can a technical specification contain normative language to cover something that doesn't exist? More precisely, what does it mean to include such language, in terms of actual development or operation? What impact does such a statement have on the current specification? On use of it? The alternative seems to be to require the current specification to wait until there is an approved specification for advertising/configuration that can then, in turn, be recommended or required (presumably SHOULD OR MUST, respectively?) ps. But to conform to the precise confines of your exercise, I suggest Alternative A, since there are many operational environments for which manual configuration works just fine. In those environments, advertising and configuration mechanisms add complexity without benefit. pps. What are examples of similar mechanisms, for application-level advertising or auto-configuration, that are already in Internet-scale use? Knowing the answer to this can give some guidance about the likely risk of mandating such a mechanism here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9CLTO75036203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 14:29:24 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9CLTORk036201; Sun, 12 Oct 2008 14:29:24 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.241]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9CLTC8C036186 for ; Sun, 12 Oct 2008 14:29:23 -0700 (MST) (envelope-from lisa.dusseault@gmail.com) Received: by rv-out-0708.google.com with SMTP id c5so1232454rvf.34 for ; Sun, 12 Oct 2008 14:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=rJiAvE/bramwsm6SvvpgjuliagTArGiPYdBlEbBS21M=; b=N74xYhnVvNDEEHm85bVPqngT+1RRDk7WByPK/ZWIsLZq9KiwqpuDj487au/yAtR828 a615QT6oozWKWZj3aLwV85oIseSn5B4hXLY5yNuCw5QZUiOcNA7YvRGDoVGDoSNww7/4 Gy3iKXzbmAMOhev9phfrzlS3rxmKybdPGBBxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=W6VgCOEczeuOVwr0R18XZ6+Zqi91PbFlVBZSoWiPjfucBEIOySeeBBHHcrr8dNiREC 7LQwnByfFnjggG1Cu/qkoXhTYtBcR5cAT0buThzw16IQBtgzeWpwW/hOUnQRhdTOvk9A Fp7rohxMlPOfHEjOYabl1yIawmwSPVTj9rVU8= Received: by 10.140.165.21 with SMTP id n21mr3141685rve.97.1223846952025; Sun, 12 Oct 2008 14:29:12 -0700 (PDT) Received: by 10.140.173.21 with HTTP; Sun, 12 Oct 2008 14:29:11 -0700 (PDT) Message-ID: Date: Sun, 12 Oct 2008 14:29:11 -0700 From: "Lisa Dusseault" To: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Straw consensus call on auth-header draft MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_127225_14626098.1223846951999" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_Part_127225_14626098.1223846951999 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'd like to do a more explicit consensus call now to nail this down. I've tried to identify the major points of attraction rather than every variant, to see where people are leaning. Please reply with one of these options, a variant, and explanation if you like: A) auth-header to not require any feature advertising or auto-configuration B) auth-header to normatively RECOMMEND some kind of feature advertising C) auth-header to normatively REQUIRE some kind of feature advertising Separately, the unspecified feature advertising or auto-conf should be (choose one or more): 1) IMAP Capabilities advertising 2) E/SMTP capabilities 3) IMAP annotations 4) Something else 5) Nothing Note that I've left document organization out of the poll. If people feel strongly about that they can argue about it. Lisa On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov wrote: > Hi Murray, > Some quick comments about your IMAP proposal that uses ANNOTATE. > > >3. IMAP Server Implementation > > > > An [IMAP] server conforming to this specification MUST implement > > [ANNOTATE] and MUST report these annotations to the client if they > > are attached to the message(s) being requested. > > > > > The second MUST: I am not sure what you are trying to say here. If you > are saying that the new annotations must be reported whenever the > corresponding message body is send (or similar), then that is not how > the ANNOTATE extension works. > [...] > > >5.1. Formal Definition > > > > The content of the annotation, as defined using [ABNF], is as > > follows: > > > > authres = 1*( version ":" authserv-id ":" methodspec > > ":" propspec ) > > ; relays a single unit of authentication results > > ; information > > > > > Are you trying to list multiple authresults here? I think you are > missing some delimiter between individual values, e.g. SP. > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > ------=_Part_127225_14626098.1223846951999 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I'd like to do a more explicit consensus call now to nail this down.  I've tried to identify the major points of attraction rather than every variant, to see where people are leaning.   Please reply with one of these options, a variant, and explanation if you like:

A)  auth-header to not require any feature advertising or auto-configuration
B) auth-header to normatively RECOMMEND some kind of feature advertising
C) auth-header to normatively REQUIRE some kind of feature advertising

Separately, the unspecified feature advertising or auto-conf should be (choose one or more):
1) IMAP Capabilities advertising
2) E/SMTP capabilities
3) IMAP annotations
4) Something else
5) Nothing

Note that I've left document organization out of the poll.  If people feel strongly about that they can argue about it.

Lisa


On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Hi Murray,
Some quick comments about your IMAP proposal that uses ANNOTATE.

>3.  IMAP Server Implementation
>
>   An [IMAP] server conforming to this specification MUST implement
>   [ANNOTATE] and MUST report these annotations to the client if they
>   are attached to the message(s) being requested.
>
>
The second MUST: I am not sure what you are trying to say here. If you
are saying that the new annotations must be reported whenever the
corresponding message body is send (or similar), then that is not how
the ANNOTATE extension works.
 [...]

>5.1.  Formal Definition
>
>   The content of the annotation, as defined using [ABNF], is as
>   follows:
>
>      authres = 1*( version ":" authserv-id ":" methodspec
>                            ":" propspec )
>              ; relays a single unit of authentication results
>              ; information
>
>
Are you trying to list multiple authresults here? I think you are
missing some delimiter between individual values, e.g. SP.

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

------=_Part_127225_14626098.1223846951999-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O29GRR058448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 19:09:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9O29Gxn058446; Thu, 23 Oct 2008 19:09:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from blu0-omc3-s8.blu0.hotmail.com (blu0-omc3-s8.blu0.hotmail.com [65.55.116.83]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O295K4058428; Thu, 23 Oct 2008 19:09:15 -0700 (MST) (envelope-from markrcrispin@live.com) Received: from BLU126-W22 ([65.55.116.72]) by blu0-omc3-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Oct 2008 19:07:55 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_2b333ddd-2963-4a09-9d07-78b8bbdb2159_" X-Originating-IP: [206.124.149.116] From: Mark Crispin To: Douglas Otis , "Murray S. Kucherawy" CC: , , Mail-Vet-Discuss Subject: RE: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Thu, 23 Oct 2008 19:07:55 -0700 Importance: Normal In-Reply-To: References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> <4900C737.7070000@sendmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Oct 2008 02:07:55.0935 (UTC) FILETIME=[545D3AF0:01C9357D] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_2b333ddd-2963-4a09-9d07-78b8bbdb2159_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 > From: dotis@mail-abuse.org > Get rid of the sales hype describing everything as "authentication". =20 > Security is no time for muddled or misused terminology. There is no =20 > reason to mislead recipients any more than they already are. _________________________________________________________________ When your life is on the go=97take your life with you. http://clk.atdmt.com/MRT/go/115298558/direct/01/= --_2b333ddd-2963-4a09-9d07-78b8bbdb2159_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1

>=3B From: dotis@mail-abuse.org
>=3B Get rid of the sales = hype describing everything as "authentication".
>=3B Security is no= time for muddled or misused terminology. There is no
>=3B reason t= o mislead recipients any more than they already are.


Whe= n your life is on the go=97take your life with you. Try Windows Mobile=AE= today = --_2b333ddd-2963-4a09-9d07-78b8bbdb2159_-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O13Fhm055999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 18:03:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9O13FnC055998; Thu, 23 Oct 2008 18:03:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9O134YW055987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 18:03:14 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 59765A9443D; Fri, 24 Oct 2008 01:03:01 +0000 (UTC) Cc: ietf-imapext@imc.org, ietf-smtp@imc.org, Mail-Vet-Discuss Message-Id: From: Douglas Otis To: "Murray S. Kucherawy" In-Reply-To: <4900C737.7070000@sendmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Thu, 23 Oct 2008 18:03:00 -0700 References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> <4900C737.7070000@sendmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 23, 2008, at 11:49 AM, Murray S. Kucherawy wrote: > Douglas Otis wrote: >> The ADSP draft inhibits an assurance regarding _what_ the signing >> domain authenticated! The Author Signature definition limits a >> signing-domain's associated "on-behalf-of" identifier to being an >> email address within the From header field or to being _blank_. >> As a result, any intra-domain abuse can not be safely identified. >> One would be mistaken to assume the From email-address is always >> what a signing domain authenticates. No other assumption would be >> available without incurring an impractical second signature that is >> likely ignored anyway. Should one care about the damage created by >> an incorrect assumption regarding authentication, even when the >> assumption is signed by the border MTA? Perhaps this could be call >> the Assumed-Authentication-Results header. : ) >> >> -Doug > > Doug, > > I'm pretty sure you're talking about the reliability/assertions of > ADSP or even DKIM. That's orthogonal to what we're discussing here > on mail-vet-discuss. This draft is about moving the evaluation > results from an MTA to MUAs in a consistent and reliable manner. > That the evaluations themselves could conceivably be flawed or > subverted is already discussed in Security Considerations for this > draft and is not within the scope of this document. I responded to a different message on mail-vet and dkim. Here is the portion that attempts to explain the concern: A security mechanism should not recklessly abuse the term Authentication. The term Authentication is _dangerously_ misleading for most methods logged by this header. The term "Authentication" should be replaced by a neutral term "method" within draft where possible. It would not be too misleading to use the terms "Authentication or Authorization" instead of just "Authentication" within a few sentences. A header label "Source-Results" would be less deceptive in respect to the nature of the results obtained. The term Authentication is being misused more than 60 times through out this draft (ignoring the title and header labels). Admittedly the word "authorized" is buried in the definition of some results, but this term will _never_ be evident to the user. Do you see the danger using the header label "Authentication-Results:"? The draft's introductory statement does not help much either: "At the time of publication of this draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the published e-mail authentication methods in common use." Authentication methods? Really? It is _dangerous_ and _misleading_ to suggest that an SMTP client _authorization_ method results in the "authentication" of the PRA, MAILFROM, the valid origination of the message as stated in this draft. An _unauthorized_ SMTP client MAY be an indication of the invalid use of a MAILFROM or PRA, however an authorized SMTP client must not be assumed to indicate the valid use of an email-address, as suggested by the overused term "Authentication" through out this draft. Describing an authorization method as being an authentication method results in a dangerous misrepresentation of the results produced for most of the methods currently defined, even for DKIM-ADSP at this time. Get rid of the sales hype describing everything as "authentication". Security is no time for muddled or misused terminology. There is no reason to mislead recipients any more than they already are. -Doug Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NInDAH037308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 11:49:13 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9NInDox037307; Thu, 23 Oct 2008 11:49:13 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NIn1jS037288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Oct 2008 11:49:12 -0700 (MST) (envelope-from msk@sendmail.com) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m9NInfTj028332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 23 Oct 2008 11:49:41 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1224787781; bh=ZIWDsLDfqovbcbs6WKsihAPQMDnYIztWu7x9 UiPFiao=; h=Received:X-DKIM:DKIM-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=PB9xyBRoEa 1JF/KddSuxr0xcsd8cVCdRVYLdlcNBs7CJLkuWSvTZiOdCTvsCqcBnMT6vKlvslwDpQ +CQu5pBqvNYirzyllOVP6D0zRc8bBgAy1s8NLh1q74zsTWxivaLj0zBFoK8pU8yPnVs 4I2k8vxHquY1PClpf9/D+BqKg7I= Received: from [10.210.202.7] ([10.210.202.7]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m9NImmBV029107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 11:48:50 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m9NImmBV029107 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1224787731; bh=ZIWDsLDfqovbcbs6WKsihAPQMDnYIztWu7x9 UiPFiao=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=akMYIQvcyyLP7+Dh0XZOV12 9osnqhwYx9C3zfdo3+nM471A2TrbbCahlMp3VqPs1OKY8aFc8QRegT+Hfc1e9utyiM4 2oblX8/+fI7LvQZdUPEmhAZNzDwE44uVMKJqag6WrcRH75SICVeVWRPR27CF4zWwLef rsakPFc5/CgKhs= Message-ID: <4900C737.7070000@sendmail.com> Date: Thu, 23 Oct 2008 11:49:27 -0700 From: "Murray S. Kucherawy" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Douglas Otis CC: Dave CROCKER , ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MM-Ex-RefId: 149371::081023114851-06A3EB90-2DC2386A/0-0/0-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Douglas Otis wrote: > The ADSP draft inhibits an assurance regarding _what_ the signing > domain authenticated! The Author Signature definition limits a > signing-domain's associated "on-behalf-of" identifier to being an > email address within the From header field or to being _blank_. As > a result, any intra-domain abuse can not be safely identified. One > would be mistaken to assume the From email-address is always what a > signing domain authenticates. No other assumption would be available > without incurring an impractical second signature that is likely > ignored anyway. Should one care about the damage created by an > incorrect assumption regarding authentication, even when the > assumption is signed by the border MTA? Perhaps this could be call > the Assumed-Authentication-Results header. : ) > > -Doug > Doug, I'm pretty sure you're talking about the reliability/assertions of ADSP or even DKIM. That's orthogonal to what we're discussing here on mail-vet-discuss. This draft is about moving the evaluation results from an MTA to MUAs in a consistent and reliable manner. That the evaluations themselves could conceivably be flawed or subverted is already discussed in Security Considerations for this draft and is not within the scope of this document. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9M06ESx027714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 17:06:14 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9M06Eds027713; Tue, 21 Oct 2008 17:06:14 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9M062jm027702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Oct 2008 17:06:13 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 5BCFAA9443C; Wed, 22 Oct 2008 00:06:02 +0000 (UTC) Cc: Dave CROCKER , ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Message-Id: From: Douglas Otis To: "Murray S. Kucherawy" In-Reply-To: <48F50E27.9080502@sendmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Tue, 21 Oct 2008 17:06:01 -0700 References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 14, 2008, at 2:24 PM, Murray S. Kucherawy wrote: > > Douglas Otis wrote: >> Agreed. However, when a domain attempts to assert control over the >> From header field using DKIM and ADSP, they must "pretend" to >> authenticate an email-address within the From header field. > > I don't think we're talking about any such assertions here. We're > only interested in protecting an Authentication-Results: header > added by a border MTA on inbound mail. Seems like ADSP and even > From: are somewhat irrelevant to this discussion. The ADSP draft inhibits an assurance regarding _what_ the signing domain authenticated! The Author Signature definition limits a signing-domain's associated "on-behalf-of" identifier to being an email address within the From header field or to being _blank_. As a result, any intra-domain abuse can not be safely identified. One would be mistaken to assume the From email-address is always what a signing domain authenticates. No other assumption would be available without incurring an impractical second signature that is likely ignored anyway. Should one care about the damage created by an incorrect assumption regarding authentication, even when the assumption is signed by the border MTA? Perhaps this could be call the Assumed-Authentication-Results header. : ) -Doug Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FAJA3F089353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 03:19:10 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9FAJAK3089351; Wed, 15 Oct 2008 03:19:10 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from winserver.com (mail.winserver.com [208.247.131.9]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9FAIwSo089316 for ; Wed, 15 Oct 2008 03:19:09 -0700 (MST) (envelope-from hsantos@santronics.com) Received: by winserver.com (Wildcat! SMTP Router v6.3.452.5) for ietf-imapext@imc.org; Wed, 15 Oct 2008 06:20:31 -0400 Received: from hdev1 ([72.144.161.85]) by winserver.com (Wildcat! SMTP v6.3.452.5) with ESMTP id 3721354984; Wed, 15 Oct 2008 06:20:29 -0400 Message-ID: <48F5C338.5000101@santronics.com> Date: Wed, 15 Oct 2008 06:17:28 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: Straw consensus call on auth-header draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I'd like to do a more explicit consensus call now to nail this down. > I've tried to identify the major points of attraction rather than every > variant, to see where people are leaning. Please reply with one of > these options, a variant, and explanation if you like: > > A) auth-header to not require any feature advertising or auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising > C) auth-header to normatively REQUIRE some kind of feature advertising "C" for having a reason for living (implementing it). Otherwise, whats the point? "A" will further create fuzzy unknowns about trust. While B is the middle ground, it is just as bad as A. > Separately, the unspecified feature advertising or auto-conf should be > (choose one or more): > 1) IMAP Capabilities advertising > 2) E/SMTP capabilities > 3) IMAP annotations > 4) Something else > 5) Nothing Thats just it. Whats it for? The only use I see for it is to pass intra-process (internal) state information, i.e. so that a 2nd trusted process doesn't have to "re-do" whatever the first trusted process did. For an Internal MUA (a trusted process), it can be used for state information. Why and When would a offline MUA, for example, trust and make use of this information? In terms of DKIM, does it replace the need for an MUA to do DKIM verification? -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EM4tDg040133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 15:04:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EM4t0b040130; Tue, 14 Oct 2008 15:04:55 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EM4hhS040106; Tue, 14 Oct 2008 15:04:54 -0700 (MST) (envelope-from steve@blighty.com) Received: from platter.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id E26D8800C2; Tue, 14 Oct 2008 15:04:40 -0700 (PDT) Message-Id: <9E521D40-B2A6-4782-B9AA-D3A5D8773F55@blighty.com> From: Steve Atkins To: SMTP Interest Group , ietf-imapext@imc.org, Mail-Vet-Discuss In-Reply-To: <48F50E27.9080502@sendmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Tue, 14 Oct 2008 15:04:42 -0700 References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> <48F50E27.9080502@sendmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: (I expect this message to be rejected by at least some of the mailing lists it was CCed to). On Oct 14, 2008, at 2:24 PM, Murray S. Kucherawy wrote: > > Douglas Otis wrote: >> Agreed. However, when a domain attempts to assert control over the >> From header field using DKIM and ADSP, they must "pretend" to >> authenticate an email-address within the From header field. > > I don't think we're talking about any such assertions here. We're > only interested in protecting an Authentication-Results: header > added by a border MTA on inbound mail. Seems like ADSP and even > From: are somewhat irrelevant to this discussion. > If it's added by a border MTA, so it's only seen by your network after the header is added, what are you protecting it against? Cheers, Steve Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ELP1Zw036922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 14:25:01 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9ELP1hg036921; Tue, 14 Oct 2008 14:25:01 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9ELOmJU036889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 14:25:00 -0700 (MST) (envelope-from msk@sendmail.com) Received: from spork.sendmail.com (tls.sendmail.com [209.246.26.41]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m9ELPCdG000839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Oct 2008 14:25:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1224019512; bh=ujT8QwH5fdaiMnFMa09sN5QtiZgPiP9TM5Ub uIH4xC8=; h=Received:X-DKIM:DKIM-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=phTB0hRRQ7 9a7QExGved090I4Anc97IEQPOnN1qqptL52v9l35aHI7Yp2gPP381CUSzXjH9q04YHT aXSqwU8+Ui3gMpoZtpKn8EUd8lxfNaFRC+km1qzjMUEmsSVvnwct4s3l7g23OY9JynL WWFPuXUE+lC4eYVcRCX1L81YAJA= Received: from [10.210.202.7] ([10.210.202.7]) (authenticated bits=0) by spork.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m9ELOReK029287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 14:24:34 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 spork.sendmail.com m9ELOReK029287 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=spork.dkim; t=1224019476; bh=ujT8QwH5fdaiMnFMa09sN5QtiZgPiP9TM5Ub uIH4xC8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=eEdWOUmXgI12OHsqJlwBcvG 4688pSwlnM+Fk0Sf9gZbPopRnOfyB3CWls1PEUkpW/n9du0vxXWmv/xlFxG0nsVM13G EdgzkO6ojiVu4PYi/wk7mrJcHp1HEgpdYX6sSfwYrRFUwnG4H6uhB6L4Fnn//92ugBq LfkhB7cLZck6u8= Message-ID: <48F50E27.9080502@sendmail.com> Date: Tue, 14 Oct 2008 14:24:55 -0700 From: "Murray S. Kucherawy" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Douglas Otis CC: dcrocker@bbiw.net, ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> In-Reply-To: <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MM-Ex-RefId: 149371::081014142435-5AD7AB90-5CE9F3EB/0-0/0-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Douglas Otis wrote: > Agreed. However, when a domain attempts to assert control over the > From header field using DKIM and ADSP, they must "pretend" to > authenticate an email-address within the From header field. I don't think we're talking about any such assertions here. We're only interested in protecting an Authentication-Results: header added by a border MTA on inbound mail. Seems like ADSP and even From: are somewhat irrelevant to this discussion. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EGqRsj013773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 09:52:27 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EGqRr1013772; Tue, 14 Oct 2008 09:52:27 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EGqGmF013757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 09:52:26 -0700 (MST) (envelope-from dotis@mail-abuse.org) Received: from [127.0.0.1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 194B7A94443; Tue, 14 Oct 2008 16:52:16 +0000 (UTC) Cc: dcrocker@bbiw.net, ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Message-Id: <0504E530-67BB-479B-BC84-416365183338@mail-abuse.org> From: Douglas Otis To: "Murray S. Kucherawy" In-Reply-To: <48F3A85B.8020906@sendmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft Date: Tue, 14 Oct 2008 09:52:13 -0700 References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 13, 2008, at 12:58 PM, Murray S. Kucherawy wrote: > > Dave CROCKER wrote: >> This begs the question: why bother to do the first validation; why >> not simply wait and let whoever would have validated the first >> instead validate the first? > > If the only authentication method being applied at a site is DKIM or > other things that don't care about the path, that works. But that's > a big "if", and moreover means all consumers of authentication > results data must now learn all local path-agnostic methods being > used to evaluate messages. > > The desire here is to secure arbitrary authentication results data > between the border MTA and the consuming MUA. DKIM is one way that > could be achieved, meaning the consumers need to learn one and only > one message authentication scheme in order to validate that one > piece of protected internal data. Agreed. However, when a domain attempts to assert control over the From header field using DKIM and ADSP, they must "pretend" to authenticate an email-address within the From header field. ADSP, using a false premise of email-address authentication, has impaired DKIM's on-behalf-of field which is essential for evaluating intra- domain abuse. If the source of a message is not abusive, there should be no reason to filter based upon content classifications. In the case of ADSP, there no basis upon which classifications can be trusted. The one exception would be for a perfect signing domain, otherwise these efforts represent an exercise in futility. -Doug Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EFwu2W009442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 08:58:56 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9EFwufm009440; Tue, 14 Oct 2008 08:58:56 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EFwhCg009425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 08:58:54 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.1.118] (static-66-14-247-16.bdsl.verizon.net [66.14.247.16]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m9EFwek6001851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 08:58:41 -0700 Message-ID: <48F4B5B9.60202@dcrocker.net> Date: Tue, 14 Oct 2008 11:07:37 -0400 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Murray S. Kucherawy" CC: ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> <48F3A85B.8020906@sendmail.com> In-Reply-To: <48F3A85B.8020906@sendmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/8423/Tue Oct 14 05:36:14 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 14 Oct 2008 08:58:43 -0700 (PDT) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Murray, Interesting and intriguing perspective. I like it. Perhaps I missed it, but I don't recall seeing such a coherent, focused and pragmatic requirements statement in this discussion, so far. But note that what you are describing has nothing specific to mail-vet. Really. You are describing a generic requirement for trusted information exchange between two nodes that are possibly within a trust domain. The fact that the information is, itself, security-related might affect some choices in the design, but not in a way that is specific to mail-vet (or the fact that it is security-releated...) The other that might be a bit different is to protect a specified header field. Again, I doubt that affects design choices all that much. So mail-vet *might* be motivating it, but it is really an independent technical requirement. It warrants an independent technical specification. Let me repeat this: To the extent that the current specification is for a data format, rather than an end-to-end exchange service, then an effort to satisfy this requirement belongs to a separate document. And, of course, there are *lots* of ways to satisfy it. That's a further reason to avoid burdening the current, core data spec with its details. d/ Murray S. Kucherawy wrote: > Dave CROCKER wrote: >> This begs the question: why bother to do the first validation; why >> not simply wait and let whoever would have validated the first instead >> validate the first? > > If the only authentication method being applied at a site is DKIM or > other things that don't care about the path, that works. But that's a > big "if", and moreover means all consumers of authentication results > data must now learn all local path-agnostic methods being used to > evaluate messages. > > The desire here is to secure arbitrary authentication results data > between the border MTA and the consuming MUA. DKIM is one way that > could be achieved, meaning the consumers need to learn one and only one > message authentication scheme in order to validate that one piece of > protected internal data. > -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9E11Hpt029917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 18:01:17 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9E11H7S029916; Mon, 13 Oct 2008 18:01:17 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9E115pL029902; Mon, 13 Oct 2008 18:01:16 -0700 (MST) (envelope-from sm@resistor.net) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.3/8.14.3) with ESMTP id m9E10s7i006548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 18:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1223946064; x=1224032464; bh=Tt/cVfQkqnABDIIN0ReaRgJjzEGNYxI05qD0 O36ZbVo=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=T4TFQpIduaQcYbkl0uVriQ+X27OXanREvi mRh2MAeq0+tzscI2ptT/bAW7oudv9s8/4jNYWlvOjNfUY1RTZLOSMV/mwUKkYl4cs1T LZeKmt5hOfCNBv2OSpAyXzJRQcP4UPXHxLca7iGlk9AqBqul3QOKA33ejU/5uEaPUre /74= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=0dLPOhxF9IkKp1bjulFpEisaT5XvhM9Bgdj8nCx6wWGWyqi+xyOqTvVF5LPYOTmst K9QWiFmmiM4xDQttJW4Ze9cGsuL/LxROM/v2UjnqOUh9f8l28brtk7jr+w7osjzw1pd 16R+G58z/14hz/xPBCOZrJ9FqEgDinc9pIYTF2M= Message-Id: <6.2.5.6.2.20081013174044.02ed0e58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 13 Oct 2008 18:00:15 -0700 To: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org From: SM Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 14:29 12-10-2008, Lisa Dusseault wrote: >I'd like to do a more explicit consensus call now to nail this >down. I've tried to identify the major points of attraction rather >than every variant, to see where people are leaning. Please reply >with one of these options, a variant, and explanation if you like: > >A) auth-header to not require any feature advertising or auto-configuration I'm for (A). >B) auth-header to normatively RECOMMEND some kind of feature advertising >C) auth-header to normatively REQUIRE some kind of feature advertising I gather that you are referring to advertising for the MUA through POP3 and IMAP. >Separately, the unspecified feature advertising or auto-conf should >be (choose one or more): >1) IMAP Capabilities advertising >2) E/SMTP capabilities >3) IMAP annotations >4) Something else >5) Nothing I'm for (5). Regards, -sm Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJw8Dc031341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:58:08 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DJw8XW031339; Mon, 13 Oct 2008 12:58:08 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJw6uX031327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 12:58:07 -0700 (MST) (envelope-from msk@sendmail.com) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m9DJwV5v022662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 12:58:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1223927912; bh=x3NzhqUxTxml7L20sLw7WkKokN1aEarIsX2x 05NdSYc=; h=Received:X-DKIM:DKIM-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=HcNTAhOXkf pNwX1bwLjJd4vu8nNEKz876SrBtlPjksEiDU1kaWG+FvXRCg8R/uf7YapUGYM4i5sy+ +Q7Toxvp/szK95cyeg8I8y4SBPydsS7lpgKEDHefbD48L7bWlFdDS6TPMllF32dnWUV 8dtgR7fSKbJ7ngMqmLFkqmFH5ec= Received: from [10.210.202.7] ([10.210.202.7]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m9DJvq7g025259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:57:52 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 fife.sendmail.com m9DJvq7g025259 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1223927876; bh=x3NzhqUxTxml7L20sLw7WkKokN1aEarIsX2x0 5NdSYc=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=6z5rbqytB9+YHL7Nd012HPF d4TTUR7qjxaiOcHXsgHOoTV4R83Jx3YYFsBOeUOs0EqnwPTetckNjJjnYLlQ0cpCXjg ULvyQ9BMOp3z7euLX8RSewo8XkwBTysJO6Uvr2UfHRtPGQVddHsxp3PQvDKkMV6RYM8 L+il3Fi71YGCkg= Message-ID: <48F3A85B.8020906@sendmail.com> Date: Mon, 13 Oct 2008 12:58:19 -0700 From: "Murray S. Kucherawy" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: dcrocker@bbiw.net CC: ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> <48F3A198.2080700@dcrocker.net> In-Reply-To: <48F3A198.2080700@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MM-Ex-RefId: 149371::081013125756-75714B90-17C908C1/0-0/0-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave CROCKER wrote: > This begs the question: why bother to do the first validation; why > not simply wait and let whoever would have validated the first instead > validate the first? If the only authentication method being applied at a site is DKIM or other things that don't care about the path, that works. But that's a big "if", and moreover means all consumers of authentication results data must now learn all local path-agnostic methods being used to evaluate messages. The desire here is to secure arbitrary authentication results data between the border MTA and the consuming MUA. DKIM is one way that could be achieved, meaning the consumers need to learn one and only one message authentication scheme in order to validate that one piece of protected internal data. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJpGFr031033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:51:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DJpGDD031032; Mon, 13 Oct 2008 12:51:16 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJpF3X031021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:51:15 -0700 (MST) (envelope-from dcrocker@bbiw.net) Received: from [10.1.129.77] ([66.103.88.194]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m9DJpDqV026628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:51:14 -0700 Message-ID: <48F3A68F.4010002@bbiw.net> Date: Mon, 13 Oct 2008 15:50:39 -0400 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: Straw consensus call on auth-header draft References: <48F28BE6.1060509@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/8417/Mon Oct 13 00:34:29 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 13 Oct 2008 12:51:14 -0700 (PDT) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: >> So, please clarify how can a technical specification contain normative >> language to cover something that doesn't exist? More precisely, what >> does it mean to include such language, in terms of actual development >> or operation? What impact does such a statement have on the current >> specification? On use of it? > > Since that's not what I'm suggesting, I can't answer these questions. It isn't? Since your language was "normatively * some kind of feature advertising" then I am entirely confused. The feature advertising for this does not yet exist. You cite normatively referring to such advertising. How did I mis-characterize your query? >> The alternative seems to be to require the current specification to >> wait until there is an approved specification for >> advertising/configuration that can then, in turn, be recommended or >> required (presumably SHOULD OR MUST, respectively?) > > That could be. That's useful input, since it can level-set folks' expectations. >> pps. What are examples of similar mechanisms, for application-level >> advertising or auto-configuration, that are already in Internet-scale >> use? Knowing the answer to this can give some guidance about the >> likely risk of mandating such a mechanism here. > > IMAP and SMTP have lots of application-level capabilities advertising. > Sometimes this can aid auto-configuration. Hmmm. Maybe it's jet-lag. I'm not thinking of which ones you might have in mind. I'd really appreciate some particulars, for advertising security-related features that rely on being within a trust boundary and are widely adopted and used. What existing mechanisms qualify? Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJUE1l030156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:30:15 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DJUEBY030154; Mon, 13 Oct 2008 12:30:14 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DJU3eQ030138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:30:14 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [10.1.129.77] ([66.103.88.194]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m9DJU1iU026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 12:30:02 -0700 Message-ID: <48F3A198.2080700@dcrocker.net> Date: Mon, 13 Oct 2008 15:29:28 -0400 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Murray S. Kucherawy" CC: ietf-imapext@imc.org, Mail-Vet-Discuss , ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: <48F38765.30508@sendmail.com> In-Reply-To: <48F38765.30508@sendmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/8417/Mon Oct 13 00:34:29 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 13 Oct 2008 12:30:03 -0700 (PDT) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Murray S. Kucherawy wrote: > 4 would include DKIM signing. I'd be fine with adding a SHOULD there. SHOULD? You would specify a normative SHOULD for protecting a DKIM validation with a(nother) DKIM signature? This begs the question: why bother to do the first validation; why not simply wait and let whoever would have validated the first instead validate the first? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DHvBCB023337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 10:57:11 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DHvB32023334; Mon, 13 Oct 2008 10:57:11 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from leka.osafoundation.org (leka.osafoundation.org [64.127.108.190]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DHv06L023316; Mon, 13 Oct 2008 10:57:10 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by leka.osafoundation.org (Postfix) with ESMTP id 2A6A43E3722; Mon, 13 Oct 2008 10:57:00 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from leka.osafoundation.org ([127.0.0.1]) by localhost (leka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs4EexzzhkyD; Mon, 13 Oct 2008 10:56:55 -0700 (PDT) Received: from [192.168.1.102] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by leka.osafoundation.org (Postfix) with ESMTP id 4CFBD3E36F0; Mon, 13 Oct 2008 10:56:55 -0700 (PDT) Cc: Lisa Dusseault , Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Message-Id: From: Lisa Dusseault To: dcrocker@bbiw.net In-Reply-To: <48F28BE6.1060509@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: Straw consensus call on auth-header draft Date: Mon, 13 Oct 2008 10:56:54 -0700 References: <48F28BE6.1060509@dcrocker.net> X-Mailer: Apple Mail (2.929.2) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Oct 12, 2008, at 4:44 PM, Dave CROCKER wrote: > > > > Lisa Dusseault wrote: >> I'd like to do a more explicit consensus call now to nail this >> down. I've tried to identify the major points of attraction rather >> than every variant, to see where people are leaning. Please reply >> with one of these options, a variant, and explanation if you like: >> A) auth-header to not require any feature advertising or auto- >> configuration >> B) auth-header to normatively RECOMMEND some kind of feature >> advertising >> C) auth-header to normatively REQUIRE some kind of feature >> advertising > > > Lisa, > > Your alternatives B & C appear to seek normative technical language > that refers to something that does not exist. Further, a phrase > like "some kind of" makes it rather difficult to know whether the > 'requirement' is satisfied. Yes, this is correct. I realize this is somewhat of a charter-phase question, but that's a risk with individual submissions going for Proposed Standard -- the risk that without a consensus-based charter, the scope of the work will be questioned. > > It is generally ill-advised to have a specification make statements > about the unknown future, which of course means anything in the > future. It seems an even poorer choice to make that statement be > normative, without specifying the details of that future precisely. Agreed. > > So, please clarify how can a technical specification contain > normative language to cover something that doesn't exist? More > precisely, what does it mean to include such language, in terms of > actual development or operation? What impact does such a statement > have on the current specification? On use of it? Since that's not what I'm suggesting, I can't answer these questions. > > > The alternative seems to be to require the current specification to > wait until there is an approved specification for advertising/ > configuration that can then, in turn, be recommended or required > (presumably SHOULD OR MUST, respectively?) That could be. > > ps. But to conform to the precise confines of your exercise, I > suggest Alternative A, since there are many operational environments > for which manual configuration works just fine. In those > environments, advertising and configuration mechanisms add > complexity without benefit. > > > pps. What are examples of similar mechanisms, for application-level > advertising or auto-configuration, that are already in Internet- > scale use? Knowing the answer to this can give some guidance about > the likely risk of mandating such a mechanism here. IMAP and SMTP have lots of application-level capabilities advertising. Sometimes this can aid auto-configuration. Lisa Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DHbWPB021999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 10:37:32 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DHbWCT021998; Mon, 13 Oct 2008 10:37:32 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DHbLQt021970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 10:37:31 -0700 (MST) (envelope-from msk@sendmail.com) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id m9DHbpZ2026915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 13 Oct 2008 10:37:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1223919471; bh=t55z7AjyLjsHBplzBKDSikavzQdZUw0MMZaL 8ExHZdA=; h=Received:X-DKIM:DKIM-Signature:Message-ID:Date:From: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:X-MM-Ex-RefId; b=Ak0x1gbWVc jGO8oEIDfbbKK3V0IGHWr4QnV3QizRKtZ/1mKcf9o6TLgCkDV24wYvif5OmhLrXLoRE Bvpia9bY0eKKrxDTXj+8MCZJl8gLkQUYuf9OyYe1SMGFcCoFTU2FqLspQGGrNljbBLV XcXL5XQUvlAj3LOEe6B92iPNMG8= Received: from [10.210.202.7] ([10.210.202.7]) (authenticated bits=0) by fife.sendmail.com (Switch-3.3.1/Switch-3.3.2mp) with ESMTP id m9DHbFbO005359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 10:37:16 -0700 X-DKIM: Sendmail DKIM Filter v2.2.3 fife.sendmail.com m9DHbFbO005359 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1223919437; bh=t55z7AjyLjsHBplzBKDSikavzQdZUw0MMZaL8 ExHZdA=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC: Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:X-MM-Ex-RefId; b=Zv8sbn3fNqhzTNW/N8yNJoJ MSxzRqUmGAGxH6h2k1cwfGLFaf5ktdL9K+4Oc2H/4oTABHXrrcYMXdqMrG9R9Dlt7Yu bIQlsgHSLIVsCrAG7mPne8o93ANOqw9/SyVbO7ipERPeAX8fISlVw+TrdDRxMN2MSfW jlaKV/NtmFEnmE= Message-ID: <48F38765.30508@sendmail.com> Date: Mon, 13 Oct 2008 10:37:41 -0700 From: "Murray S. Kucherawy" User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MM-Ex-RefId: 149371::081013103717-7571BB90-30BD82DE/0-0/0-1 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > A) auth-header to not require any feature advertising or auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising > C) auth-header to normatively REQUIRE some kind of feature advertising > I'm currently between A and B. I'm fine with referencing possible solutions, but I'm not sure I agree with the need for any normative language. > Separately, the unspecified feature advertising or auto-conf should be > (choose one or more): > 1) IMAP Capabilities advertising > 2) E/SMTP capabilities > 3) IMAP annotations > 4) Something else > 5) Nothing > I don't think 3 is relevant here. It specifies a different mechanism entirely. 1 & 2 are what the draft should mention as experimental possibilities. 4 would include DKIM signing. I'd be fine with adding a SHOULD there. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DA9ocL078276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 03:09:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DA9oA9078275; Mon, 13 Oct 2008 03:09:50 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DA9dPu078259; Mon, 13 Oct 2008 03:09:49 -0700 (MST) (envelope-from alexey.melnikov@isode.com) Received: from [172.16.2.195] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 13 Oct 2008 11:09:37 +0100 Message-ID: <48F31E58.2030101@isode.com> Date: Mon, 13 Oct 2008 11:09:28 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: [mail-vet-discuss] Straw consensus call on auth-header draft References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I'd like to do a more explicit consensus call now to nail this down. > I've tried to identify the major points of attraction rather than > every variant, to see where people are leaning. Please reply with > one of these options, a variant, and explanation if you like: > > A) auth-header to not require any feature advertising or > auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising I am in favour of B, but I want it to be described informatively with examples. (I.e. I think having a SHOULD would be a mistake) > C) auth-header to normatively REQUIRE some kind of feature advertising > > Separately, the unspecified feature advertising or auto-conf should be > (choose one or more): > 1) IMAP Capabilities advertising > 2) E/SMTP capabilities > 3) IMAP annotations > 4) Something else > 5) Nothing > > Note that I've left document organization out of the poll. If people > feel strongly about that they can argue about it. 2) for auto-configuration. I am still deciding between 1) and 3) on IMAP side. If the information can be different for different messages, then a new IMAP capability is a wrong way to do this. In this case IMAP per-message annotations are a better fit, but I do have some concerns about deployability. > > Lisa > > > On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov > > wrote: > > Hi Murray, > Some quick comments about your IMAP proposal that uses ANNOTATE. > > >3. IMAP Server Implementation > > > > An [IMAP] server conforming to this specification MUST implement > > [ANNOTATE] and MUST report these annotations to the client if they > > are attached to the message(s) being requested. > > > > > The second MUST: I am not sure what you are trying to say here. If you > are saying that the new annotations must be reported whenever the > corresponding message body is send (or similar), then that is not how > the ANNOTATE extension works. > [...] > > >5.1. Formal Definition > > > > The content of the annotation, as defined using [ABNF], is as > > follows: > > > > authres = 1*( version ":" authserv-id ":" methodspec > > ":" propspec ) > > ; relays a single unit of authentication results > > ; information > > > > > Are you trying to list multiple authresults here? I think you are > missing some delimiter between individual values, e.g. SP. > > _______________________________________________ > 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 > Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DA8Nib078144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2008 03:08:23 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9DA8NdH078141; Mon, 13 Oct 2008 03:08:23 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from kalyani.oryx.com (kalyani.oryx.com [195.30.37.30]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9DA8Bjt078060; Mon, 13 Oct 2008 03:08:22 -0700 (MST) (envelope-from arnt@oryx.com) Received: from kalyani.oryx.com (localhost.oryx.com [127.0.0.1]) by kalyani.oryx.com (Postfix) with ESMTP id EAF664AC95; Mon, 13 Oct 2008 12:08:07 +0200 (CEST) Received: from arnt@oryx.com (client address 195.30.37.40) (HELO lochnagar.oryx.com) by kalyani.oryx.com (Archiveopteryx 3.1.0) with esmtp id 1223892487-66249-3650 (5 recipients); Mon, 13 Oct 2008 12:08:07 +0200 Message-Id: <2QS9LqMYTRX1oMg1BXsm+A.md5@lochnagar.oryx.com> Date: Mon, 13 Oct 2008 12:06:29 +0200 From: Arnt Gulbrandsen To: ietf-imapext@imc.org, ietf-smtp@imc.org, mail-vet-discuss@mipassoc.org Subject: Re: Straw consensus call on auth-header draft Cc: Lisa Dusseault References: In-Reply-To: Content-Type: text/plain; format=flowed Mime-Version: 1.0 Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I read the auth-* drafts. Lisa Dusseault writes: > I'd like to do a more explicit consensus call now to nail this down. > I've tried to identify the major points of attraction rather than > every variant, to see where people are leaning. Please reply with > one of these options, a variant, and explanation if you like: > > A) auth-header to not require any feature advertising or auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising > C) auth-header to normatively REQUIRE some kind of feature advertising I don't like auth-header, but if any, then A. Comments and stuff. 1. Auth-header tells MTAs to add two (or more?) trace fields. The document doesn't specify order, so if it's not clear what was added by y below: Received: by x ... Authentication-Results: (1) ... (dkim stuff) Received: by y ... Authentication-Results: (2) ... (dkim stuff) Authentication-Results: (3) ... (iprev stuff) Received: by z ... Y might have added 1, 2 or 2+3, right? Difficult to handle. Particularly if the analysis code wants to detect or handle reordered headers. This could be fixed by adding a new level of hierarchy between header and field. Call it trace-field-group. But we have that for Resent-* and IMO that's one of the reasons Resent-* has faded from view. Another solution would be to write this information inside the Received field. 2. I've noticed that some DKIM implementations like to sign every field they see, which might include auth-headers. The auth-header draft says to remove old auth-headers, breaking such signatures. That conflict needs advice, or at least a security consideration. 3. The reason I don't like advertising is that many people use so very complex delivery chains. Transmitting capability advertising from start to end is hard. Better to design the stuff so that's not needed. 4. Why isn't there a sieve extension to let people filter mail on this? Arnt Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9CNiqSX043868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 16:44:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9CNiqF2043867; Sun, 12 Oct 2008 16:44:52 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9CNieEf043850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 16:44:51 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.0.3] (adsl-68-122-70-138.dsl.pltn13.pacbell.net [68.122.70.138]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m9CNicq7024549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 16:44:39 -0700 Message-ID: <48F28BE6.1060509@dcrocker.net> Date: Sun, 12 Oct 2008 16:44:38 -0700 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Lisa Dusseault CC: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Re: Straw consensus call on auth-header draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92/8414/Sat Oct 11 20:30:50 2008 on sbh17.songbird.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 12 Oct 2008 16:44:39 -0700 (PDT) Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Lisa Dusseault wrote: > I'd like to do a more explicit consensus call now to nail this down. > I've tried to identify the major points of attraction rather than every > variant, to see where people are leaning. Please reply with one of > these options, a variant, and explanation if you like: > > A) auth-header to not require any feature advertising or auto-configuration > B) auth-header to normatively RECOMMEND some kind of feature advertising > C) auth-header to normatively REQUIRE some kind of feature advertising Lisa, Your alternatives B & C appear to seek normative technical language that refers to something that does not exist. Further, a phrase like "some kind of" makes it rather difficult to know whether the 'requirement' is satisfied. It is generally ill-advised to have a specification make statements about the unknown future, which of course means anything in the future. It seems an even poorer choice to make that statement be normative, without specifying the details of that future precisely. So, please clarify how can a technical specification contain normative language to cover something that doesn't exist? More precisely, what does it mean to include such language, in terms of actual development or operation? What impact does such a statement have on the current specification? On use of it? The alternative seems to be to require the current specification to wait until there is an approved specification for advertising/configuration that can then, in turn, be recommended or required (presumably SHOULD OR MUST, respectively?) ps. But to conform to the precise confines of your exercise, I suggest Alternative A, since there are many operational environments for which manual configuration works just fine. In those environments, advertising and configuration mechanisms add complexity without benefit. pps. What are examples of similar mechanisms, for application-level advertising or auto-configuration, that are already in Internet-scale use? Knowing the answer to this can give some guidance about the likely risk of mandating such a mechanism here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9CLTO75036203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Oct 2008 14:29:24 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id m9CLTORk036201; Sun, 12 Oct 2008 14:29:24 -0700 (MST) (envelope-from owner-ietf-imapext@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-imapext@mail.imc.org using -f Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.241]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9CLTC8C036186 for ; Sun, 12 Oct 2008 14:29:23 -0700 (MST) (envelope-from lisa.dusseault@gmail.com) Received: by rv-out-0708.google.com with SMTP id c5so1232454rvf.34 for ; Sun, 12 Oct 2008 14:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=rJiAvE/bramwsm6SvvpgjuliagTArGiPYdBlEbBS21M=; b=N74xYhnVvNDEEHm85bVPqngT+1RRDk7WByPK/ZWIsLZq9KiwqpuDj487au/yAtR828 a615QT6oozWKWZj3aLwV85oIseSn5B4hXLY5yNuCw5QZUiOcNA7YvRGDoVGDoSNww7/4 Gy3iKXzbmAMOhev9phfrzlS3rxmKybdPGBBxE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=W6VgCOEczeuOVwr0R18XZ6+Zqi91PbFlVBZSoWiPjfucBEIOySeeBBHHcrr8dNiREC 7LQwnByfFnjggG1Cu/qkoXhTYtBcR5cAT0buThzw16IQBtgzeWpwW/hOUnQRhdTOvk9A Fp7rohxMlPOfHEjOYabl1yIawmwSPVTj9rVU8= Received: by 10.140.165.21 with SMTP id n21mr3141685rve.97.1223846952025; Sun, 12 Oct 2008 14:29:12 -0700 (PDT) Received: by 10.140.173.21 with HTTP; Sun, 12 Oct 2008 14:29:11 -0700 (PDT) Message-ID: Date: Sun, 12 Oct 2008 14:29:11 -0700 From: "Lisa Dusseault" To: Mail-Vet-Discuss , ietf-imapext@imc.org, ietf-smtp@imc.org Subject: Straw consensus call on auth-header draft MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_127225_14626098.1223846951999" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ------=_Part_127225_14626098.1223846951999 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I'd like to do a more explicit consensus call now to nail this down. I've tried to identify the major points of attraction rather than every variant, to see where people are leaning. Please reply with one of these options, a variant, and explanation if you like: A) auth-header to not require any feature advertising or auto-configuration B) auth-header to normatively RECOMMEND some kind of feature advertising C) auth-header to normatively REQUIRE some kind of feature advertising Separately, the unspecified feature advertising or auto-conf should be (choose one or more): 1) IMAP Capabilities advertising 2) E/SMTP capabilities 3) IMAP annotations 4) Something else 5) Nothing Note that I've left document organization out of the poll. If people feel strongly about that they can argue about it. Lisa On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov wrote: > Hi Murray, > Some quick comments about your IMAP proposal that uses ANNOTATE. > > >3. IMAP Server Implementation > > > > An [IMAP] server conforming to this specification MUST implement > > [ANNOTATE] and MUST report these annotations to the client if they > > are attached to the message(s) being requested. > > > > > The second MUST: I am not sure what you are trying to say here. If you > are saying that the new annotations must be reported whenever the > corresponding message body is send (or similar), then that is not how > the ANNOTATE extension works. > [...] > > >5.1. Formal Definition > > > > The content of the annotation, as defined using [ABNF], is as > > follows: > > > > authres = 1*( version ":" authserv-id ":" methodspec > > ":" propspec ) > > ; relays a single unit of authentication results > > ; information > > > > > Are you trying to list multiple authresults here? I think you are > missing some delimiter between individual values, e.g. SP. > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html > ------=_Part_127225_14626098.1223846951999 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I'd like to do a more explicit consensus call now to nail this down.  I've tried to identify the major points of attraction rather than every variant, to see where people are leaning.   Please reply with one of these options, a variant, and explanation if you like:

A)  auth-header to not require any feature advertising or auto-configuration
B) auth-header to normatively RECOMMEND some kind of feature advertising
C) auth-header to normatively REQUIRE some kind of feature advertising

Separately, the unspecified feature advertising or auto-conf should be (choose one or more):
1) IMAP Capabilities advertising
2) E/SMTP capabilities
3) IMAP annotations
4) Something else
5) Nothing

Note that I've left document organization out of the poll.  If people feel strongly about that they can argue about it.

Lisa


On Sat, Oct 11, 2008 at 10:13 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Hi Murray,
Some quick comments about your IMAP proposal that uses ANNOTATE.

>3.  IMAP Server Implementation
>
>   An [IMAP] server conforming to this specification MUST implement
>   [ANNOTATE] and MUST report these annotations to the client if they
>   are attached to the message(s) being requested.
>
>
The second MUST: I am not sure what you are trying to say here. If you
are saying that the new annotations must be reported whenever the
corresponding message body is send (or similar), then that is not how
the ANNOTATE extension works.
 [...]

>5.1.  Formal Definition
>
>   The content of the annotation, as defined using [ABNF], is as
>   follows:
>
>      authres = 1*( version ":" authserv-id ":" methodspec
>                            ":" propspec )
>              ; relays a single unit of authentication results
>              ; information
>
>
Are you trying to list multiple authresults here? I think you are
missing some delimiter between individual values, e.g. SP.

_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

------=_Part_127225_14626098.1223846951999--