Ian Eiloart wrote:
On 12 May 2011, at 06:47, John R. Levine wrote:
As I tried to say tactfully in the draft, mailing lists have worked just
fine for 40 years, so if DKIM or ADSP don't work with mailing lists, it's
not because the lists are broken.
I think I agree with this. I get very little spam from mailing lists,
and very little spam purporting to be from mailing lists that
I subscribe to.
And I see a lot of spam in some of the list I have subscriptions to.
Most of it is trapped though and discarded.
ADSP seems to be carrying on the SPF tradition of claiming
that it's everyone else's fault that it doesn't work.
On the other hand, I still get a lot of spam. To me, that's
prima facie evidence that email needs fixing. I use, and like,
the additional information that SPF publishers give me.
Well, Levine never liked SPF since MARID, yet the world thought
otherwise (especially in the high-value domain world) and have
deployed SPF en masse. I think his arguments have been inconsistent
(see ending comment below).
The problem is that DKIM was exclusive redesigned to work for a
natural integrity breaking MLM and unrestricted resigner market and
you can only technically do this by ignoring all claims of originating
integrity and originality and authenticity behind it.
John is saying for the most part:
For 40 years, we (MLM) has been ignoring the
originating integrity and originality of mail,
ergo, any new mail claims of mail security and
authenticity can be naturally ignored too.
Speaking as a MLM vendor, there is something functionally wrong with
logic. Its ok to say we being it one way for a long time, but its not
ok to say I want to add something new and break inherent rules that
come with the new.
Finally, DKIM event without ADSP also has the same arguments stated
against SPF. DKIM + TRUST is what the key WG cogs want using a single
output. This also comes with a same similar concept of the SPF policies:
DKIM + Expected signer : PASS (-ALL)
DKIM + Unknown signer : Unknown (?ALL) or SoftFail (~ALL)
For example:
Suppose I have in my local receiver "DKIM trust" tables (a POLICY
concept or ACL idea) to trust mail from signer MyBank.com:
TRUST s=mybank.com
Thus all mail signed by mybank.com would be a locally certified PASS
concept.
But what the faults?
First, Levine claims that whats good for me, is good for all users on
my system. So any mail signed by mybank.com should be trusted at a
SYSTEM LEVEL! Thats a problem right there, but not unreasonable to
have this scenario base on a Local Receiver Policy.
Realistically, I will probably only expect mail from MyBank.com to be
for me or for certain users who are allowed to make the unique
vendor/user claim. So perhaps my local version of the trust table
might be:
TRUST s=mybank.com to:hsantos(_at_)isdg(_dot_)net
or for the AUID advocates (defined as it is technically defined):
TRUST s=mybank.com i=hsantos(_at_)isdg(_dot_)net(_dot_)mybank(_dot_)com
This would be based on the BANK DKIM Policy of telling me to set that
up which could come with a BANK DKIM POLICY based on Originating
Author Domain:
TRUST s=mybank.com odid=users.mybank.com
So if a message comes in purported signed mybank.com but doesn't with
any of the user or author domain policies, you have what now?
FAIL
SOFTFAIL
UNKNOWN
DKIM is the the same boat as any other policy based technology
yielding indeterminate results.
--
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