J.D.
It is about expectations. The world is being ask to being looking at the
broadcasting of DKIM messages coming into their system.
What do you (speaking in general) expect us to do? Define it.
The engineering shows there is a fix set of boundary conditions. Based on
the specifications, these are inherent to the model. They are there to be
used.
However, we can control them. What is acceptable and not acceptable.
John is calling for a low footprint of the boundary conditions. He suggest
"Always Sign" and "No Mail" expectations.
I believe for the sake of progress that it is probably feasible to begin
with a base SSP draft concept that strictly deals with the original domain
boundary conditions.
I see this OA policies:
No Mail Expected
Never Signed by anyone
Optional Signed by Original Domain (today called Strong)
Always Signed by Original Domain (I call this Exclusive Policy)
A network may want to have an always sign and a sometimes signed, but in all
cases, if signed, it is OA only.
I think one this is squared away, then we can introduce the next 3PS SSP
boundary conditions which is be HIGHLY complex and not only domain policy
based but also ISP based, List Server Based and other 3rd party middle ware
services, etc. There is where the potential liability and contractual
concepts come into play and no doubt, it can be complex because for the
most part it begins to introduce the idea of having a list of authorized 3rd
party signers.
---
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "J.D. Falk" <jdfalk(_at_)yahoo-inc(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, July 26, 2006 3:10 PM
Subject: Re: [ietf-dkim] How to proceed with SSP
On 2006-07-26 07:41, Arvel Hathcock wrote:
> Dave suggested in Montréal, to the agreement of at least some
> (including the chairs), that we have to step back and sort out SSP
> *requirements* before we can do an SSP specification.
I am in full agreement with this plan and am happy to see that an
approach is being managed and is well thought out. You're right, what
SSP ends up looking like is anyone's guess at this point but with a
pre-determined requirements doc to work from it will help the process
greatly.
+1
Policy is different things to different people -- and like many
social/legal/political constructs, the same policy can contradict itself
without being invalid. This won't be an easy consensus to find.
--
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
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