On Wed, Jun 11, 2014 at 7:49 PM, Hector Santos <[email protected]> wrote:
> On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote: > >> >> One thing that is missing (and there's a placeholder for it) is >> examples so you can see how it works. I'll make sure that's there for >> -01. >> > > Examples are good. Can we work it out here, a "software" walkthru? Save > some drafting time. The draft already does that in Section 3.2. What's missing is an example message showing the semantics. Yes, the risk with the existing base DKIM verifiers, but I speak of the > more primitive, basic protocol faults "holes", "use cases" that is central > to all this: > > Restrictive 1st Party (Author Domain) Signing Policies > > - No Mail Expected > That's not in scope here. You could use draft-ietf-appsawg-nullmx for that if you really want. > - Signature Required, Exclusive 1st party only. > You would simply not use DKIM-Delegate if that's your policy. > - Signature Required, Any 3rd party allowed. > I don't think we're interested in that case here. Why would you want to allow arbitrary third parties to sign on your behalf and have that be meaningful? That would mean I can sign something that came from you and everyone would believe you approved it. > - Signature Required, Authorized 3rd party allowed only. > That's the exact use case for DKIM-Delegate. > If DKIM-Delegate does address the above, then its becomes a good > optimizer. However, there still need to be an "IF ELSE" DNS lookup when the > DKIM-Delegate or advanced 2.0 DKIM signature is missing. > It only addresses one of those cases, but that's the only one we need to solve here. And since one of the big benefits of this mechanism is that the policy becomes part of the message, there's no need to bring DNS (or a published whitelist of any kind) into this at all. -MSK
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
