+1, but the concern of not informing suspicious parties about local
policies should then be risen in aggregate-reporting, Security
Considerations (currently blank), shouldn't it?
The current wording makes an attempt to distinguish overrides due to
authentication failures, such as mailing list, from reject or quarantine
decisions made /after/ dmarc=pass, such as obvious spam. The latter are
not to be reported, and the action disposition left to none in those cases.
Indeed, that is what a DMARC filter actually knows.
Best
Ale
On Sun 28/Aug/2022 15:08:51 +0200 Dotzero wrote:
+1 to Scott's suggestion.
Michael Hammer
On Sat, Aug 27, 2022 at 5:49 PM Barry Leiba <barryle...@computer.org> wrote:
I’m happy with Scott’s suggestion.
Barry
On Sat, Aug 27, 2022 at 5:11 PM Scott Kitterman <skl...@kitterman.com>
wrote:
On Thursday, August 25, 2022 1:43:49 PM EDT Barry Leiba wrote:
On Wed 24/Aug/2022 21:40:20 +0200 Barry Leiba wrote:
I think “SHOULD do what the domain owner says” is too strong, and
propose to change it. By making it that strong we vary from the
policy that recipients use all the input they have to make their
handling decision, and we tell them that using this input alone is
normatively required for interoperability/security. I think that’s
wrong.
I suggest this alternative text:
NEW
A Mail Receiver implementing the DMARC mechanism gets the Domain
Owner’s or PSO's published DMARC Domain Owner Assessment Policy
when a message fails the DMARC test, and uses it as an important
factor in deciding how to handle the message.
I agree that blindly following the remote policy is a hazard.
(Personally,
I enable that on a restricted set of domains only.) However, the
above
text is too generic and slightly inexact. You actually get the policy
/before/ concluding the evaluation. DMARC result is an important
factor
also if it is a pass or a none.
The above snippet can be skipped.
The above snippet is just a slight change to what was already there,
and I think it's useful to keep it... but I think I did change the
sense of it when I rephrased it. In the original, "when a message
fails the DMARC test" was attached to the action that the receiver
should take. In mine, that attachment is lost.
Maybe this rewording works better?:
NEW-2
A Mail Receiver implementing the DMARC mechanism gets the
Domain Owner’s or PSO's published DMARC Domain Owner Assessment
Policy and uses it as an important factor in deciding how to
handle the message. When a message fails the DMARC test, Mail
Receivers should make a best-effort attempt to comply with the
published policy, but email streams can be complicated (due to
forwarding, existing RFC5322.From domain-spoofing services,
etc.) and Mail Receivers may have other information that can
inform their decisions.
When Mail Receivers deviate from a published Domain Owner
Assessment Policy during message processing they SHOULD make
available the fact of and reason for the deviation to the Domain
Owner via feedback reporting, specifically using the
"PolicyOverride" feature of the aggregate report defined in
[DMARC-Aggregate-Reporting].
END
I think that retains the connection that I lost in the first attempt.
In this part of the document, I think the phrase "best-effort" is a
problem.
A "best-effort" to comply with the policy is pretty trivial to do: if it
fails
and the policy is reject, then reject. That's not actually what we
want.
This section is a non-normative paraphrase of part of Section 5.8. I
think it
would be better to shorten it and reference Section 5.8. Also, this says
SHOULD use PolicyOverride. Section 5.8 currently discourages it.
We ought to decide if we want to discourage or encourage reporting of
policy
overrides. I think encourage is the right answer. Based on that
approach,
I'd suggest the following changes:
In place of the above:
NEW-3
A Mail Receiver implementing the DMARC mechanism gets the
Domain Owner’s or PSO's published DMARC Domain Owner Assessment
Policy and uses it as an important factor in deciding how to
handle the message. Mail handling considerations based on DMARC
policy enforcement are discussed below in [section-5.8].
END
And this additional change in Section 5.8:
Replace:
Mail Receivers should only report reject or quarantine policy actions
in aggregate feedback reports that are due to published DMARC Domain
Owner Assessment Policy. They need not report reject or quarantine
actions that are the result of local policy. If local policy
information is exposed, abusers can gain insight into the
effectiveness and delivery rates of spam campaigns.
with:
When Mail Receivers deviate from a published Domain Owner
Assessment Policy during message processing they SHOULD make
available the fact of and reason for the deviation to the Domain
Owner via feedback reporting, specifically using the
"PolicyOverride" feature of the aggregate report defined in
[DMARC-Aggregate-Reporting].
I think this reduces duplication and inconsistency without losing
anything.
the proposed new text in 5.8 is a direct move of the proposed Section 5
text
on including feedback based on local policy overrides.
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
