On Tue, 1 Aug 2006, Stephen Farrell wrote:
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.
What do you mean by it not being "right protocol", in fact
what in your view makes protocol somehow "right" or "wrong"?
In any case the above scenario ("OP=ALWAYS; 3P=NEVER") is
probably going to be used by financial organizations that
want to protect use of their domains by phishers. Many of
these organizations only want to communicate directly with
end-users and do not allow their employers to even signup
for public mail list (or they allow but require users to
use address in some type of "corporate" domain as opposed
to their primary domain known to users), there is nothing
wrong with allowing them to publish this in the policy
and if it turns out not to be useful, I'm sure they will
not public it and remove 3P=NEVER policy record.
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?
Hopefully these lists will check which the existing signature
first. If this signature would get broken after normal list
processing than its good idea for mail list to check policies
of original sender and to accomdate those cases (i.e. different
type of list processed which would not break the signature).
If they are going to check on these cases anyway I see nothing
wrong with mail list not adding their own signature for those
same cases if user/domain asked not to do it.
That makes no sense at all to me and is a straight
consequence of the addition of a signature having a
negative effect.
I was on the linux conference recently in the security-area where
presenter said SELinux extensions would always make security of the
system greater. In couple minutes an example was found where they make
security of overall system weaker when the policy gets applied to
file having to do with another security mechanism. The point is that
new security mechanisms do always bring greater security for all the
cases they can be used with - in fact I'd not be surprised if there
is a theorem that said it is impossible.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html