ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New Requirements: SSP must offer Highest Protection Possible

2006-08-01 11:28:16

----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
Cc: "IETF-DKIM" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, August 01, 2006 1:50 PM
Subject: Re: [ietf-dkim] New Requirements: SSP must offer Highest Protection
Possible


"highest protection" (with or without caps:-) is a simple assertion
that there is a benefit.

Correct, but I would suggest it is based on the hypothesis that the
shortest, interrupted path between A and B theoritically offers the highest
protection (less troublesome, less opportunity for change).

So this policy basically becomes an emulation of the direct 1 to 1 mail
transaction "no change" expectation.  It would not be used where there might
be an expectation of mailing list servers in involved.

I still don't see what that benefit is. What message (that should) gets
delivered that wouldn't otherwise, or gets dropped (that should)
that would otherwise get through?

I'm not suggesting that a 2nd (3rd party ) valid signature added would not
be a valid transaction, but I think you should leave it up to the domain if
he wishes to allow this:

     OP=ALWAYS; 3P=NEVER;      Highest protection
     OP=ALWAYS; 3P=OPTIONAL;   "high" protection

All I saying is lets not exclude the highest potential.

I do see potential for at least accidental DoS when someone tries
to help by countersigning.

Right, thats possible. But isn't that a bug and applies to all policies <g>
and doesn't it still serve the purpose at the final destination that there
was a middle man doing unexpected things to the message?

All I am noting is that we should not exclude this possible policy. I don't
see the reason for excluding it.  The domains don't have to use it and there
is no harm created by it.

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








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