On Thu 06/Jan/2022 22:50:42 +0100 John Levine wrote:
It appears that Alessandro Vesely said:
On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote:
I perceive a false assumption that when a sender does not publish
p=reject, then his messages cannot be blocked for failure to validate,
and
On Thu, Jan 6, 2022 at 8:12 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Protocols are created to solve a problem, and solution design should
> include both normal operation and failure management.That’s why
> electrical panels use circuit breakers instead of simple on-off
Protocols are created to solve a problem, and solution design should
include both normal operation and failure management.That’s why
electrical panels use circuit breakers instead of simple on-off switches.
In this current case, we are defining an access control system for email,
so we have ea
On Thu, Jan 6, 2022 at 3:32 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> There are good reasons for talking about a default DMARC policy. It is
> certainly not to give evaluators permission, because we know that
> evaluators can do whatever they want, and they will do what t
It appears that Alessandro Vesely said:
>On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote:
>> The point of a specification like this is to understand each
>> participant's best interest and channel that toward the common goal.
>> I perceive a false assumption that when a sender does no
On January 6, 2022 9:34:44 PM UTC, Douglas Foster
wrote:
>Please explain what you think is wrong and why. We are not voting yet, we
>are discussing.
This being the IETF, we aren't voting.
Scott K
___
dmarc mailing list
dmarc@ietf.org
https://www
What is the basis of your conviction that everyone knows how to use SPF and
DMARC validation properly?
It ceased to be my perception when I tried to buy an email filtering
product that implements DMARC.
Doug
On Thu, Jan 6, 2022 at 11:07 AM John Levine wrote:
> It appears that Murray S. Kuchera
Please explain what you think is wrong and why. We are not voting yet, we
are discussing.
On Thu, Jan 6, 2022 at 11:18 AM Dave Crocker wrote:
> On 1/6/2022 3:32 AM, Douglas Foster wrote:
> > Consequently, the best way for senders to avoid delayed or blocked
> > messages is to avoid getting clo
On Thu 06/Jan/2022 12:32:17 +0100 Douglas Foster wrote:
The point of a specification like this is to understand each
participant's best interest and channel that toward the common goal.
I perceive a false assumption that when a sender does not publish
p=reject, then his messages cannot be bl
On 1/6/2022 3:32 AM, Douglas Foster wrote:
Consequently, the best way for senders to avoid delayed or blocked
messages is to avoid getting close examination. This is facilitated
by ensuring messages are both DKIM-verifiable and SPF-PASS, regardless
of DMARC policy. P=NONE or T=Y or no policy
>> Consequently, the best way for senders to avoid delayed or blocked
>> messages is to avoid getting close examination. This is facilitated by
>> ensuring messages are both DKIM-verifiable and SPF-PASS, regardless of
>> DMARC policy. P=NONE or T=Y or no policy are not valid substitutes. ...
No
It appears that Murray S. Kucherawy said:
>I would argue that it's well understood by now that DKIM and SPF "pass"
>results are the only things that convey usable information.
I agree. I've never seen anyone have any trouble figuring out what SPF or
DKIM inputs to feed into DMARC and don't see
On Thu, Jan 6, 2022 at 6:32 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> There are good reasons for talking about a default DMARC policy. It is
> certainly not to give evaluators permission, because we know that
> evaluators can do whatever they want, and they will do what t
There are good reasons for talking about a default DMARC policy. It is
certainly not to give evaluators permission, because we know that
evaluators can do whatever they want, and they will do what they deem to be
in their best interest.
The point of a specification like this is to understand eac
On Tue, Jan 4, 2022 at 4:53 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> [...]
> The PASS-centric approach is the only one that makes sense to me. This is
> why I have lobbied for changes to the introduction to explicitly state that
> FAIL is an ambiguous result. If you acc
There are two possible approaches to DMARC.
One approach says that FAIL should be reliably true, and non-FAIL for any
reason is ambiguous. This means that domain owners should only publish a
reject policy when there is no possibility that their messages pass through
mailing list or any other pat
On Mon, Dec 27, 2021 at 8:33 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> I suggest the language should be more like this:
>
> If the set produced by the DNS Tree Walk contains no DMARC policy record
> (i.e., any indication that there is no such record as opposed to a
> transi
This question is about this paragraph:
5.7.2.1. DMARC Policy Discovery
If the set produced by the DNS Tree Walk contains no DMARC policy record
(i.e., any indication that there is no such record as opposed to a
transient DNS error), Mail Receivers SHOULD NOT apply the DMARC mechanism
to the messag
18 matches
Mail list logo
