On 7/28/2020 1:19 PM, Doug Foster wrote:
Hector, I do not understand this comment:
"The DKIM Policy Model since ADSP lacked the ability to authorize 3rd party domains.
DMARC did not address the problem and reason ADSP was abandoned. Hence the on-going
dilemma."
SSP, ADSP and DMARC are technical specs for a DKIM POLICY Model.
The problem we have with DMARC was the same with SSP which was
replaced by ADSP which attempted to ignore the problem. Generally, as
it often done with ambiguous issues in the IETF, we ignore it, we make
it out of scope, we keep it open ended, etc. It just wasn't resolved
and ADSP was abandoned but returned as DMARC but it also kept the same
3rd party ignorance as ADSP did. If this issue is not resolved for
DMARC, I see an interesting situation during DMARCBis Last Call
explaining how we abandoned ADSP for having problem XYZ and then
reintroduced "SUPER ADSP" as DMARC but it still has the problem XYZ.
Domains that participate with a mailing list have the option of including the
ML servers in their SPF record, or delegating them a DKIM scope and key. But
to obtain that authorization from the sending domain, someone would have to ask
for it, and might not receive the desired answer.
The goal of this discussion is to find a way to coerce trust. We do not lack
ways to grant trust on request.
This issue is not about the known, but the unknown. We don't have an
issue with proactive authorization and whitelisting methods.
I've been in this DKIM project for 15+ years, and to me, the goal has
also been to find a reasonable, scalable deterministic protocol that
will handle unsolicited, unknown 3rd party domain signers. Not
necessarily unknown in a bad sense, unknown that you don't know
anything about them. So you ask the author, "Hey, is this 3rd party
signer ok?"
SPF allows 3rd party IP declarations. DKIM POLICY model does not
offer this capability.
We have DKIM Policy extension proposals like ATPS (RFC6541) that
offers a deterministic method to associate the author domain with 3rd
party signer domains. This authorization is defined by the
Originating, Author Domain.
Look at my DMARC record for my isdg.net domain:
v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net;
ruf=mailto:dmarc-...@isdg.net;
The atps=y tells an ATPS compliant receiver that if it sees a 3rd
party domain signature:
Author Domain IS NOT EQUAL TO Signer Domain
Then it can do a ATPS look:
base32(sha1(SIGNER-DOMAIN))._atps.isdg.net
So if I wanted to authorized bayviewphysicians.com to be able to sign
for me, I would go to the wizard
https://secure.winserver.com/public/wcdmarc, enter your domain in the
list of authorized signers, click Zone Record and I get a record I can
add to my isdg.net zone:
e25dhs2vmyjf2tc2df4efpeu7js7hbik._atps TXT ("v=atps01;
d=bayviewphysicians.com;")
So anyone out there can see that I authorized bayviewphysicians.com to
sign for isdg.net
It is really sample.
Whether we can "coerce" receivers to honor any of this is a different
situation. In general, all you can do create a PROTOCOL that makes
good engineering sense and usable by the IETF community. If not, then
generally systems will ignore it.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
