I'm looking at this through the lens of formerly being a domain owner for a
complex organization doing a successful DMARC deployment which ended at
p=quarantine for the organization domain primarily housing user-generated
email. A subdomain strategy is employed for most other non-user generated mail.
I have not worked there for 2+ years.
I now work for a much much larger organization which has the same
organizational complexities, but much much more complex. It also houses user
traffic on the organization domain, and it's more mixed-use. It is also at
p=quarantine currently.
My organization also happens to be a large ESP (and as of a few months ago my
primary hat is as a sender). Often, it is the authors within a domain who are
the primary customer instead of the domain owner; DNS records are sometimes
hard to get in place, sometimes impossible. Other times it is the domain owner
who is the primary customer and they express a need to govern the use of our
ESP (and every other ESP) being used by authors within their domains. We also
happen to be in the receiver role for many of our customers, and sometimes
received mail needs to be emitted back outbound.
I wanted to jump in on this thread at some point to stick my foot in my mouth.
I'm not sure which hat I'm wearing. All opinions expressed are my own.
On Fri, Mar 31, 2023, at 10:49 AM, Hector Santos wrote:
>
> On 3/29/2023 9:16 PM, John Levine wrote:
> > It appears that Murray S. Kucherawy <superu...@gmail.com> said:
> >>
> >> This is laid out in RFC 6377, Section 5.2, if it would be helpful to have
> >> something published to reference. Indeed, ADSP threatened the same damage
> >> that DMARC "p=reject" causes, which I think was one of the reasons it never
> >> got adopted.
> > It wasn't just a threat -- someone got bounced off an IETF list shortly
> > after the ADSP draft came out when some eager beaver implemented it.
> >
>
> I was the one who first reported the problem of what will happen when
> the SSP (DKIM Policy) was split from DKIM. I was able to show this
> when the IETF was not yet supporting DKIM.
>
> With the split, DKIM became DKIM-BASE and SSP became ADSP with all the
> 3rd party (re)signer concepts from SSP removed. It went from SSP
> policy which considered 3rd party signers:
>
> o=? WEAK (signature optional, no third party)
> o=~ NEUTRAL (signature optional, 3rd party allowed)
> o=- STRONG (signature required, 3rd party allowed)
> o=! EXCLUSIVE (signature required, no 3rd party)
> o=. NEVER (no mail expected)
> o=^ USER
>
> to a very limited 1st party only policy.
>
> DKIM=DISCARD always expect to be signed by the Author Domain
> DKIM=ALL always expect to be signed but by who?
>
> The only flexibility was DKIM=ALL. We presumed it could allow for a
> 3rd party signer and it would be useful by mailing list servers.
> Unfortunately, we could not resolve how to authorize the 3rd party
> signers and ATPS was said not to scale.
>
> So in my view, its not ADSP, DMARC as the problem -- its a lack of a
> 3rd Party Authorization model in the protocol.
>
> I see more domains are being "dmarca-tized" without their domain owner
> knowledge of what the hosting system is doing nor how the MDA hosting
> will handle mail. This is causing major problems that requires
> drastic mail handling actions.
>
> I now have forwarding mail logic that determine the sender's DMARC
> policy. If weak or none it can be forwarded. If strong, it stays for
> mail pickup.
>
> I long had mailing list subscripting logic to stop a subscriber with a
> strong DMARC policy.
>
> I will probably begin to add a From Rewrite but I would prefer if the
> DMARC record has a domain authorization to do so, with perhaps a
> `-rewrite` tag to signify any form of rewriting allowed.
>
> I think we need to focus more on DMARC having extended tags that
> address many of the issues and ideas we have encountered. Receivers
> want to honor the author domain wishes for handling failure when
> various parts fail to meet their protocol-defined expectations. But
> if honoring going to cause more problems, then we either abandon DMARC
> like we did with ADSP or we add 3rd party domain considerations.
>
> Reject domain polices should support these ideas for handling outbound
> and inbound mail handling.
>
> -p=reject -rewrite -atps
>
> -rewrite
>
> says if the first initiate signer succeeded and you need to resign,
> then you are allowed to rewrite the ADID. This handles list
> distribution problems. If a domain does not have -rewrite, a
> subscriber and list submission MUST be denied.
-rewrite would send a clear signal to the intermediary that the domain owner
wishes for mail to be handled the same way most intermediaries have already
been doing for p=reject|quarantine domains that do not have -rewrite. I don't
think this adds much value for domains that are already p=reject, and it would
cause issues for intermediaries who stop rewriting email for domains that have
not yet become aware of -rewrite being a feature they should adopt
I do like that -rewrite potentially replaces the "p=quarantine pct=0" hack for
domain owners that wish to expose their users to DMARC effects before their
DMARC deployment reaches p=reject. Is this better than the current language in
DMARCbis A.7. Removal of the "pct" Tag, and the description of the "t" tag
t: DMARC policy test mode (plain-text; OPTIONAL; default is 'n').
For the RFC5322.From domain to which the DMARC record applies, the
"t" tag serves as a signal to the actor performing DMARC
verification checks as to whether or not the domain owner wishes
the assessment policy declared in the "p=", "sp=", and/or "np="
tags to actually be applied. This parameter does not affect the
generation of DMARC reports. Possible values are as follows:
y: A request that the actor performing the DMARC verification
check not apply the policy, but instead apply any special
handling rules it might have in place, such as rewriting the
RFC5322.From header. The domain owner is currently testing its
specified DMARC assessment policy.
n: The default is a request to apply the policy as specified to
any message that produces a DMARC "fail" result.
I can see the argument that "rewrite" is more descriptive than "policy test",
especially if inducing rewriting is the sole purpose of the "t" tag. And it
allows the domain owner to indicate rewriting is preferred after a p=reject
deployment, long after "policy testing" is complete.
This wording might imply that rewriting might stop after ""testing" is complete
after a p=reject deployment
> -atps
>
> says if we ADID does not equal SDID then we will do an SDID ATPS
> lookup at the ADID zone. This handles reception for all mail. If a
> domain does not have -atps, then the receiver MUST honor the domain
> reject policy for failures.
I just read https://datatracker.ietf.org/doc/rfc6541/ (or, re-read, I can't
remember)
I'm struggling to understand how ATPS is significantly better than delegation
via DKIM CNAME records. I can see that it's simpler for a domain owner because
they need only set 1 ATPS record vs. sometimes 3 CNAME records (for key
rotation). But that's not enough to justify adoption.
Consider domain owners who (1) have a strong brand association with their
organizational domain, (2) the domain allows normal user email as the primary
use case, (3) and is moving to p=reject despite IETF's warnings not to. These
security-minded domain owners also aren't willing, or are reluctant, to
authorize an ESP to have delegated authorship over 100% of its email address
space just because one use case within their organization has a valid reason to
use the ESP. Hence they may not do DKIM CNAME delegation any more/less than
they might use ATPS. They might resort to pushing their sub-organizations to
sub-domains over time and take advantage of psd=y, but it's already past the
point; the domain will have a ratio of mixed-use indefinitely.
Does ATPS help solve that problem? Perhaps, if it can offer more fine-grained
authorization.
I could see these domain owners willing to leverage a protocol like ATPS if
they could authorize delegated authorship down to individual email addresses.
That level of control may be enough to pique the interests of security-minded
domain owners who want to allow tightly-controlled mixed-use of the
organizational domain.
What would the freemail domains do with ATPS? Maybe the same thing, more
slowly, if they care. I can only speculate here.
The authors within the domain (users of the MBP) aren't allowed to publish
anything in DNS and the domain owners see no point in explicitly authorizing
every ESP to use every address within their domains. Leave it for the receivers
to figure out. There is some assumption that freemail domains need to be
spoofable by any potential ESP (maybe with some batteries/reputational model
required by the receiver); and this assumption is being codified by MUST NOT
p=reject [*]. Address-level delegation via ATPS might be something MBPs would
be willing to support since they are typically also the receivers and may have
a desire to reduce dependence on the required batteries. But in the end, they
will need to share some of the same motivation of non-freemail domains to
protect their domain from spoofing or a desire to have stronger governance.
Considering both scenarios, we would be in a state where ATPS is allowing for
more mail to be authenticated, but not in a state where we know all of the mail
is being authenticated for any particular domain. I read that -atps would mean
that the domain supports ATPS, but doesn't convey that it has 100% coverage.
Without knowing that there is an acceptable level of coverage, to prevent
complaints, the intermediary may err on the side of caution and continue to
rewrite for domains with p=reject|quarantine, and not rewrite otherwise.
So, ATPS offers a status quo for the intermediaries' rewrite logic. But I do
like the idea of more fine-grained authentication, if it's even possible.
How about from the point of view of an ESP? Should an ESP behave any
differently than an intermediary when emitting mail from domains with p=reject?
If the domain has p=reject and no mechanism has been provided for the ESP to
send authenticated email. Which makes more sense?
(1) The ESP honors the domain owner's policy and it does not allow its customer
to emit mail using the domain. (AKA the winserver.com approach). The ESP could
offer its customers to use a provided domain, perhaps with the original address
encoded within the address/friendly from, setting the Reply-to, and some other
approach to effectively emit the mail with some brand/authorship association
while honoring the domain owner's policy
(AKA the rewrite approach)
(2) The ESP determines that the domain is used by humans, which it does by
means of its author verification process, ignores the domain owner's policy,
and allows its verified-authors to choose to have the ESP emit the mail using
their verified address within the domain, relying on the receiver to decide if
the mail is trustworthy without an authentication mechanism
(AKA the approach of a MLM who has not mitigated DMARC's damaging effects
because they must not be forced to)
It seems, with (2), we're presuming every receiver has an ability to know of
the author verification process of each non-authorized sender (ESP,
intermediary, or otherwise), and they feed it into their opaque/individualized
reputation models.
With (1), receivers only need to rely on domain reputation and less on a
non-existent intermediary reputation mechanism.
In summary:
a. -rewrite seems to be more logical than t=y to signal a permanent desire for
intermediaries and ESPs not to emit non-authenticated mail using the domain,
regardless of the domain's policy (possibly with a different term like
-no-squatters ;-)
b. An address-level authentication mechanism via a modified version of ATPS
could reduce the amount of non-authenticated mail and reduce ambiguity
regarding the domain owner's preferences
Jesse
[*] and all non-freemail domains have to choose between being lumped into the
same mail handling treatment, or opt for p=reject by ignoring the MUST NOT _______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
