ietf-dkim
[Top] [All Lists]

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

2006-08-01 12:47:32

Evening Hector,

Hector Santos wrote:
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.

Now that sounds *very* complicated, or else, very marginal
(in terms of places it could be used).

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.

Ok, I'll stop asking now, but I have not seen anything to
convince me of a benefit here, never mind that this is
"highest" in any interesting sense. I can understand the
apparent attractiveness of being able to represent what
senders/domain-owners would like to say, but that doesn't
mean that ssp is the right protocol to use to make all
such statements.

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>

No. If a mailing list, or forwarder, wanted to start
signing, are they first supposed to check all of their
subscribers policies to determine which senders will be
disadvantaged by their signing?

That makes no sense at all to me and is a straight
consequence of the addition of a signature having a
negative effect.

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.

There is harm there - we'd at least be creating a new
DoS opportunity where none would exist otherwise, and
that I definitely dislike.

Stephen.


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