[ietf-dkim] Delegating responsibility: a make vs. buy design
dotis at mail-abuse.org
Mon Aug 21 10:17:18 PDT 2006
On Aug 21, 2006, at 9:35 AM, Hector Santos wrote:
> From: "Paul Hoffman" <phoffman at proper.com>
>> True. However, even if they are optional, they have to be fully
>> specified in order for people in the WG to understand if they are
>> relevant or necessary. The parts that I miss in this thread is:
>> "for this particular optional statement of policy, what is the
>> recipient of that policy message expected to do? What are the
>> requested to do?"
> In addition, the following table created long discussions since
> last year...
There are problems created using this verifier action matrix,
especially when a list of designated domains creates another category
of domain. Rather than asserting what the verifier should do, there
is greater clarity in describing what the signer does.
A Third-Party signature can be confusing when it may or may not be
included within a list of designated domains.
The following policy assertions based upon signer actions encompass
1st Party and all designated domains, however the 1st Party signature
syntax can override the policy Invalid/Valid assertions for the
"All" initial messages are signed for the 2822.From domain.
"Only" compliant sources are used that do not damage signatures.
"Invalid" 2822.From addresses are permitted.
All+Only = DKIM Signer Complete
All = DKIM signer Extended
> In addition, the current open SendMail source code (dkim-
> milter-0.5.1) has
> current support only for:
> Signature Optional (o=~ DKIM_POLICY_SIGNSOME)
Any policy without All+Only assertion.
A policy that indicates All assertion should then include only common
> Signature Expected (o=- DKIM_POLICY_REQUIRED)
A policy that indicates All+Only
> Signature Not Expected (o=. DKIM_POLICY_NEVER)
An empty list and All+Only assertion would indicate no mail sent.
Adding a flag that asserts that DKIM is never used would be trumped
by a valid signature. This may provide minor value for handling
domains that do not use DKIM and somehow find a reason to make this
Should policy include:
"Never" signs with DKIM policy assertion?
> The 3rd party restrictive policy DKIM_POLICY_AUTHORITY (o=!) as
> defined in SSP-01 is not SUPPORTED. There is no action for it.
The All+Only flags and designated domain list covers this use.
> This can only be assumed to be based on the idea that 3rd party or
> middle ware signing is not be restricted.
> One question that keeps coming back to me is if all this push back
> is to avoid more code changes that is already in the DKIM public
> API vaults?
By including a list of designated domains, greater flexibility can be
achieved while still retaining all the prior states. The flags that
offer the least benefit would be:
- "Invalid" as listing a domain could assert an assumption that the
2822.From are valid for the designated domain.
- "Never" as there seems to be little justification for making the
More information about the ietf-dkim