> -----Original Message----- > From: [email protected] [mailto:ietf-dkim- > [email protected]] On Behalf Of Hector Santos > Sent: Thursday, March 26, 2009 7:40 AM > To: IETF-DKIM > Subject: Re: [ietf-dkim] DKIM/ADSP edge case writeup at CircleID > > Charles Lindsey wrote: > > On Wed, 25 Mar 2009 11:28:52 -0000, Hector Santos > > <[email protected]> wrote: > > > > > >>> - eBay and PayPal: signs non-existent Resent-From, preventing > resending > >> > >> Another case of BLIND signing! Read the freaking specs!! > > > > Not necessarily. Signing a non-existent header is a valid way of > > preventing it being added subsequently, and maybe that is what you want > > (e.g. in this case if the mail is "for original recipient's eyes only"). > > Not that Ebay and Paypal were necessarily trying to do that, although > > they are the sort of organisations that just might want to do it in > > specific situations. > > Good point Charles. > > I guess I can see benefits of signing an non-existing header with the > intent to preempt some downlink injection. But only from the > standpoint of the intent to force a failure handling process. i.e, > eBay, Paypal and entities of the like do not expect these failures to > be ignored. Possible example is Reply-To. They might not want a > Reply-To and will rely on From: for any user feedback. So they sign > an non-existing Reply-to, this preventing any replays with an injected > Reply-to for MUAs to use. > > I can see that. > >
Hector, This is exactly why I said in the article: "Some might assert that an organization should never DKIM sign a non-existent message-id header. At this time it is not clear, at least to me, that this is absolutely true. The implications of signing versus not signing under these circumstances certainly merit a healthy discussion before a verdict is reached." I've seen little if any (systematic) discussion of the various cases (for all headers) and how unsigned non-existent (at time of injection to the mail stream or signing) might be abused at a later point. Most of the discussion is about how things SHOULD function, not how they might be abused. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
