Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread Murray S. Kucherawy
On Fri, Jul 7, 2023 at 6:14 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Malicious impersonation creates a need for authentication. If the list > makes changes that disable the originator's authentication, then it is the > list's problem to find a way to convince the

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread Murray S. Kucherawy
On Fri, Jul 7, 2023 at 6:35 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Consequently, the problem remains: How does an evaluator distinguish > between a legitimate list and a malicious attack? > If we had a reliable answer to that, this would've been over ages ago.

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread Tero Kivinen
Scott Kitterman writes: > You can equally argue that these receivers are merely following the > policy advice provided by the sending domain (it has reject right in > the name) and this problem is entirely generated by sender's > inappropriate use of p=reject. True, thats why the proposed text

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread Scott Kitterman
On July 8, 2023 6:16:46 PM UTC, Tero Kivinen wrote: >Brotman, Alex writes: >> I suspect the portion that instructs receivers to not act solely on >> p=reject may be ignored by a fair set of receivers. I'm not >> necessarily opposed to the language below, just that it seems odd to >> create

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread Tero Kivinen
Brotman, Alex writes: > I suspect the portion that instructs receivers to not act solely on > p=reject may be ignored by a fair set of receivers. I'm not > necessarily opposed to the language below, just that it seems odd to > create language that we know will be ignored. If receivers ignore

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread John Levine
It appears that Richard Clayton said: >They then moved on to just using random identities from the same domain >as the recipient. This led a great many Yahoo users to believe that a >great many other Yahoo users had been compromised, leading to a >significant loss of faith in the integrity of

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread Hector Santos
*Note: The following is a general rule of thumb for me.* From my functional specification protocol language coding standpoint: MUST --> NO OPTION. Technically enabled with no switch to disable. SHOULD -> OPTIONAL, Default is ON, enabled MAY --> OPTIONAL, Default is ON or OFF depending on

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread Richard Clayton
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Murray S. Kucherawy writes >Some of my IETF mentors (ahem) taught me some stuff about the use >of SHOULD [NOT] that have stuck with me, and I'm going to pressure >test this against that advice.  Let's see how this goes. 

Re: [dmarc-ietf] Another p=reject text proposal

2023-07-08 Thread Alessandro Vesely
On Sat 08/Jul/2023 02:44:19 +0200 Murray S. Kucherawy wrote: On Thu, Jul 6, 2023 at 7:55 AM Barry Leiba wrote: 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