ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Clarification: Section 5.4.6

2006-08-09 14:10:31
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(_dot_)example(_dot_) Please
           report all such abuse to;
         r=phishing-reports(_at_)bank(_dot_)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(_dot_)com>
To: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
Cc: "DKIM List" <ietf-dkim(_at_)mipassoc(_dot_)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



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