----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
On Nov 17, 2005, at 1:12 PM, Hector Santos wrote:
Doug,
It will be helpful to be distinctive and to distinguish which
policies in
DKIM/SSP you are concern about:
All but Never and None. : )
Can you explain how?
Showing the policies again:
NONE (no policy declared)
o=? WEAK (signature optional, no third party)
o=~ NEUTRAL (signature optional, 3rd party allowed)
o=- STRONG (signature required, 3rd party allowed)
o=! EXCLUSIVE (signature required, no 3rd party)
o=. NEVER (no mail expected)
o=^ USER
Looking the #1 obvious scenario which you are concern about, where ISP user
(MUA) wishing to use an alias via his ISP machine:
When the MUA submits a message, the ISP MSA will:
NONE - status quo, do nothing
WEAK - status quo, do nothing
NEUTRAL - ISP can sign as 3PS, if it wants
STRONG - ISP needs to check if message is OA signed
- ISP can sign as 3PS, if it wants
EXCLUSIVE - ISP needs to check if message is OA signed,
disallow otherwise.
NEVER - Disallow
USER - ISP checks USER policy for PASS/FAIL.
So the only OA Domain (From) restrictive policies when the domain is used as
an alias domain at the MSA are:
STRONG
EXCLUSIVE
NEVER
Everything else is relaxed.
So if a PUBLIC service system was really concern about DKIM and wanted to
give his users complete freedom, then he would not support DKIM and this ISP
will be the status quo exploited system allowing any FROM to be used.
But want about the MDA?
It all depends on what it sees, the SSP Verify Chart needs to be followed
where we have 6 x 6 or 36 possibilities.
Please don't misunderstand, DKIM offers a tremendous advantage,
but reliance upon a domain being visually unique may have
been considered okay a decade ago.
I don't follow that thinking. It is still important today.
The naive user requires greater assistance.
Yeah, at the MDA, not at the MUA.
Don't expect them to discern when they are seeing the
pretty-name, various character set(s) declared from a
RFC2047 format, a particular character-set derived from
puny-code RFC3492, or perhaps worse, the
puny-code itself. : 0
I don't expect them to know anything, but they do expect that when they
receive a message via our services that we did our best to serve them and
not just pass junk to them to decipher and cross our fingers that one day
they will get a new MUA that is smarter and do things for them.
Even then, why do I want to change 5-6 MUAs for our system for a logic I can
add to a single entry point - the back end server?
Did you know there are bills in certain govs like in Canada that is making
it a requirement for ISP to have AVS software so that you don't pass the
buck to users?
Do you understand the concern just expressed?
Yes, I completely understand your concerns and motivition as well for that
matter. I am not 100% sure you care to understand the various majority of
others concern.
But your concerns are more about the impact exclusive and strong policies
only will have, not the others, you are trying to fight policies that
high-value domains will very much like to control and regulate. They don't
want the FREEDOM on their domains.
What is really funny about your efforts is that you are shooting yourself in
the foot when I think you can have you cake and eat it too, if you really
know how to approach it.
I recommend that you:
1) Embrace DKIM,
2) Help squeeue out the issues of SSP
3) Help make sure that DKIM is flexibility for expansion,
4) Help make sure DKIM updates RFC 2821 for client FQDN
So once DKIM/SSP becomes widely adopted, your ideas would fit right in. In
other words, CSV/CSV, DNA will gain an entry and window of opportunity for
exploration and usage.
But no, you are trying to develop ALL-In-One integrated solution that
frankly are not all that correct to begin with.
I didn't need to tell you that the opaque-id idea DOES expose user privacy,
especially for our Wildcat! system. We will need to come up with a
different index that doesn't expose the current one that used for our
system.
I would ask "Why not the Message-ID?" We already use this for tracking and
dupe checking for over 20+ years. This is already cross reference per
message per domain per user.
And you have SPF to contend with too.
Of course, these are just my input into the WG. Just providing my side of
the issue and how I think you can best the make of it.
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org