[ietf-dkim] Delegating responsibility: a make vs. buy
designdecision
Hector Santos
hsantos at santronics.com
Tue Aug 22 17:08:52 PDT 2006
Jim,
I consider the baseline situation where verifiers receiving non-signed
messages and what you would use from the minimum 2822 headers available to
extract the domain policy information.
What will that be?
In other words, if you have:
Received:
From:
To:
Subject:
Date:
and no other DKIM fingerprints, what do you use to get the DKIM signing
practice?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Jim Fenton" <fenton at cisco.com>
To: "Scott Kitterman" <ietf-dkim at kitterman.com>
> Sorry, having trouble keeping the context of the discussion right.
>
> This could be done, but dilutes the simplicity argument that motivated
> the Authorized Signing Domains approach in the first place. Formerly
> the ISP just signed using their own domain name; now they must create a
> subdomain for each of their customers, publish keys there, and sign each
> using the proper subdomain? Or do they sign using i=@cust49.isp.com and
> d=isp.com perhaps?
>
> But there is a residual problem. Suppose jdoe at mipassoc.org is a
> subscriber to this list and someone spoofs a message from
> jdoe at mipassoc.org to the list. ietf-dkim at mipassoc.org accepts the
> message and sends it to isp.com, their Authorized Signing Domain, and it
> is signed and sent. Is the signature from jdoe (the author) or
> ietf-dkim (the mailing list)? Without Authorized Signing Domains, you
> could tell by looking at the local-part of i=. But now you can't. I
> think this is an important distinction, even if it only applies in a
> subset of use cases.
>
> -Jim
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
More information about the ietf-dkim
mailing list