Subject: [ietf-dkim] Clarification: Section 5.4.6

From: Damon <[email-masked]>
Date: Wed, 9 Aug 2006 12:56:03 -0400

6.   Practices and Expectations MUST be presented as an information
        service from the sender to be consumed as an added factor to the
        receiver's local policy.  In particular a Practice or
        Expectation MUST NOT specify any particular disposition stance
        that the receiver should follow.

 Should the last sentence say: "Expectation MUST NOT specify any
particular disposition stance that the receiver MUST follow."?

In my opinion, if the Expectation is set, it is stating a suggested
usage. Or in other words, what the receiver should follow.

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Aug 2006 11:08:07 -0700

> usage. Or in other words, what the receiver should follow.

I think that this is a question of whether the "should" (or "MUST" in
yours) is actually normative. I don't think it is. It might read better as:

  "In particular, a Practice or Expectation MUST NOT mandate any
    disposition stance on the receiver."

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Aug 2006 11:33:32 -0700

Following myself up with a clarification:

>    disposition stance on the receiver."

The reason that I've written it in this way was purposeful on my part: the
sender's expectation is that there should be a valid signature. I don't 
really
think we need to go further than that because if a receiver knows that the
sender expects a message to arrive with a valid signature, that's really 
all
it needs to know that there's something seriously amiss. What it actually
does when something is amiss it's its business, and I really don't think we
 need to give helpful hints as it's not really rocket science at that 
point,
and we really don't want to prejudice any particular action.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 9 Aug 2006 14:51:46 -0400

I was thinking about this and wasn't sure if it was worth bringing up.  I
mean, in DSAP we have failure-handling statements, but I can go either way.

But let me throw out the idea of the domain wishing to express a disclaimer
that is something failures, it is HIGHLY desirable that you not retain this
message.  I provided an example in DSAP:

  _dsap._domainkey.bank.example.  IN TXT
         "v=dsap1.0; a=rsa-sha256; op=always; 3p=never;
          n=We only send DKIM signed email, do not trust anything else
            such as notices allegedly from [email-masked]. Please
            report all such abuse to;
          r=[email-masked];"

Where using the N= note tag, the domain making an disclaimer statement to
the verifier not to trust the message.

So maybe just adding a new requirement?

    Protocol MUST allow for a informational text note for the policy.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Michael Thomas <[email-masked]>
Date: Wed, 09 Aug 2006 13:57:27 -0700

As always, a requirements document is a set of MINIMUM requirements. I'd
just assume we not get too far down in the details of things that we can 
just
as easily discuss in the design phase. This seems like one that could 
wait to me.

       Mike

Hector Santos wrote:

>>does when something is amiss it's its business, and I really don't think
>>    
>>
>we
>  
>

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 10 Aug 2006 01:09:33 +0200

> Protocol MUST allow for a informational text note for the

I always hated the exp= explanations in SPF.  A "disclaimer"
n=convoluted_legalese isn't better, IMO receivers won't care
about it.  You'd also get I18N issues with such "disclaimers".

Frank

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 9 Aug 2006 20:07:29 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> just as easily discuss in the design phase. This seems like one that could
> wait to me.

+1

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 10 Aug 2006 01:20:40 -0700 (PDT)

> Protocol MUST allow for a informational text note for the policy.

This is not a good for requirement precisely because the note is
of information use (basicly you already can put whatever else
extra in the record in additional undefined tag). The good thing
about pre-defined tag as with 'n' is that it reserves it for
something that will not be in use in the future become functional
record parameter. In any case this is precisely a design issue
and not for generalized requirement.

-- 
William Leibzon
Elan Networks
[email-masked]