> On Apr 21, 2023, at 10:19 PM, Douglas Foster
> <dougfoster.emailstanda...@gmail.com
> <mailto:dougfoster.emailstanda...@gmail.com>> wrote:
>
> I mean something different.
>
> By "user-to-domain" I mean a DNS function which asserts:
> When the message is signed by IETF, and the From address is my account, the
> message is considered authenticated by this DNS entry.
> If the message is signed by IETF but the From address is a different account
> in the same domain, the message is not authenticated by this DNS entry.o
That’s the conceptual TPA protocol theory. Consider SPF has a TPA system when
the possible external MTA (smtp client machine) was “authorized” by IP address.
It took a while before domains were adding -include _spf.google.com
<http://spf.google.com/> to their SPF primary domain records. Conceptually,
that is what ATPS, TPA, DSAP ideas offered to DKIM+ADSP and now DKIM+DMARC.
> We have three uses cases:
> The owner of an account on a mailbox provider such as Gmail, who wants to
> create an ESP account for mass mailings. Girl Scout troops were mentioned
> as a community that had this problem after the Yahoo lockdown.
>
> The subscriber to a mailing list who wants to authorize the list owner to
> send messages using his From identity. We all have this problem.
>
> And the newly introduced problem of the domain owner who is not willing to
> delegate a DKIM scope. They might be willing to authorize the ESP to send
> messages on behalf of market...@example.com <mailto:market...@example.com>,
> until they realize that it also authorizes the ESP to send on behalf of
> c...@example.com <mailto:c...@example.com> . The ESP is willing to accept a
> DKIM scope, but the management sees the delegation as too risky.
1) This scenario is a typical one. Mailing list had early esp domains,
yahoo.com <http://yahoo.com/>, gmail.com <http://gmail.com/>, msn.com
<http://msn.com/>, so many that become “spam-polluted” that at one point, I was
among those calling for a flat out block of these highly abusive domains. I
give many kudos for AOL.COM <http://aol.com/> to start with a hard reject with
SPF and jump start the MARID working group that began the SPF and the DKIM era.
YAHOO.COM <http://yahoo.com/> finally said enough with DMARC p=reject and why
not? Yahoo invented DomainKeys with the reject concept "o=-“ tag on the
signature, no DNS lookup needed. So no one should be surprise that the patented
idea finally was activated via DMARC p=reject.
2) This scenario is also typical - the subscriber with DNS control of the
domain to add an authorization record. That would be me and a good bit of the
developers here.
3) This is not new. In fact, it has been the #1 reason for DKIM with a POLICY
enforcement concept. It is the #1 payoff. It was the strongest, the most
restrictive policy. Original DKIM had o=- which was split into SSP with other
o= signing patterns, which was replaced with ADSP with Discardable and now
DMARC with p=reject. The concept was so powerful, the Functional
Specification for SSP indicated that it MUST NOT trump local policy. What
happen with DMARC causing From Rewrite is a reminder of local policy can not be
controlled by author domain policy.
>
> To solve these use cases, we need a DNS lookup that is based on the fully
> qualified From address and the DKIM domain. In concept, it seems like a
> straightforward extension of any of the third-party signing strategies.
The Domain Policy Model I believe is sufficient than a Domain User Policy. It
would also be Using email address would need to be manageable via DNS.
TPA has scoping logic that was too complex for me to follow. ATPS was simpler.
You might follow Doug Otis’s TPA better than I did.
>
> What I see as the primary difficulty is the need to publish a DNS entry which
> is specific to my email account, without announcing to every spammer in the
> world that my account is an available spam target. Hashing helps, but
> creates collisions. To avoid side-channel authorizations, we need a way to
> disaggregate collisions. ATSP does that by providing the domain name in
> cleartext, but that I don't see that as acceptable for a user account. Some
> critics may argue that hashing is not an adequate data-hiding technique
> anyway,
>
> It would be the solution to the great mailing list problem if we can make it
> work. But is that possible?
We can make anything happen with software changes. This requires changes to
legacy mail unit operations, MSA, MDA, MLS, MTA, the C/C++ SMTP developers, the
Mail Men, the transporters, and changes to the "low code” that makes up MLM
scipts for the Administrators.
For a long time, starting with FidoNet [1] and also with the IETF too, I
experienced a good bit of the debates with future methods and directions was
often a clash between Developers vs Administrators. Basically software
developers want to do it right - cross all the tees, dot all the eyes, make it
logical and protocol complete. So it was too easy to see ADSP/DMARC were not
protocol complete from a software engineering standpoint. In the case, the
needs of MLM administrators prevailed in this long debate. They want
developers hto write options, switches, backend script languages, and hookling
methods for the Admins to use. That is called Local Policy provisional
processing. But even if the RFC says to do XYZ (DMARC p=reject), the local
policy does ABC (From Rewrite).
We are basically trying to convince local policy operators to pay attention to
DMARC in both directions because not doing so is causing software developers to
reluctantly serious make changes to mail products and tools, create more junk
like ARC, like a rewrite to tear down security if it can’t be worked out right
with among all.
[1] https://en.wikipedia.org/wiki/FidoNet
—
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
