No. That's not how DMARC records work and there's no reason to make psd=y
mean anything other than "don't use this domain when evaluating alignment".
Scott K
On Tuesday, January 18, 2022 5:44:34 PM EST Douglas Foster wrote:
> You could declare that "DMARCv1 psd=y np=reject" is a valid policy, t
You could declare that "DMARCv1 psd=y np=reject" is a valid policy, that
psd=y implies p=reject but is not inherited, so that sp result is "do not
check".
I think this is what you want.
On Tue, Jan 18, 2022 at 4:32 PM Todd Herr wrote:
> On Tue, Jan 18, 2022 at 4:17 PM John Levine wrote:
>
>> I
First: I note that you did not answer my direct questions. Please
consider that when you see that people aren't understanding you.
> I test every message for SPF, aligned SPF, and aligned verified DKIM. With
> one exception mentioned below,
> I don't block on FAIL, but I do collect data.
...
>
I test every message for SPF, aligned SPF, and aligned verified DKIM.
With one exception mentioned below, I don't block on FAIL, but I do
collect data.
Most legitimate messages produce at least SPF, many messages have DKIM
signatures. I receive very little forwarded mail. So most messages pass
On Tue, Jan 18, 2022 at 4:17 PM John Levine wrote:
> It appears that Todd Herr said:
> >If the intent of the tree walk is, at least in part, to allow for
> >publishing of policy records at the PSD level and for those records to be
> >inherited by existing subdomains (e.g., _dmarc.tld is inherit
On Tuesday, January 18, 2022 4:16:57 PM EST John Levine wrote:
> It appears that Todd Herr said:
> >If the intent of the tree walk is, at least in part, to allow for
> >publishing of policy records at the PSD level and for those records to be
> >inherited by existing subdomains (e.g., _dmarc.tld
It appears that Todd Herr said:
>If the intent of the tree walk is, at least in part, to allow for
>publishing of policy records at the PSD level and for those records to be
>inherited by existing subdomains (e.g., _dmarc.tld is inherited by
>domain.tld if domain.tld does not publish its own poli
Maybe I'm misunderstanding what you mean by "testing every message",
so let me ask it this way:
- A message says it's from ba...@gloob.example.com
- If you can authenticate that through DKIM or SPF, you have an
authenticated message from gloob.example.com. What do you do next,
and how does that r
Alas, there is no convincing this group, but the missed opportunity is so
great:. By testing every message, I learn that 81% of domains and 93% of
messages are able to authenticate using DMARC rules. (Statistics taken
after sender reputation blocks have excluded the known offenders.)
Compare t
On Tue, Jan 18, 2022 at 1:13 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Michael, you ducked the question.
>
> If a domain owner has a right to not participate in DMARC, why are we
> removing that right with PSD policies?
>
I said in an earlier message in this thread that I
Michael, you ducked the question.
If a domain owner has a right to not participate in DMARC, why are we
removing that right with PSD policies?
Either participation is optional or it is not.Which is it?
This right to not participate is based on an assumption that DMARC will be
used to block l
On Tue, Jan 18, 2022 at 11:58 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Why should the protocol provide a carve-out for non-participating domains?
>
I would think that "non-participating domains" would be self explanatory.
Non-participating is a choice not to participate,
On 1/18/2022 9:11 AM, Barry Leiba wrote:
I think what's*also* outside the intent is for the receiver to infer
anything in absence of any statement by the domain owner. Do you
disagree with that?
Heck no.
Since there is nothing in DMARC that mandates that it be used, and
nothing normative th
On Tue, Jan 18, 2022 at 11:58 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Why should the protocol provide a carve-out for non-participating domains?
>
I don't see a "carve-out". If a domain doesn't publish a DMARC policy
record, that's one less thing that a mail receiver has
I think what's *also* outside the intent is for the receiver to infer
anything in absence of any statement by the domain owner. Do you
disagree with that?
Barry
On Tue, Jan 18, 2022 at 12:08 PM Dave Crocker wrote:
>
> On 1/18/2022 9:04 AM, Barry Leiba wrote:
> >
> > If a receiving domain wants
On 1/18/2022 9:04 AM, Barry Leiba wrote:
If a receiving domain wants to use DMARC in its decision process,
outside what the purported sending domain says, that's, as Todd says,
its choice, but is outside of the intent, and therefor the
specification, of DMARC.
Ahem. A mechanism that inclu
On 1/18/2022 7:33 AM, Todd Herr wrote:
On Tue, Jan 18, 2022 at 9:36 AM Douglas Foster
wrote:
I entirely agree that the DMARC result is different from the
wanted/unwanted result. If my opening failed to convey that, it
was not intentional. My real point was that DMARC is, or sho
The point of DMARC is to allow sending domains to specify a policy to apply
to unauthenticated mail that purports to be from them. In that sense,
DMARC is for the senders.
If a receiving domain wants to use DMARC in its decision process, outside
what the purported sending domain says, that's, as
It appears that Dave Crocker said:
>-=-=-=-=-=-
>
>On 1/18/2022 5:51 AM, Todd Herr wrote:
>> I don't agree with the goal statement here, because it implies to me
>> that all messages that pass DMARC validation are safe and wanted,
>> while all messages that do not pass DMARC validation are mali
Why should the protocol provide a carve-out for non-participating domains?
Similarly, if the carve-out is really important, what are we to do about
PSD policies, since they take away the carve-out.? I suppose we could
create a clause for PSD policies to say sp="NoCheck", but we have not yet
done
On Tue, Jan 18, 2022 at 11:38 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> "Demolish" should have been limited to the notion that a domain owner has
> a "right" to not be DMARC-evaluated, because he has not published a
> policy. With tree walk, every message will have either
"Demolish" should have been limited to the notion that a domain owner has a
"right" to not be DMARC-evaluated, because he has not published a policy.
With tree walk, every message will have either a domain-published policy
or a PSD policy.
A message asking for entrance to my network has NO rights
On Tue, Jan 18, 2022 at 9:36 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I entirely agree that the DMARC result is different from the
> wanted/unwanted result. If my opening failed to convey that, it was not
> intentional. My real point was that DMARC is, or should be, fo
On 1/18/2022 5:51 AM, Todd Herr wrote:
I don't agree with the goal statement here, because it implies to me
that all messages that pass DMARC validation are safe and wanted,
while all messages that do not pass DMARC validation are malicious,
and neither statement is true.
Let me provide, in q
I entirely agree that the DMARC result is different from the
wanted/unwanted result. If my opening failed to convey that, it was not
intentional. My real point was that DMARC is, or should be, for the
benefit of the evaluator.
Specifically, I have trouble with the language about "Domain owners
On Sat, Jan 15, 2022 at 10:14 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
>
> DMARC Goal
>
> The goal of DMARC is to help evaluators make correct disposition
> decisions, so that safe and wanted messages are allowed while malicious and
> unwanted messages are blocked. It does
26 matches
Mail list logo
