ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Designated Signing Domains and Don't Sign assertions

2006-07-26 13:46:07

On Jul 26, 2006, at 12:13 PM, Hector Santos wrote:

So you always need to check for SSP first.

I don't think you should eliminate the 3rd party signature potential, but I can see where you might have a BASE SSP draft designed for Original Domain expectations versus a 3PS SSP Draft higher layer that supports the BASE SSP
with new 3PS logic as well.

DKIM makes administration of designated signing domains difficult because Selectors are not deterministic. Listing these designations represents an easier means to manage this relationship and provides a method of stating policy.

The following should represent fairly complete policy at the OA domain:

1- A Designated Signing Domain List
2- A Flag indicating whether DSDL is open-ended or closed.

Meaning derived:

Empty open-ended DSDL
 - Other domains handle the OA (default without policy asserted)

Empty closed-ended DSDL
 - No domain handles the OA (no mail sent from here)

Populated open-ended DSDL
 - Listed domains handle the OA as "first-party"
 - Other domains handle the OA.

Populated closed-ended DSDL
 - Listed domains handle the OA as "first-party"
 - No other domains handle the OA.

Other domains handling the OA may or may not sign using DKIM.

A policy (a flag) combined with a Designated Signing Domain List can be achieved within one query, whether this is a TXT RR, a TXT + PTR RRset, or a DKIM POLICY specific RR. The DSDL itself along with one simple flag indicating whether it is open-ended or closed DSDL provides all policy that should be needed.

-Doug



_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>