[ietf-dkim] New Issue: ssp-requirements-01
// DKIM Strict definition needed.
stephen.farrell at cs.tcd.ie
Fri Sep 22 03:13:20 PDT 2006
(This thread relates to issue #1358 btw.)
Douglas Otis wrote:
> On Sep 21, 2006, at 4:53 PM, Michael Thomas wrote:
>> Douglas Otis wrote:
>>> On Sep 21, 2006, at 3:53 PM, Michael Thomas wrote:
>>>>> o DKIM Strict: the state where the domain holder believes that all
>>>>> legitimate mail purportedly from the domain are sent with a
>>>>> valid DKIM signature and that non-compliant services are avoided.
>>>>> What is difficult to understand with this definition? Is a
>>>>> definition needed for non-compliant services?
>>>> How does this differ from scenario #1?
>>> Note that DKIM Strict is not currently defined, but should be.
>> Doug, this is completely circular so I give up.
> This is a request that a policy state be _defined_ and indicated as
> _required_ within the 4.1 use scenario and listed in section 5.3.
> The 4.1 use scenarios has been made confusing by not alluding to when
> this undefined policy state might apply. Your suggestive descriptions
> have been unhelpful.
> DKIM Signer Complete is not suitable in this 4.1 but is suitable in
> 4.2. A more stringent state is required for 4.1 or we have the
> following problem:
> A- mailing list messages might be accepted when permitting signature
> failures from otherwise trusted mailing lists. (An assumption
> that steps to prevent signature failures have not been taken that
> is not suitable for 4.1)
> B- mailing list messages might be blocked when guarding against
> phishing attempts. (An assumption that steps have been taken to
> prevent signature failure that is not suitable for 4.2)
> 4.1 requires a policy state that ensures use scenarios 4.1 and 4.2 can
> be handled appropriately and that a wrong assumption is not made.
> Currently this state has not been defined or listed as a policy
> What are your reasons for excluding and not defining this stringent
> policy state?
Without entering into whether or not your definition is good, one
reason would be a lack of support for the suggested text coupled
with active opposition.
But there is another issue (1357) where Mike and Dave agreed to work
out language to make a clear distinction between the two scenarios
concerned, so if you're right about this, then they'll presumably
just discover that as they try write new text.
PS: I personally still don't understand how any interesting domain
can "avoid" messages passing through signature-breaking services, so
since I don't understand how to do it, I'd have a problem with that
language in any case.
More information about the ietf-dkim