Re: [ietf-dkim] Re: "I sign everything" yes/no
"Charles Lindsey" <chl@clerew.man.ac.uk> Mon, 27 November 2006 12:55 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gog12-0002Nc-8y for ietf-dkim-archive@lists.ietf.org; Mon, 27 Nov 2006 07:55:20 -0500
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gog0x-0000L7-NE for ietf-dkim-archive@lists.ietf.org; Mon, 27 Nov 2006 07:55:20 -0500
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kARCsLUE003662; Mon, 27 Nov 2006 04:54:22 -0800
Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id kARCs5sL003595 for <ietf-dkim@mipassoc.org>; Mon, 27 Nov 2006 04:54:05 -0800
Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3&clerew&man^ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.237) id 456adfdd.85f6.502 for ietf-dkim@mipassoc.org; Mon, 27 Nov 2006 12:53:49 +0000 (envelope-sender <chl@clerew.man.ac.uk>)
Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id kARCrlRS002086 for <ietf-dkim@mipassoc.org>; Mon, 27 Nov 2006 12:53:48 GMT
Date: Mon, 27 Nov 2006 12:53:47 -0000
To: DKIM <ietf-dkim@mipassoc.org>
Subject: Re: [ietf-dkim] Re: "I sign everything" yes/no
References: <198A730C2044DE4A96749D13E167AD37E7E714@MOU1WNEXMB04.vcorp.ad.vrsn.com> <91A3FD7B-8B4A-4F78-9C5F-9BC66F86614D@mail-abuse.org> <4563C8D8.40909@santronics.com> <45647C86.36F3@xyzzy.claranet.de> <45648A1A.9030302@santronics.com> <op.tjg51tkv6hl8nm@clerew.man.ac.uk> <4567E1D7.6050002@cisco.com>
From: Charles Lindsey <chl@clerew.man.ac.uk>
Content-Type: text/plain; format="flowed"; delsp="yes"; charset="iso-8859-1"
MIME-Version: 1.0
Message-ID: <op.tjod3xh26hl8nm@clerew.man.ac.uk>
In-Reply-To: <4567E1D7.6050002@cisco.com>
User-Agent: Opera M2/8.01 (SunOS, build 1204)
X-Songbird: Clean, Clean
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id kARCsLUE003662
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
On Sat, 25 Nov 2006 06:25:27 -0000, Jim Fenton <fenton@cisco.com> wrote: > It's not entirely forgotten; section 2.3 of draft-allman-dkim-ssp-02 > discusses multiple From addresses. We thought about resolving the > ambiguity by (1) arbitrarily picking the first address in the From > header field, (2) picking the address in the Sender header field, or (3) > querying SSP for all addresses in the From header field, and combining > them somehow. We picked (1), because we don't know whether the MUA is > going to display the Sender address or not, and we felt that it is > likely that it will display the first From address regardless. And there I think you picked the wrong one. Why is whether the Sender header gets displayed by the MUA of relevance (though a decent MUA should give you the option of showing it)? Surely it is the MTA/MDA that does the verifying and that queries the appropriate SSP that needs to consider whether to use the Sender: or From: (for sure, full headers are available for inspection at that point). So I think you should have picked #2. OTOH, if you or your MUA are sufficiently sophisticated to want to do the checks yourself, then you are presumably sufficiently sophisticated to cause the Sender: to be displayed. I have seen sufficient comments from others to the effect that the Sender needs to be looked at in many situations that this matter probably ought to be reviewed (does that mean raising an Issue?). Actually, I think we are all asking the wrong question, by starting from some header (From/Sender/Whatever). Surely a proper verifier should proceed something like this: For each signature accompanying the message: Consider the Domain that created the signature For each relevant header (From, Sender, List-Post, etc) Note whether that Domain occurs in the address(es) in that header Consider the SSP of that Domain: Is the set of headers including (or not including) that Domain correct/reasonable/whatever? Combine results from all signatures to arrive at final conclusion/score/whatever. > But we don't know how this will be displayed, and who the recipient is > likely to consider the author of the message, ... I think it is more important who the originating/resending/forwarding/signing/SSP domain considered to be the author/sender. so it's very difficult to decide >> BTW, the bit in the base document that says the "From" MUST always be >> signed is wrong. It should have been the Sender, and maybe any >> Resent-From too. And that MUST is going to haunt us again when EAI ... > The language here was discussed and determined by WG consensus. > Personally, I favored the language in -base-03 and earlier that says, > "any header field that describes the role of the signer (for example, > the Sender or Resent-From header field if the signature is on behalf of > the corresponding address and that address is different from the From > address) MUST also be included." Yes, Im think you were right there, and if I had been a WG member at that time you would have had my support (though maybe not all the way up to "MUST"). I think it is up to verifiers to decide whether the correct headers have been signed to enable them to form a valid conslusion. For example, if the verifier saw that the message had been downgraded by EAI, it might take a very different view of which headers it wanted to see. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
- [ietf-dkim] "I sign everything" yes/no J.D. Falk
- Re: [ietf-dkim] "I sign everything" yes/no Stephen Farrell
- Re: [ietf-dkim] "I sign everything" yes/no Dave Crocker
- Re: [ietf-dkim] "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] "I sign everything" yes/no Douglas Otis
- Re: [ietf-dkim] "I sign everything" yes/no Paul Hoffman
- RE: [ietf-dkim] "I sign everything" yes/no Hallam-Baker, Phillip
- Re: [ietf-dkim] "I sign everything" yes/no Douglas Otis
- Re: [ietf-dkim] "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] "I sign everything" yes/no Douglas Otis
- [ietf-dkim] Re: "I sign everything" yes/no Frank Ellermann
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- RE: [ietf-dkim] "I sign everything" yes/no Hallam-Baker, Phillip
- [ietf-dkim] ISSUE: Better definition of "DKIM sig… Frank Ellermann
- Re: [ietf-dkim] "I sign everything" yes/no Douglas Otis
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Stephen Farrell
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Charles Lindsey
- [ietf-dkim] Re: Role of Sender header as signing … Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Douglas Otis
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Douglas Otis
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- [ietf-dkim] Re: "I sign everything" yes/no Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Stephen Farrell
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- [ietf-dkim] OT: Return-Path considerations (was: … Frank Ellermann
- [ietf-dkim] EAI + SSP status (was: "I sign everyt… Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- [ietf-dkim] Last calls for lemonade (was: ISSUE: … Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- [ietf-dkim] ISSUE: Is "sender" in 4.1 4th paragra… Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Stephen Farrell
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Stephen Farrell
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Eliot Lear
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Michael Thomas
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… william(at)elan.net
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] ISSUE: Better definition of "DKIM… John Levine
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Jim Fenton
- Re: [ietf-dkim] Re: "I sign everything" yes/no Jim Fenton
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… william(at)elan.net
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Michael Thomas
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Eliot Lear
- Re: [ietf-dkim] Re: "I sign everything" yes/no Eliot Lear
- [ietf-dkim] Re: ISSUE: Better definition of "DKIM… Frank Ellermann
- RE: [ietf-dkim] Re: "I sign everything" yes/no Hallam-Baker, Phillip
- Re: [ietf-dkim] Re: news and lists again, was "I … John Levine
- Re: [ietf-dkim] Re: ISSUE: Better definition of"D… Hector Santos
- Re: [ietf-dkim] Re: "I sign everything" yes/no Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- [ietf-dkim] Resend-cruft (was: ISSUE: Better defi… Frank Ellermann
- Re: [ietf-dkim] Re: "I sign everything" yes/no Jim Fenton
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Stephen Farrell
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Charles Lindsey
- Re: [ietf-dkim] Re: "I sign everything" yes/no Stephen Farrell
- [ietf-dkim] Future uses of DKIM in Netnews (was: … Frank Ellermann
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Douglas Otis
- Re: [ietf-dkim] Future uses of DKIM in Netnews (w… Charles Lindsey
- [ietf-dkim] Role of Sender header as signing doma… Charles Lindsey
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Charles Lindsey
- Re: [ietf-dkim] Role of Sender header as signing … Scott Kitterman
- Re: [ietf-dkim] Re: "I sign everything" yes/no Eliot Lear
- Re: [ietf-dkim] Role of Sender header as signing … Hector Santos
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- [ietf-dkim] Re: Role of Sender header as signing … Frank Ellermann
- Re: [ietf-dkim] Role of Sender header as signing … John Levine
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Role of Sender header as signing … Steve Atkins
- Re: [ietf-dkim] Re: "I sign everything" yes/no Michael Thomas
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Michael Thomas
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Damon
- Re: [ietf-dkim] Re: ISSUE: Better definition of "… Hector Santos
- Re: [ietf-dkim] Role of Sender header as signing … Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Re: Role of Sender header as sign… Michael Thomas
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Role of Sender header as signing … Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Eliot Lear
- Re: [ietf-dkim] Role of Sender header as signing … Hector Santos
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Role of Sender header as signing … Stephen Farrell
- Re: [ietf-dkim] Re: Role of Sender header as sign… william(at)elan.net
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Damon
- Re: [ietf-dkim] Re: Role of Sender header as sign… Eliot Lear
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- RE: [ietf-dkim] Re: Role of Sender header as sign… Bill.Oxley
- Re: [ietf-dkim] Re: Role of Sender header as sign… Michael Thomas
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Charles Lindsey
- Re: [ietf-dkim] Re: Role of Sender header as sign… Wietse Venema
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Re: Role of Sender header as sign… Hector Santos
- RE: [ietf-dkim] Re: Role of Sender header as sign… Bill.Oxley
- Re: [ietf-dkim] Re: Role of Sender header as sign… John Glube
- Re: [ietf-dkim] Re: Role of Sender header as sign… Hector Santos
- Re: [ietf-dkim] Re: Role of Sender header as sign… John Glube
- Re: [ietf-dkim] Re: Role of Sender header as sign… Scott Kitterman
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Hector Santos
- Re: [ietf-dkim] Re: Role of Sender header as sign… Damon
- Re: [ietf-dkim] Re: Role of Sender header as sign… Stephen Farrell
- Re: [ietf-dkim] Re: Role of Sender header as sign… Steve Atkins
- [ietf-dkim] receiver role in ssp Bill.Oxley
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis
- Re: [ietf-dkim] Re: Role of Sender header as sign… Damon
- Re: [ietf-dkim] Re: Role of Sender header as sign… Douglas Otis