On 7/20/2014 12:27 AM, Douglas Otis wrote:>
This is missing two citations that I thought were supposed to be
included, since they touch on indirect email flows:
Delegating DKIM Signing Authority - draft-kucherawy-dkim-delegate-00
DKIM Third-Party Authorization Label - draft-otis-dkim-tpa-label-03
Why not ATPS RFC6541 production?
http://tools.ietf.org/html/rfc6541
Consider ATPS the "lite version" of Doug's TPA. The same lookup hashing algorithm is used
in both. Further, there is real high quality commercial "running code" implementations
supporting rfc6541. All of our installations have DKIM+ADSP+ATPS out of the box with their primary
domain used for automated first time setup plug and play readiness.
ATPS is not the "lite version" of TPA-Label. This is explained in
http://tools.ietf.org/id/draft-otis-tpa-label-04.html#rfc.appendix.C
ATPS requires DKIM signatures used by Third-Party Services to somehow determine
different label encoding methods permitted by ATPS.
Hi Doug,
ATPS just requires the existing of the record. It puts no meaning in
the content or data returned from a successful ATPS lookup:
NXDOMAIN: No resigner authorization found
SUCCESS: Resigner authorization found
Either the record exist or it doesn't. Both ATPS and TPA offer similar
lookup as a function of author and signer domain:
YesNo = IsSignerAuthorized(ADID, SDID)
where
ADID is the author domain
SDID is the signer domain, if any.
They both have same functional goals and outcome. TPA just provides
extra and complex semantics and meaning for the content of the
existing record.
ATPS also lacks any discovery or exchange method for this.
With the exception of the arbitrarily selected underscore and/or
sub-domain delimiters, both have the near similar lookup algorithm
using a base32(sha1()) hashing discovery method:
ATPS: base32(sha1(SIGNER-DOMAIN))._atps.AUTHOR-DOMAIN
TPA: _base32(sha1(SIGNER-DOMAIN))._adsp.AUTHOR-DOMAIN
The TPA Label is just a sub-domain. The label or "subdomain" can only
be declared once for one lookup meaning. To have a different meaning,
you need a different lookup subdomain or label.
In contrast, TPA-Label makes NO demands on third-Party services. None.
Come on. Its all the same thing. Please. We have been at this for
nearly 9 years.
ATPS "labels" a.k.a. subdomains, doesn't require any demands on
resigners other than to play the same game (follow the protocol) as
expected of all DKIM verifiers. We really don't know how the
"Database" will be created, but at this point, it is the AUTHOR-DOMAIN
that is the base zone of the lookup algorithm that is currently
responsible to make this work. How this all scaled and managed,
delegated is a complex DNS administration related topic. But from a
protocol standpoint, it the same tool and method for a lookup to
resolve the problem we have today is:
Should the 3rd party do a LOOKUP or NOT to filter restrictive
domains?
The problem is that its not doing any kind of check, not even the
first level DMARC check to filter our the problematic restrictive mail
domains, including the ones that have changed mid-stream and there
exist legacy domains in 3rd party membership areas that need to be
cleaned up -- a migration problem.
TPA is no different than ATPS or any other kind of lookup that needs
to be done to make this a protocol complete integrated solution.
All TPA has is extra, complex semantics and big enterprise terms like
"federation" associated with it. ATPS can have a "federation" too!
TPA is written way too complex for what it does Doug, otherwise I
would of added support for it when it first came out.
But at the end of the programming day, its all the same thing which
resolves a simple question; Is the DKIM signer authorized as a
function of the signer and author domain?
Further, there are at least two SMTP packages (SendMail, Wildcat!
SMTP) that I am aware of, that have ATPS included in their API and
deployment options. I don't know of any using TPA.
Note: The fact that traction is not apparent can not be used for
judgment, because it wasn't championed, pushed and at the time,
ADSP was
being pushed out (erroneously IMO). ATPS (and TPA) required ADSP to
piggyback of its record to trigger a third party ADSP extension.
We are
now trying to change ATPS and TPA to piggyback off DMARC to continue
with the resigner authorization model that DMARC lacks.
Look, I really don't care whats used. If TPA is going to be considered
in the DMARC WG charter, then common sense management and engineering
tells you, ATPS should also be part of the charter, and it will be
very strange if it doesn't. ATPS is the "lite version" of TPA and
offers the basic same functionality of authorizing a signing domain.
I have nothing against TPA, and I told you that many years ago. ATPS
is written to simplify what you had with TPA and to scale the simplest
ASL idea of having ADSP tag extension:
asl=comma delimited list of authorized domains
in a ADSP record which is what I was pushing for the smaller scale.
The TPA extra data is not required but I am not saying it not a good
idea. I think it was TOO COMPLEX for the basic first level resolution
question being sought -- is that resigner authorization, yes or no?
Whatever "guts" is added behind the above functional equation, needs
to be simple in order to get wide and quick support at all discipline
levels. ATPS and TPA are going to get much push back because of the
hashing method. Creating the database of "labels" is going to be a
problem too. But again, its really about selling the idea of a
"lookup" for a resigner authorization. Once that concept is sold, the
method and/or database can be done one way or another, and it doesn't
have to be via DNS.
TIP:
What you should do is offer an equivalent match for ATPS records which
means the simplest content you can have for a lookup. ATPS does not
require any data. What is the minimum for TPA?
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
