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 PROTECTED] Please
report all such abuse to;
[EMAIL PROTECTED];"
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" <[EMAIL PROTECTED]>
To: "Michael Thomas" <[EMAIL PROTECTED]>
Cc: "DKIM List" <[email protected]>
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
