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
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
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
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
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
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.
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
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
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
>> 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. ...
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
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
13 matches
Mail list logo
