Hi,
On 1/26/2018 3:23 PM, Brandon Long wrote:
I sometimes override DMARC p=quarantine failures with filters, does
DMARC require a filters extended tag and compliance by mail clients to
not allow overriding of the filters if the domain requests it?
Local Policy always prevails. But we all work towards developing a
common protocol and hopefully, and ideally, do so on a cooperative
competitive basis where all nodes are treated the same at the protocol
level. The add-on value may be what the implementation may offer at
the local level to customers, i.e. features, options, etc.
I believe the intent of the domain is his published policy record. If
a restrictive policy is published, the receiver should not presume it
did not mean it. When failure is detected, the author domain with a
restrictive policy is given the world permission to treated it harshly.
See RFC5016, "Requirements for a DomainKeys Identified Mail (DKIM)
Signing Practices Protocol." Also note section 5.3 Item 10
which basically reminds us about Local Policy expectations.
But to me, thats just a protocol option:
How should DMARC failures be handled?
(o) Reject with _55x_ SMTP rejection code
(_) Quarantine to user's spam box.
[X] NEW! Check for the DMARC arc= tag.
etc.
I will have something like that in my implementation and even more
options as we learn more how ARC is suppose to operate and fit in with
the rest of the DKIM/POLICY/TRUST architectural model and system.
Others may automatically presumed everything is accepted (250 reply
code) and put into the user's spam box where it can be eyeballed by
them (or completely forgotten by them). Some here strongly believe
that is the only to operate (never reject). I believe in options.
My point is, fundamentally in the mail eco-system, whether something
is delivered or rejected or labeled as spam is at the discretion of
the receiver. Having increasing levels of "but I really mean it" for
DMARC is not useful.
yes, thats a given, always, Local Policy always prevails.
But that is exactly why the extended policy signal would offer a more
explicit indication of the the domain's intent. With no tag, there is
an element of "fuzziness" for the receiver on whether it is doing the
right thing.
If the domain has arc=0, then the compliant ARC/DMARC receiver SHOULD
honor the intent of the protocol when the policy is restrictive. If
the domain has arc != 0, then the compliant ARC/DMARC receiver CAN|MAY
use ARC to preempt a restrictive policy DMARC failure.
There is no ambiguity now, both technically and legally, if I may add,
presuming that there may be DMARC domains who do not want any ARC
processing of failed mail, using ARC to bypass a True Positive failure
may have some level of liability concerns. i.e. you can't ignore this
consideration.
Also, the sender doesn't implement ARC, so why should they care?
Because of the point above. Its always better to be protocol specific.
Also consider the ARC-ignorant receiver (who just doesn't know
anything about it) but it supports DMARC, it may honor restrictive
policies. That would be the DMARC protocol expectation. It would
behave with an default 'arc=0" policy when it reads a DMARC record
because it knows nothing about it.
Also, I think some of this already happens today based on reports. We
get complaints about where we override DMARC from domains all the
time, and that goes into our work on making our overrides more
correct. I don't see how arc=n helps that at all.
There will be domains who will not want to participate in a concept
that can bypass true positive DMARC failures -- it can be viewed as
security loophole.
Having an indicator will definitely help receivers with their
processing logic, including development and usage of APIs. Without
it, ARC will add a new element of DMARC processing fuzziness unless
you are presuming that any receiver even contemplating ARC implies
that the receiver is automatically going to ignore author domain
wishes. Be careful with that because that would be enough for some
implementators and domains to nix the whole ARC idea.
If you wanted to
help that, you'd want some mechanism or automation with which a domain
owner could tell a particular mailbox provider that they're doing a
bad job, and that's a lot more complicated than arc=n.
Yes I would think that would be more complex, but also a different
idea. Receivers are already doing a DMARC lookup. Adding an extended
tag like "arc=" will assist receivers in how to process failures
without ambiguity.
To me, the only real protocol design question would be what ARC would
recommend as the default "arc=" value. Using "arc=1" as the default
would presume ARC can bypass any DMARC failure without explicit
permission from the Author Domain. The burden would be on the current
DMARC p=reject/quarantine policies domains to add an "arc=0" to tell
receivers "Please don't skip failures by using ARC."
Thanks
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
