> On Nov 12, 2023, at 4:00 AM, Alessandro Vesely wrote:
>
> On Sat 11/Nov/2023 14:57:12 +0100 Neil Anuskiewicz wrote:
On Oct 23, 2023, at 11:00 AM, Alessandro Vesely wrote:
>>> My opinion is that Barry's text is good as is. As far as delimiting a
>>> SHOULD NOT with another SHOULD is
MUST NOT or SHOULD NOT make little difference. Both are the Crocker
Proposal revived and simplified: "The solution to authentication problems
MUST be LESS AUTHENTICATION!"If you can convince nearly all senders to
use p=NONE, and if you can convince nearly all evaluators to enforce only
when
I’m a little slow responding to this; my apologies for that.
On 23 Oct 2023, at 1:03, Francesca Palombini wrote:
> I believe there is a rough consensus that a change needs to be made in the
> text to include stronger requirements admonishing operators against deploying
> DMARC in a way that cau
On Sat 11/Nov/2023 14:57:12 +0100 Neil Anuskiewicz wrote:
On Oct 23, 2023, at 11:00 AM, Alessandro Vesely wrote:
My opinion is that Barry's text is good as is. As far as delimiting a SHOULD
NOT with another SHOULD is legit, this sentence sounds clear to me:
It is therefore critical that
> On Nov 11, 2023, at 7:24 PM, Steven M Jones wrote:
>
> On 11/12/23 03:59, Neil Anuskiewicz wrote:
>> What is the definition of rough consensus. That is if you took a vote, 100
>> people voted yes and 3 voted no, the three win? Id there’s a document that
>> states these rules I’d be happy t
On 11/12/23 03:59, Neil Anuskiewicz wrote:
What is the definition of rough consensus. That is if you took a vote, 100
people voted yes and 3 voted no, the three win? Id there’s a document that
states these rules I’d be happy to dig into it. If there’s a rule we should
have a vote. Who is entit
> On Nov 11, 2023, at 11:06 AM, Scott Kitterman wrote:
>
> The short answer is it depends. We don't vote.
>
> Here's the longer answer:
>
> https://datatracker.ietf.org/doc/html/rfc7282
>
> Scott K
>
>> On November 11, 2023 6:59:20 PM UTC, Neil Anuskiewicz
>> wrote:
>> What is the defin
The short answer is it depends. We don't vote.
Here's the longer answer:
https://datatracker.ietf.org/doc/html/rfc7282
Scott K
On November 11, 2023 6:59:20 PM UTC, Neil Anuskiewicz
wrote:
>What is the definition of rough consensus. That is if you took a vote, 100
>people voted yes and 3 vot
What is the definition of rough consensus. That is if you took a vote, 100
people voted yes and 3 voted no, the three win? Id there’s a document that
states these rules I’d be happy to dig into it. If there’s a rule we should
have a vote. Who is entitled to vote? Like I’m new to this and so it’d
> On Oct 23, 2023, at 11:00 AM, Alessandro Vesely wrote:
>
> My opinion is that Barry's text is good as is. As far as delimiting a
> SHOULD NOT with another SHOULD is legit, this sentence sounds clear to me:
>
> It is therefore critical that domains that host users who might
> post
> On Oct 28, 2023, at 5:01 AM, Alessandro Vesely wrote:
>
> On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely
>>> wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
If there isn't a consensus to do a DKIM-only
On a theoretical level, probabilistic tools like spam assassin will be
predictably wrong some of the time. Accurate disposition requires audits
and overrides using static rules based on confirmed evidence. I cannot
find much sympathy for sites that enforce SPF without considering DKIM and
withou
On Sun 29/Oct/2023 21:03:17 +0100 Mark Alley wrote:
Giving this some more thought from the opposite point of view... the benefits
to an auth=DKIM method in DMARC itself would remove the need for domain owners
to do SPF tinkering for any upgrade mitigation, and shared mail infrastructure
where o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Douglas Foster
writes
>By contrast, the new tag cannot be effective until DMARCbis is published
>and filtering software updated. This involves years.
Hard to say ... there is some self-interest here in having shiny new
features (such
Murray S. Kucherawy writes:
> On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated. This involves years. Even then, domain
> owners
On Sun, Oct 29, 2023 at 12:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> By contrast, the new tag cannot be effective until DMARCbis is published
> and filtering software updated. This involves years. Even then, domain
> owners will never have confidence that the new token
Giving this some more thought from the opposite point of view... the
benefits to an auth=DKIM method in DMARC itself would remove the need for
domain owners to do SPF tinkering for any upgrade mitigation, and shared
mail infrastructure where one could potentially be affected by SPF upgrade
could in
Reporting allows certainty within the limits of the reporting mechanism.
My inference is that many domains stop at p=none for an extended period or
forever because the reporting mechanism does not provide that certainty.
For my part, I backed away from reject when I received fail-with-reject
repor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Douglas Foster writes
>* auth=DKIMOnly requires that the domain owner have high confidence
> that every message source is applying DKIM signatures.
which of course the reporting mechanism allows them to acquire
- --
richard
I have become persuaded to Scott's approach, as long as it is documented
clearly.
For DMARC-enabled evaluators:
- auth=DKIMOnly requires that the domain owner have high confidence that
every message source is applying DKIM signatures.
- ?include=hostingservice only requires knowledge tha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Wei Chuang writes
>I don't think the SPF '?' qualifier approach works because as Richard
>Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
>Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
>
>
On Sat 28/Oct/2023 16:51:27 +0200 Scott Kitterman wrote:
On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely wrote:
You're the only one strongly opposing the idea, AFAICS, and I still don't know
why.
As to why, I don't think there's a valid use case and the proponents for this
haven't r
The intended purpose of using it in the referenced scenario is to avoid the
negative connotation of ~ or - on their shared infrastructure mechanism(s)
in SPF evaluation, while also producing a non-pass for SPF to DMARC.
Many receivers use the failure SPF results as additional signals to
spam/junk
On Sat 28/Oct/2023 17:28:50 +0200 Scott Kitterman wrote:
We need to add a subsection in Security Consideration, discussing an
example of an include mechanism with a neutral qualifier and its effect on
DMARC outcome; that is, how that avoids spurious authentications.
I disagree. It's already
On Sun 29/Oct/2023 07:39:09 +0100 Wei Chuang wrote:
I don't think the SPF '?' qualifier approach works because as Richard
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
A "neutral" result MUST be t
I don't think the SPF '?' qualifier approach works because as Richard
Clayton said earlier of RFC7208 "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1" section 8.2 which says:
A "neutral" result MUST be treated exactly like the "none" result;
the distincti
On Saturday, October 28, 2023 4:03:30 PM EDT Emanuel Schorsch wrote:
> > As to why, I don't think there's a valid use case and the proponents for
> > this haven't really thought it through. As an example, someone (I don't
> > recall who) cited the issue of domain owners that publish SPF, but can't
For the shared provider SPF upgrade example, I think Scott's previously
mentioned method of using SPF '?' qualifier on the relevant shared
mechanism mitigates the upgrade problem, and ensures only DKIM can provide
passing authentication.
Thinking back earlier this year to the well-publicized SPF u
>
> As to why, I don't think there's a valid use case and the proponents for
> this haven't really thought it through. As an example, someone (I don't
> recall who) cited the issue of domain owners that publish SPF, but can't be
> bothered to set up DKIM. The implication is that this minimum effo
Fwiiw, Lurker opinion:
I ideally vote to make DMARCBis Experimental Status and begin to explore the
“required” integration between envelope (5321 only) protocols and payload
(5322) protocols. Specifically, work on a “proper” DKIM+SPF Policy Modeling
with 3rd party signature support.
But reali
On Sat, Oct 28, 2023 at 8:28 AM Richard Clayton
wrote:
> Paying attention to the (sometimes inferred) age of a signature is also
> important for reducing the opportunity for replay, viz: it would be a
> Good Thing for senders to set appropriately short expire times.
>
Why does it have to be infe
On Saturday, October 28, 2023 11:26:40 AM EDT Richard Clayton wrote:
> In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
> writes
>
> >What's your plan for when easily getting a DMARC pass due to bad SPF
> >records doesn't work anymore, so the bad guys focus more on DKIM replay?
>
> At
On Saturday, October 28, 2023 10:51:27 AM EDT Scott Kitterman wrote:
> >Even if we don't add the feature, we should address the vulnerability.
Currently there is only a bullet in Section 4.8, Organizational Domain
Discovery, saying:
> > * The domain found in the RFC5321.MailFrom header if there i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman
writes
>What's your plan for when easily getting a DMARC pass due to bad SPF records
>doesn't work anymore, so the bad guys focus more on DKIM replay?
At $DAYJOB$, DKIM replay is simply not
On Saturday, October 28, 2023 10:49:46 AM EDT Richard Clayton wrote:
> In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
> Vesely writes
>
> >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
> >> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely
wrote:
> >>>If we
On October 28, 2023 12:01:05 PM UTC, Alessandro Vesely wrote:
>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
>>> On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
If there isn't a consensus to do a DKIM-on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro
Vesely writes
>On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
>> On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
>>>If we add the feature, we should in any
On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote:
On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
If there isn't a consensus to do a DKIM-only feature, which seems to be the
case, I agree, wrap up the few minor editoria
On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote:
>On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
>> It appears that Scott Kitterman said:
That is unfortunately true, but if we could decouple the DMARC from SPF,
then at least we could fix the situation at some poin
On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote:
It appears that Scott Kitterman said:
That is unfortunately true, but if we could decouple the DMARC from
SPF, then at least we could fix the situation at some point...
I propose that we not repeat this discussion and instead, try to focus
I concur with what Doug mentioned. As someone on the receiving end of bad
press due to an exploit of what I perceive to be weaknesses in the DMARC
standards particularly around depending on SPF [1], and then had to drop
everything to mitigate, I would suggest taking this opportunity to
strengthen
On Thu, Oct 26, 2023 at 8:25 PM Scott Kitterman
wrote:
>
>
>
> I propose that we not repeat this discussion and instead, try to focus on
> finishing.
>
> Scott K
>
Agreed. +1
Michael Hammer
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/
It appears that Scott Kitterman said:
>>That is unfortunately true, but if we could decouple the DMARC from
>>SPF, then at least we could fix the situation at some point...
>
>I propose that we not repeat this discussion and instead, try to focus on
>finishing.
If there isn't a consensus to do
Like Ale, I thought the group had agreed to implement an auth=DKIM-only
option of some type.
I understood the motivation to be false pass created by malicious
forwarding through a legitimate hosting platform. Therefore SPF precision
is an unrelated issue.
Doug
On Thu, Oct 26, 2023, 5:46 PM Ter
On October 26, 2023 9:46:04 PM UTC, Tero Kivinen wrote:
>John Levine writes:
>> It appears that Scott Kitterman said:
>> >>* Is there consensus on moving ahead with the idea of a way to indicate
>> >>which authentication method(s) the Domain Owner wants Receivers to use? If
>> >>so, it doesn
John Levine writes:
> It appears that Scott Kitterman said:
> >>* Is there consensus on moving ahead with the idea of a way to indicate
> >>which authentication method(s) the Domain Owner wants Receivers to use? If
> >>so, it doesn't seem to be in the document yet.
> >
> >I haven't seen any vali
On Wed 25/Oct/2023 16:01:01 +0200 Scott Kitterman wrote:
On October 25, 2023 1:37:55 PM UTC, John Levine wrote:
It appears that Scott Kitterman said:
I haven't seen any valid case for it yet. It adds complexity to little or no benefit.
[...]
There's the counterargument "so don't publis
On Wed, Oct 25, 2023 at 9:33 AM Richard Clayton
wrote:
> >The operator is making the decision to publish or enforce, not the
> >user.
>
> Looking at $DAYJOB$ logs for this week I see a shade under 300 people
> who are participating in IETF working groups using p=reject addresses.
>
> I be
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Murray S. Kucherawy
writes
>Do you really want to be pushing that information and decision
>burden onto users? How many of them will understand versus
>ignoring it and just blundering ahead?
I think that depends how clear
On Wed, Oct 25, 2023 at 8:17 AM Richard Clayton
wrote:
> So might I suggest a wording that captures what will actually happen in
> the real world
>
> Domains that choose to publish p=reject SHOULD inform the people
> using those domains of the issues that may arise if theu post to
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Brotman, Alex writes
>+1 SHOULD NOT
If there is not going to be a consensus for just a discussion of the
issue (which I would prefer) then my view, obviously is that SHOULD NOT
is to be preferred to MUST NOT
The relevant bit of Barry's
On Wednesday, October 25, 2023 11:01:27 AM EDT Richard Clayton wrote:
> In message , Scott
> Kitterman writes
>
> >>> My reading of the discussion is:
> >>>
> >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
>
> sadly so, it would have been the right thing to do
>
>
On Wednesday, October 25, 2023 10:46:09 AM EDT Emanuel Schorsch wrote:
> > >There's the counterargument "so don't publish SPF" but it's on so many
> >
> > checklists
> >
> > >that even though that would be a fine idea, it's not practical.
> >
> > Diving into the SPF angle, if someone has a 'legi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Scott
Kitterman writes
>>> My reading of the discussion is:
>>>
>>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC.
sadly so, it would have been the right thing to do
>>> 2. We did not have rough consensus to
>
> >There's the counterargument "so don't publish SPF" but it's on so many
> checklists
> >that even though that would be a fine idea, it's not practical.
>
> Diving into the SPF angle, if someone has a 'legitimate' mail source that
> also sends spoofed mail for them, they can prefix the relevant
On October 25, 2023 1:37:55 PM UTC, John Levine wrote:
>It appears that Scott Kitterman said:
>>>* Is there consensus on moving ahead with the idea of a way to indicate
>>>which authentication method(s) the Domain Owner wants Receivers to use? If
>>>so, it doesn't seem to be in the document
It appears that Scott Kitterman said:
>>* Is there consensus on moving ahead with the idea of a way to indicate
>>which authentication method(s) the Domain Owner wants Receivers to use? If
>>so, it doesn't seem to be in the document yet.
>
>I haven't seen any valid case for it yet. It adds comp
On Wed, Oct 25, 2023 at 8:56 AM Scott Kitterman
wrote:
>
>
> On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely
> wrote:
> >On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
> * Is there consensus on moving ahead with the idea of a way to
> indicate which authentication method(s) the
On October 25, 2023 11:56:25 AM UTC, Alessandro Vesely wrote:
>On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use?
If so, it doesn't
On Wed 25/Oct/2023 13:12:32 +0200 Barry Leiba wrote:
* Is there consensus on moving ahead with the idea of a way to indicate
which authentication method(s) the Domain Owner wants Receivers to use? If
so, it doesn't seem to be in the document yet.
My recall is that we want to limit DMARC evalu
On Wed, Oct 25, 2023 at 7:12 AM Barry Leiba wrote:
> > > * Is there consensus on moving ahead with the idea of a way to indicate
> > > which authentication method(s) the Domain Owner wants Receivers to
> use? If
> > > so, it doesn't seem to be in the document yet.
> >
> > My recall is that we wa
> > * Is there consensus on moving ahead with the idea of a way to indicate
> > which authentication method(s) the Domain Owner wants Receivers to use? If
> > so, it doesn't seem to be in the document yet.
>
> My recall is that we want to limit DMARC evaluation to DKIM only, for the edge
> cases o
On Wed 25/Oct/2023 05:38:01 +0200 Murray S. Kucherawy wrote:
On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba wrote:
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
A few questions, but they don't demand in-person time if we want to
On Tue 24/Oct/2023 20:15:22 +0200 Barry Leiba wrote:
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
IMHO this one.
Best
Ale
--
___
dmarc mailing list
dmarc@ietf.org
https://www.i
On Tue 24/Oct/2023 15:20:02 +0200 Baptiste Carvello wrote:
Le 23/10/2023 à 19:59, Alessandro Vesely a écrit :
My opinion is that Barry's text is good as is. As far as delimiting a SHOULD
NOT with another SHOULD is legit, this sentence sounds clear to me:
It is therefore critical that do
On October 25, 2023 3:38:01 AM UTC, "Murray S. Kucherawy"
wrote:
>On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba
>wrote:
>
>> Now that we have a consensus call on the main issue that has remained open:
>>
>> 1. Do we need to retain our session at IETF 118 and discuss this (or
>> something else)
On Tue, Oct 24, 2023 at 11:15 AM Barry Leiba
wrote:
> Now that we have a consensus call on the main issue that has remained open:
>
> 1. Do we need to retain our session at IETF 118 and discuss this (or
> something else) further?
>
> ...or...
>
> 2. Do we have what we need to finish up the DMARCb
On 10/24/2023 2:15 PM, Barry Leiba wrote:
Now that we have a consensus call on the main issue that has remained open:
1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?
...or...
2. Do we have what we need to finish up the DMARCbis document, and
should
+1 SHOULD NOT
--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast
From: dmarc On Behalf Of Mark Alley
Sent: Tuesday, October 24, 2023 1:26 PM
To: Matt V
Cc: dmarc-cha...@ietf.org; Francesca Palombini
; IETF DMARC WG
; art-...@ietf.org
Subject: Re: [dmarc-ietf] Dmarcbis
Now that we have a consensus call on the main issue that has remained open:
1. Do we need to retain our session at IETF 118 and discuss this (or
something else) further?
...or...
2. Do we have what we need to finish up the DMARCbis document, and
should the chairs cancel the session at 118?
Oh,
+1 for SHOULD NOT.
On Tue, Oct 24, 2023, 12:14 PM Matt V wrote:
> I also agree that "SHOULD NOT" would be my vote as the preferred language
> going forward.
>
> ~
> Matt
>
> On Tue, Oct 24, 2023 at 12:41 PM Dotzero wrote:
>
>> I'd like to first thank Francesca for taking the time to review wher
[trimming redundant Ccs]
On Tue, Oct 24, 2023 at 9:41 AM Dotzero wrote:
> I'd like to first thank Francesca for taking the time to review where the
> working group is as far as consensus.
>
+1, that was a lot to sift through.
The short version of the non-normative language should be in the doc
I also agree that "SHOULD NOT" would be my vote as the preferred language
going forward.
~
Matt
On Tue, Oct 24, 2023 at 12:41 PM Dotzero wrote:
> I'd like to first thank Francesca for taking the time to review where the
> working group is as far as consensus.
>
> I fall into the "SHOULD NOT" co
I'd like to first thank Francesca for taking the time to review where the
working group is as far as consensus.
I fall into the "SHOULD NOT" consensus group with additional non-normative
language.
The short version of the non-normative language should be in the document
itself but I believe the i
On Tue, Oct 24, 2023 at 8:57 AM Scott Kitterman
wrote:
> My understanding of IETF consensus is that technical objections have been
> addressed. I think this is critical to the difference between IETF
> consensus and voting. It's not just 'most people think X'. I don't think
> that the technica
is definitely the direction I
support.
- Trent
From: dmarc on behalf of Francesca Palombini
Date: Monday, October 23, 2023 at 2:06 AM
To: "dmarc@ietf.org"
Cc: "dmarc-cha...@ietf.org" , "art-...@ietf.org"
Subject: [dmarc-ietf] Dmarcbis way forward
I have been
On October 24, 2023 3:38:54 PM UTC, "Murray S. Kucherawy"
wrote:
>On Mon, Oct 23, 2023 at 9:07 PM Scott Kitterman
>wrote:
>
>> I don't think this is consistent with the IETF's mandate to provide
>> documents
>> which promote interoperability. I do not, however, plan to file an appeal
>> about
On Mon, Oct 23, 2023 at 9:07 PM Scott Kitterman
wrote:
> I don't think this is consistent with the IETF's mandate to provide
> documents
> which promote interoperability. I do not, however, plan to file an appeal
> about it.
>
Two things to say about that:
(1) This is Francesca's determination
Hi,
Le 23/10/2023 à 19:59, Alessandro Vesely a écrit :
My opinion is that Barry's text is good as is. As far as delimiting a
SHOULD NOT with another SHOULD is legit, this sentence sounds clear to me:
It is therefore critical that domains that host users who might
post messages to
I think for interoperability reasons a MUST NOT is the correct decision:
Domains that choose to use p=reject and then allow their users to post to
mailing lists damage interoperability for uninvolved third parties. However,
for rough consensus purposes I would support Barry’s SHOULD NOT language
Thanks for that, Scott. For what it’s worth, i have sympathy for your
position, both as a participant and as chair. I do, though think that what
we have now or something like it is the only way we will get rough
consensus, that the other option is not to publish DMARC as a standard, and
that giv
On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote:
> I have been asked by Murray to assist with a consensus evaluation on the
> discussion that has been going on for a while about the dmarcbis document
> and how to move forward.
>
> I have made an attempt to evaluate consensus o
My opinion is that Barry's text is good as is. As far as delimiting a SHOULD
NOT with another SHOULD is legit, this sentence sounds clear to me:
It is therefore critical that domains that host users who might
post messages to mailing lists SHOULD NOT publish p=reject. Domains
tha
I have been asked by Murray to assist with a consensus evaluation on the
discussion that has been going on for a while about the dmarcbis document and
how to move forward.
I have made an attempt to evaluate consensus on the topic, trying to look at it
from a complete outsider’s point of view an
84 matches
Mail list logo
