ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Issue: ssp-requirements-01 // DKIM Strict definition needed.

2006-09-22 03:45:31

(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 requirement.

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.

Stephen.

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.

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

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