On 8/3/2023 2:07 AM, Murray S. Kucherawy wrote:
On Mon, Jul 31, 2023 at 9:47 AM Hector Santos
<[email protected]
<mailto:[email protected]>> wrote:
- I mentioned using the deprecated SUBMITTER/PRA
(RFC4405/RFC4407)
protocols as an implementation detail to access the author's DMARC
policy at the SMTP "MAIL FROM" stage. Wei expressed interest in
this
idea. This could also enhance the "auth=" idea to help manage local
policy SPF -ALL handling. Should SMTP immediately reject? The
PRA at
SMTP could aid this decision for SPF -ALL policies. Based on many
years of implementation, it's evident that many mailers are either
identical or are using the same software that supports
SUBMITTER/PRA,
possibly due to ongoing support for the deprecated SenderID
(RFC4406)
protocol. [...]
Can you or Wei spell this out a little more? What could a list
subscriber do with this algorithm that we don't have today?
The issue we're facing in a DMARC world isn't determining who the
original sender is, but rather that with broken signatures, we can't
prove it to DMARC's satisfaction. I'm not clear on how your idea
fixes that.
The utilization of SUBMITTER/PRA protocols possibly can help manage
situations where SPF fails before any DKIM information is accessible.
This strategy provides SPF processors with preliminary DMARC policy
data, potentially mitigating the impact of SPF hard-fail situations.
The advantages of this approach are especially clear when SPF fails,
but DMARC can help to temper the initial rejection.
Through the SUBMITTER/PRA, it's possible to ascertain the presence of
a DMARC p=none or an auth=dkim, giving operators the choice to delay
immediate rejection and verify DKIM instead.
In the context of a mailing list, using a SUBMITTER in the
distribution can prove useful. For instance, a list might not need to
rewrite if it identifies an auth=spf for the domain, allowing it to
function as a resigner although the original domain integrity was
broken. There might be a auth=arc which ARC is needed for pass
broken 1st party signature.
I know this is out of scope, but legacy scenarios may included
checking for the 'atps=y' tag and check for an ATPS DNS authorization
record for the resigner domain. There still many domains who don't use
DMARC but instead still have ADSP dkim=all to expose a mail policy -
"Expect all my mail to be signed."
However, at present, the most plausible use-case appears to be the
addition of delayed SPF rejection scenarios through DMARC evaluation.
Essentially, SUBMITTER/PRA serves as an optimizer and a mechanism to
soften the impact of SPF -ALL policies.
The approach might work as follows:
- If SPF fails and the Submitter indicates p=reject, then reject
(comes with its acceptable problems)
- If SPF fails, the Submitter specifies p=reject and auth=dkim, then
proceed to transfer the payload and evaluate DKIM
- If SPF fails and the Submitter signifies p=none, then continue with
payload transfer
- If SPF fails and the Submitter designates p=quarantine, then proceed
with payload transfer
SUBMITTER may help align SPF with its original DMARC purpose—combining
SPF+DKIM results while keeping with some level of optimization.
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
