Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

I have been “militantly” against Authorship destruction. But fast forward to today, I am willing to support it IFF it can be officially sanctioned by the IETF using a well-defined Rewrite protocol for List Systems. Overall, I believe if the middle ware performs a rewrite due to an author’s

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

Hello esteemed colleagues, I'm sure we're on the cusp of a future where only "Authenticated Mail of the Fifth Kind" will reign supreme—much like the exclusive club of Submission Protocol requiring ESMTP AUTH on the ultra-special port 587. And surely, the ever-trusted port 25 will forever

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

I am not claiming any particular knowledge of the universe of all implementations. All I know is that if my user's want a mailing list exempted from DMARC enforcement, all they have to do is ask, and that is the way it should be most everywhere. If the mailing list problem was unique to AOL

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sun, Sep 17, 2023 at 2:47 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > We have established that the normative implementation of DMARC is > (unfortunately) a fully-automated solution which implements RFC 7489 > exactly and nothing more. > Sure, but why would you do that,

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

We have established that the normative implementation of DMARC is (unfortunately) a fully-automated solution which implements RFC 7489 exactly and nothing more. These implementations block unconditionally on Fail with Reject, and have minimal effect on disposition otherwise. With any level of

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sun, Sep 17, 2023 at 11:04 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > You misunderstsnd my position. I don't expect a world where perfect > information is dropped in my lap without any effort on my part. Not now, > not ever. > > I have determined, by measurement, that

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

You misunderstsnd my position. I don't expect a world where perfect information is dropped in my lap without any effort on my part. Not now, not ever. I have determined, by measurement, that unauthenticated mail is a much smaller percentage of all mail than one might expect. This makes

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

I believe, with you, that there's likely to be a time when unauthenticated mail simply will not be delivered by most receiving domains. I similarly believe (as the owner of a Tesla) that there will be a time when cars will be self-driving in the vast majority, and that that will make the roads

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

Yes, I suspected awhile back that I was the only one in the world implementing mandatory authentication. This group has confirmed it. But I hold out hope thst others will see the opportunity that it provides. Perhaps someone will read my Best Practices draft and sponsor it as an individual

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

> Content filtering creates a need for whitelisting > Any domain may require whitelisting, regardless of sender policy. > Whitelisting is only safe if it is coupled with an authentication mechanism > which prevents impersonation. > Therefore, sender authentication, by a combination of local

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

Glad you are seeing DMARC benefits. I suggest a full set of management statistics should be based on 100 of messages, and include: % blocked by reputation % blocked by DMARC Fail+Reject % Authenticated by DMARC % Authenticated by local policy % Not authenticated "Not Authenticated" is an

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

No. Realistically, this is the last document likely to come out of this group on this subject. So I am no sure to publish it unless it fixes the coverage problem. To state the coverage problem another way: - Content filtering creates a need for whitelisting - Any domain may require

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Thu 14/Sep/2023 16:39:49 +0200 Murray S. Kucherawy wrote: On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster wrote: Our assumed reference model is a fully automated, by-the-spec implementation of RFC 7489. In particular, this means that: - when p=none, unauthenticated messages are never

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Thursday, September 14, 2023 5:27:08 PM EDT Wei Chuang wrote: > On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman > > wrote: > > On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote: > > > We had an opportunity to further review the DMARCbis changes more > > > broadly > > > within

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman wrote: > On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote: > > We had an opportunity to further review the DMARCbis changes more broadly > > within Gmail. While we don't see any blockers in the language in > DMARCbis > > version 28

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

> On Sep 14, 2023, at 10:39 AM, Murray S. Kucherawy wrote: > > On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster > > wrote: >> >> The coverage problem is aggravated if we assume rational attackers. With a >> plethora of domains available for

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

> On Sep 14, 2023, at 7:36 AM, Dotzero wrote: > > On Wed, Sep 13, 2023 at 9:21 PM Hector Santos > wrote: >> >>> On Sep 13, 2023, at 8:51 PM, Dotzero >> > wrote: >>> >>> DMARC does one thing and one thing only. It mitigates against direct

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Let's analyze the problem Jim raises, using it to answer Hector's question > about where responsibility lies. > > Our assumed reference model is a fully automated, by-the-spec > implementation of RFC

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Wed, Sep 13, 2023 at 9:01 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Let's analyze the problem Jim raises, using it to answer Hector's question > about where responsibility lies. > > Our assumed reference model is a fully automated, by-the-spec > implementation of RFC

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Wed, Sep 13, 2023 at 9:21 PM Hector Santos wrote: > > All the best, > Hector Santos > > > > On Sep 13, 2023, at 8:51 PM, Dotzero wrote: > > > > On Wed, Sep 13, 2023 at 5:28 PM Hector Santos wrote: > >> On Sep 11, 2023, at 9:24 AM, Dotzero chastised >> Douglas Foster >> >> Absolutely

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sat 09/Sep/2023 20:16:04 +0200 Douglas Foster wrote: Thus, if I get N messages from example.com , and the "pct" value is X, then the DMARC test is applied only to X% of that N; the simplest way to do this per-message would be to pick a random number between 0 and 1 and

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Douglas Foster writes >The coverage problem is aggravated if we assume rational attackers. >  With a plethora of domains available for impersonation, attackers >are least likely to use domains that are protected with

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

