On 12/8/2020 6:24 AM, Дилян Палаузов wrote:> Hello,
I do no see the point of having all the discussions here, as nobody is
capable to read and understarstand all written emails in their whole
quantity. I personally do not follow the discussions anymore, apart
from reading the subjects…
+1 Major Plus One. Its all deja vu.
Optional reading. I'll use this opportunity to express my key summary
concerns as a long time DKIM and SPF implementation and commercial
DKIM/SPF product vendor.
FWIW.....
We have a Developer vs Administrative protocol design issue once
again. Too many philosophical "Administrative" subjective opinions
trying to burn their idea into how IETF protocols is written and how
implementations should behave operationally from an admin standpoint.
The DKIM POLICY model is a simple DNS lookup protocol, like SPF. It
hasn't change since day one. DMARC is just the current rendition of
the same thing since SSP - nearly 15 years - plus Reporting which was
rejected for SSP and ADSP. Unlike SPF, what DKIM POLICY lacked 3rd
party authorization protocol support.
But we had discussed the idea of using SPF softfails as a way to link
together with a valid DKIM result. I recall Microsoft was exploring
this methods as one the early explorers of ADSP. I liked the concept
and explored it myself by looking at a possible "fuzzy" logic of the
results, for example:
SPF PASS + DKIM PASS => Result PASS (confidence? 100%)
SPF SOFTWARE + DKIM PASS => Result PASS (confidence? 80%)
SPF NEUTRAL + DKIM PASS => Result PASS (confidence? 50%)
SPF FAIL + DKIM PASS => Result PASS (confidence? 0%, SPF fail preempts
DKIM?)
But when it came to the new filtering protocols we were development, I
was more interested in 100% or 0% deterministic protocol results.
Anything in between is "fuzzy" and imo, can't make hard filtering
unless we are now learning from the BIAS from Deep AI methods. For
many, Pareto's 80% may be good enough for a filtering decision.
It is well established, DKIM POLICY works for 1st party signatures. We
know this since day one. The proof of concept was long set in stone
and never to be killed. We documented it in the early initial DKIM WG
work productions - Thread Analysis and the Functional specification:
2006 RFC4686.txt Analysis of Threats Motivating DKIM
2006 RFC5016.txt Requirements for a DKIM Signing Practices Protocol
DKIM Policy is a powerful concept and in the words of one of the key
cogs - "Its scary!" Yes, for direct 1 to 1 private mail, you have a
very powerful way to protect against domain spoofing in the same way
SPF protects against unauthorized transports from unknown machines.
SPF has its "in-direct" issue with routing of transports which I
called a "Node Transition" point. DKIM was initially marketed as a
solution to the node transition problem.
The stage was set. SSP with its 3rd party options, defined the ideas
that a domain, like SPF, can describe which domain(s) can "notarize"
the email. But we did not have a way to define the authorized 3rd
party domain. The simple idea was to use tag= list, like a Access
control list, for example
acl=ietf.org, gmail.com
which it reduced the need for another DNS lookup. The acl= tag works
for a small well organization network. But it does not scale. ATPS
was written to some some like of scalable using a zone record per 3rd
party authorized domain. ATPS starts with a tag:
atps=1
and if enabled, receiver will check for the signer domain
authorization ATPS record. Does it work for all, no. But it works
for many and its been in production since 2012.
The DMARC or DKIM Policy protocol payoff does not come from positive
passed results but rather with failed results because the protocol
raises the bar by authorizing the receiver to reject or discard or
quarantine a.k.a filter a message for the sake of the end-user.
Side note: There are four states for mail transport:
- Reject (SMTP does not accept it).
- Accept (user sees it in inbox, may be filtered with other things)
- Accept & Discard (lost to the user)
- Accept & quarantine (move to spam box, outside the main inbox stream)
The p= policy not only should keep quarantine, it should add p=discard
Unfortunately, a key moment came, in RFC5016, section 5. item 10, when
the beginning of this long 14+ year "fight" with Mailing list
administrators started, imo. This was when all the heart aches became
to occur, the major disagreements between Policy Advocates and Trust
Advocates.
Read it carefully. Its about local policy (duh), but this last minute
item provision altered the future of DKIM POLICY. Every since then, we
had his long debate of DKIM-POLICY Model vs Mailing List Systems. It
basically lead to this protocol conclusion:
DKIM POLICY does not work for Mailing List unless the Mailing List
Server vendors supports and honors the DKIM POLICY model - period. If
it does not, it will have trouble integrating into a new DKIM with
optional restrictive policies world.
I know of only one commercial List Software vendor, Wildcat! List
Server, that supports the DKIM Policy for Restrictive Policies. It
does not have the issue with in-direct mail submissions. New
subscribers from restrictive domains are not allowed to subscribe. If
already a member of the list, list members from restrictive domains
can not longer post but they can continue to receive a distribution
(iow, a read only member).
For a long time, we had folks that believed "list servers" were so old
in their ways they are not obligated to change or adapt to the DKIM
policy model. I understand that. Wildcat! List Server is one of the
older systems around. Yet, the same folks advocated making
non-standard provision changes to intentionally ignore restrictive
DKIM Policies, continue distributing changed and unprotected original
domain mail by destroying the trust of the mail system by altering the
"READ-ONLY" field 5322.From.
Anyway, thanks for pointing this out. I second your concern. Its not
pretty what is going on. I hope key folks with the IETF are made aware
that this is not normal.
I believe we need to recognize the need for augmented DKIM Policy Tag
extensions that could do the various Product Support Features some
people are looking for.
I don't like ARC, too much overhead and its not addressing the key
lack of authorized 3rd party domain concerns, but if GOOGLE wants to
push this idea, than the ARC Protocol should extend DMARC with "arc="
related tags. I am on the fence of whether DMARCbis should mention
ARC. I don't think so if its an experimental. I don't think we did
this for a proposed standard to be referencing experimental work. But
in any case, maybe the tag "arc=1: means that it promote SPF or DKIM
fails?
In theory when combining ARC to SPF and DKIM, we now have:
SPF(4)+DKIM(2)+ARC(2) == Final Result(16)
There are 16 combinations for SPF, DKIM and ARC states. Some will
fold, some will not make sense.
I won't argue the WG decision to add ARC to DMARC in some matter. But
don't ram it down our throats. Allow domains to explore with an
"ARC=1" tag in their DMARC record, then at some point in the future,
as we learn more, it can be explored. But imo, we should not speak of
a DKIM Policy Protocol as if ARC is a natural part of it.
Thanks for reading.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
