J D Falk wrote:
Jon Callas wrote:
SSP is an important, valuable, *optional* part of the email
infrastructure.
This is a very important point. When the draft says "MUST," an
experienced i-d reader will know that it actually means "x must do y in
order to comply with this specification." That's not so obvious for
other humans, especially when pretty much all of the conversation on
this list also has the inherent assumption that SSP will be everywhere
for everybody.
There will be entirely valid use cases for which SSP will not be useful,
and may even be damaging. Ellen's is one of these: she's probably going
to have to change her entire business model as SSP adoption grows. In
our discussions -- especially with people who aren't fluent in the
ancient & dusty IETF vernacular -- we MUST remember that SSP will never
and can never be any stronger than a SHOULD.
-1 for all the same reasons discussed over the last 2+ years.
Ellen is no special case than any other 3rd party system we
have debated over and over and over again for the past 2.5 + years.
If Ellen or similar business wants to get into the DKIM signing
business, then when her service verifies the new user's domain, it needs
to include SSP checking for restrictive policies during the signup
process. Otherwise, she is abusing the Domain's protection. Thats part
of the issue today - forging.
Same is going to have to be true for public Mailing List Services or any
other ESP who offers free or fee-based email support and wants to get
into the signing business.
And that includes high-commodity domains like banks sending signed mail
to their users. If they do this blindly, they are not helping
themselves nor the user.
I don't see any of this as negatives and its actually a rather simple
concept. The question is whether it is feasible to do so and how it can
optimized.
It has been my opinion, DKIM/SSP real benefits are with restrictive
polices. The loose ones will continue to exhibit themselves
problematically just like it does today with relaxed policies in SMTP
and sure, there are ones who probably are not capable of using it.
But I don't think Ellen's business is one of those.
During the Ellen's user signup process:
- If user's DOMAIN has no SSP,
- Ellen can sign as a 3rd party, or
- Choose not to sign
- If user's DOMAIN has a SSP
DKIM=UNKNOWN
- Ellen can sign as a 3rd party, or
- Choose not to sign
DKIM=ALL
- Ellen MUST sign as a 3rd party.
DKIM=STRICT
- Ellen MUST NOT allow this user to use her services.
Very consistent logic. Very simple. The worst case, she will filtering
out restrictive policies. Her business can only with with non the
non-restrictive.
Thats good in my opinion. I would go on to suggest, the majority of the
world wants the level of security.
Again, the question is one of feasibility. I don't see a problem with this.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html