All the best, Hector Santos > On Sep 13, 2023, at 8:51 PM, Dotzero wrote: > > > > On Wed, Sep 13, 2023 at 5:28 PM Hector Santos > wrote: >>> On Sep 11, 2023, at 9:24 AM, Dotzero >> > chastised Douglas Foster >>> >>> Absolutely incorrect.

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

Let's analyze the problem Jim raises, using it to answer Hector's question about where responsibility lies. Our assumed reference model is a fully automated, by-the-spec implementation of RFC 7489. In particular, this means that: - when p=none, unauthenticated messages are never obstructed, for

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Wed, Sep 13, 2023 at 5:28 PM Hector Santos wrote: > On Sep 11, 2023, at 9:24 AM, Dotzero chastised > Douglas Foster > > Absolutely incorrect. DMARC is a deterministic pass|fail approach based on > validation through DKIM or SPF pass (or if both pass). It says nothing > about the

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

> On Sep 11, 2023, at 9:24 AM, Dotzero chastised Douglas > Foster > > Absolutely incorrect. DMARC is a deterministic pass|fail approach based on > validation through DKIM or SPF pass (or if both pass). It says nothing about > the acceptability/goodness/badness of a source. So why are we

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On 10 Sep 2023, at 18:14, Dotzero wrote: >> I agree that the SHOULD language is not very useful because it’s likely to >> be interpreted as only advice. Instead, I think we need a stronger >> statement about the consequences of this policy. For example, “Domains >> publishing p=reject MUST NOT

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Mon, Sep 11, 2023 at 6:36 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > We are still trying to fix an evaluator problem by changing domain > owner behavior. No harm in giving domain owners the warning, but changing > evaluator behavior would be much better. Presumably,

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

We are still trying to fix an evaluator problem by changing domain owner behavior. No harm in giving domain owners the warning, but changing evaluator behavior would be much better. Presumably, the evaluator behavior that we have today is the result of RFC 7489 wording, so we may be able to

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sun, Sep 10, 2023 at 8:46 PM Jim Fenton wrote: > On 7 Sep 2023, at 9:28, Wei Chuang wrote: > > Many enterprises already have "p=reject" policies. Presumably those > domains were subject to some sort of spoofing which is why they went to > such a strict policy. > > This is not necessarily the

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

How I define a "Source": To the domain owner, it is all of the environments that need to be touched, as part of a DMARC implementation project, to ensure that they produce DKIM PASS with SPF PASS or DKIM PASS with SPF NONE. It includes corporate employee email, ESPs, CRMs, Web Sites, Shadow IT,

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On 7 Sep 2023, at 9:28, Wei Chuang wrote: Many enterprises already have "p=reject" policies. Presumably those domains were subject to some sort of spoofing which is why they went to such a strict policy. This is not necessarily the case. For example, DHS has

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

One thing I forgot to mention: On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang wrote: > Our suggestion is that there is not a lot of value in including this > language in the bis document if the likely outcome is that it will be > ignored, and rather more effort should be placed with a technical

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote: > We had an opportunity to further review the DMARCbis changes more broadly > within Gmail. While we don't see any blockers in the language in DMARCbis > version 28 >

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Sat, Sep 9, 2023 at 11:16 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I understand the phased roll-out goal, but phased rollout and percentages > are not applicable to the evaluator's task. > > I start with an assumption that message sources reflect the character of >

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

A not-yet mentioned characteristic of impersonating messages is that: "Impersonation requires that a message originate from an attacker-controlled server." - Mailbox providers require user-level authentication. - Hosting services require domain administrator authentication and use

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

I understand the phased roll-out goal, but phased rollout and percentages are not applicable to the evaluator's task. I start with an assumption that message sources reflect the character of the individual or organization that controls the source. Malicious traffic comes from malicious people.

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

I'm not looking to change the WG's mind on this matter, but: On Sat, Sep 9, 2023 at 3:54 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > There are many percentages mixed up together in this issue: > >- The percentage of domain message sources which provide proper >

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

I objected strongly to the RFC 7489 language which provides disposition instructions based on the PCT clause, and still do. A brief review: There are many percentages mixed up together in this issue: - The percentage of domain message sources which provide proper authentication at

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Thu 07/Sep/2023 18:28:59 +0200 Wei Chuang wrote: Regarding the languages in section 8.6 "It is therefore critical that domains that host users who might post messages to mailing lists SHOULD NOT publish p=reject.  Domains that choose to publish p=reject SHOULD implement policies that

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang wrote: > Regarding the languages in section 8.6 "It is therefore critical that > domains that host users who might post messages to mailing lists SHOULD NOT > publish p=reject. Domains that choose to publish p=reject SHOULD implement > policies that

[dmarc-ietf] Some Gmail comments on DMARCbis version 28

We had an opportunity to further review the DMARCbis changes more broadly within Gmail. While we don't see any blockers in the language in DMARCbis version 28 and can live with what is there, we wanted to briefly raise some