[ietf-dkim] Clarification: Section 5.4.6

[Michael Thomas]

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:

>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 security at bank.example. Please
>            report all such abuse to;
>          r=phishing-reports at bank.example;"
>
>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
>
>
>
>
>
>
>----- Original Message -----
>From: "Michael Thomas" <mike at mtcc.com>
>To: "Michael Thomas" <mike at mtcc.com>
>Cc: "DKIM List" <ietf-dkim at mipassoc.org>
>Sent: Wednesday, August 09, 2006 2:33 PM
>Subject: Re: [ietf-dkim] Clarification: Section 5.4.6
>
>
>  
>
>>Following myself up with a clarification:
>>
>>Michael Thomas wrote:
>>
>>    
>>
>>> "In particular, a Practice or Expectation MUST NOT mandate any
>>>   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
>>_______________________________________________
>>NOTE WELL: This list operates according to
>>http://mipassoc.org/dkim/ietf-list-rules.html
>>
>>    
>>
>
>  
>