On Aug 21, 2006, at 9:35 AM, Hector Santos wrote:
From: "Paul Hoffman" <[EMAIL PROTECTED]>
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
2822.From address.
"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
services.
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
policy assertion.
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
assertion.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
