On Thu 03/Aug/2023 21:15:57 +0000 Murray S. Kucherawy wrote:
On Thu, Aug 3, 2023 at 10:39 AM Hector Santos <hsan...@isdg.net> wrote:
[...]
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.
I agree with Mike about SUBMITTER/PRA. However, while I disagree with
Dave's proposal to use Sender: instead of From:, some kind of advice could
still be derived therefrom.
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
That seems gratuitous (assuming Submitter=Sender:'s domain). If I publish
p=none but SPF -all it still means reject (up to whitelists) unless the
receiver follows DMARC advice of disregarding SPF policy, but then that's
based on From:, not Sender:.
- 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.
Ah, interesting.
I don't think this should go in the base document, since the research we
did for RFC 6686 suggests that deployment of SUBMITTER, at least as of that
document's publication, wasn't very broad. However, if the size of the
problem is substantial, and this solution turns out to be potentially
effective, this might be fodder for the applicability statement or usage
guidelines document that this WG has discussed producing in the past as a
possible enhancement.
Collecting some data and doing some experimentation would be really helpful
toward determining the right path here, if any.
Evaluating Sender: doesn't help whitelisting rejection before DATA.
The message I'm replying to has:
Return-Path: <dmarc-boun...@ietf.org>
Sender: "dmarc" <dmarc-boun...@ietf.org>
To find the added value of Sender:, we'd be looking for a class of
forwarders, not mailing lists, where these identifiers differ.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
