From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
The matrix only enumerates the possibilities, not who or why one
would select those possibilities, and what they're hoping a
reciever will do with the information. It's the who and why
we need answers for.
Mike,
You are 100% correct and if it makes it easier I will do this in more
detail.
If you check out the DSAP section 5, the draft does begin to offer some "who
and whys". I felt from a protocol standpoint it really should not matter.
The main goal with DSAP and SSP for that matter was to describe the boundary
conditions. The compromise and solution here is to go thru the technical
possibilities, locking them down, including removing ones we don't think is
appropriate. But we would need to also document the PAIRs which will not be
supported because if we don't, that opens a threat entry point for abuse.
Ok, let me put my business hat on and describe the WHO/WHY for each. Of
course, I will not cover all possible creative uses, but I do have a few
good ideas on how they can be used, and I will submit that some that are
probably not necessary or can be folded. Also, the syntax shown is for
illustration. I am not locked into any specify form, but it was an agreed
upon format among reviewers.
Overall there are ten policies:
OP=;3P=; | Empty, No Mail Policy
This is for domains which are not used for email. The spectrum of users is
across the board, specifically those who have a web, ftp domain or other
service type but email. This will help address the spoofing of domains by
bad guys using domains that were not intended for email against other
DKIM-SSP compliant verifiers.
OP=NEVER;3P=NEVER; | No signing expected
This is for domains that fall into two possible categories; those who have
no interest in DKIM and it is telling the world DO NOT expect anyone to be
signing mail from these domains. This will help verifiers filter the
spoofers using this domains inappropriately. In addition, it will help
serve the ISP/ESP market who will begin to offer signing services. The
domain may not want to pay for signing? The domain may want to turn off any
ISP/ESP signing. These DOMAIN/ESP service contract ideas were covered the
old mailing. If a domain is using a ISP/ESP bent on signing all mail, should
this be forced down the domain throat? Of course, he can leave the ISP/ESP
if he doesn't like the new ISP/ESP policy, but why lose customers if the
domain doesn't want his mail signed? Just allow the domain to declare this
policy and the verifiers will help protect against any DKIM spoofing.
OP=NEVER;3P=ALWAYS; | Only 3P signing expected
OP=NEVER;3P=OPTIONAL; | Only 3P signing optional
This pair is designed for Service Bureaus, IPS or EPS who offer 3rd party
signing services. The EPS/ISP may offer a free or fee base signing service
targeted at local hosted domains and/or users. The business opportunities
here are great.
Please note that the ISP/ESP market can offer and support all policies so I
won't bother to mention this market in detail again.
OP=ALWAYS;3P=NEVER; | OP signature expected only
This is what I call the "Exclusive Policy" for domains who do not want to
have any risk whatsoever in sending an email directly to a user. ISP this
is highly desirable policy across the board, I can see high-value
organization taken advantage of this policy. John's lawyer, Jill's Bank,
Billy's doctor in the next generation eMedical market. All these domains
want 100% surviability and they will probably be more prudent on who they
send this type of mail too. So they might be adding failure pre-emption
methods. However, as well noted in the group, survivability may not
guaranteed depending the path, the hops, etc. Thus success rate is
increased as more DKIM-SSP compliant systems are adopted and they begin to
honor the exclusive policy. The short term workaround is the next two
policies.
OP=ALWAYS;3P=ALWAYS; | Both parties expected
OP=ALWAYS;3P=OPTIONAL; | OP expected, 3P may sign
This are for domains who want to sign all their mail but are going to allow
or may expect middle ware applications to make any corrections, if need be.
Although I consider this increases the potential for unknown abuse, it also
increases the survivability of the transport.
OP=OPTIONAL;3P=NEVER; | Only OP signing expected, if any
This policy can probably be used by a single domain who wishes to signed
mail for private direct email conversations, and also use the same domain
for unsigned messages for external public use (i.e. mailing list) where
survivability is low. This is implementation based with the software
allowing the domain to select or exclude which target domains are signed or
not.
OP=OPTIONAL;3P=ALWAYS; | OP may sign, 3P always expected
This falls into the ISP/ESP business market I described above, in the case,
the ISP/ESP has sold or has mandated an also signed concept for his system.
However, I do think the domain should have control on signing. The ISP/ESP
should offer the domain the ability to turn off 3rd party signing.
OP=OPTIONAL;3P=OPTIONAL | Both parties may sign.
Again, this can be just about anyone, but I think it will the software that
will make use of this for the domain or user to use on a per target address
basis possibly.
I hope this helps. From my standpoint, each policy is possible in the real
world. But some are more complex to handle, but that is an implementation
issue and I don't see a real big problem with that as long as we can set
such boundary conditions. As we always new, the hardest will be the MLS
(Mailing List Server). But the only solution I see is the domain itself
being a lot smarter on what policy to use within a MLS environment and the
MLS helping by using doing some pre-emptive policy checking action itself.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html