I disagree. 

I think the semantics are 'don't count on being able to verify this message
after this date'.

If I do manage to verify I can hold the purported signer resposible
regrdless of wheter x= is there or not.

My fault handling process for 'key not found' is going to be different if x=
has expired.

> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Mark Delany
> Sent: Wednesday, April 12, 2006 2:13 AM
> To: [email protected]
> Subject: [ietf-dkim] x= lets senders expire responsibility
> 
> On Wed, Apr 12, 2006 at 01:07:22AM -0400, Hector Santos 
> allegedly wrote:
> 
> > > Remove x=
> 
> > IMO, there is a precise and purposeful rationale.   I  can 
> come up with
> > atleast a dozen reasons or more why a signer may want to utilize an 
> > expiration concept.
> 
> As you say, and I agree, the benefits flow mostly, if not 
> entirely, to the signer ... even though earlier discussions 
> mooted benefits to the verifier.
> 
> 
> As I understand it, when x= expires the signer wants 
> verifiers to treat the mail as unverified - in effect signers 
> get to disclaim responsibility for that email after a certain 
> point in time.
> 
> This seems entirely at odds with DKIM which is about senders 
> taking responsibility for an email for the benefit of the verifier.
> 
> DKIM is not about senders taking responsibility for just 5 
> seconds or just 5 minutes or just 5 days. If a mail is signed 
> and sent, a sender has no right, in my mind, to subsequently 
> disclaim responsibility. It's their content; they wear the 
> consequences forever.
> 
> In short: x= gives senders wiggle room to expire 
> responsibility - that seems at odds with our goals.
> 
> 
> Mark.
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to