[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