-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] 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
<hsantos(_at_)santronics(_dot_)com> 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