[dmarc-ietf] Re: New attack leveraging DMARC None

On Tue, May 7, 2024 at 9:27 PM Scott Kitterman wrote: > On Tuesday, May 7, 2024 9:09:02 PM EDT Mark Alley wrote: > > On 5/7/2024 7:00 PM, Dotzero wrote: > > > https://www.ic3.gov/Media/News/2024/240502.pdf > > > > > > This was released this past week

[dmarc-ietf] New attack leveraging DMARC None

https://www.ic3.gov/Media/News/2024/240502.pdf This was released this past week by the FBI. Although we are in last call, I have to wonder if a) the attack itself, and/or b) the government recommendations regarding policy might impact DMARCbis in any manner. I've only just started thinking about

Re: [dmarc-ietf] Overall last-call comments on DMARC

On Thu, Apr 4, 2024 at 1:42 PM Murray S. Kucherawy wrote: > On Thu, Apr 4, 2024 at 10:21 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Murray, I was hoping your proposal to advance ARC was serious. >> > > If people think (and have evidence that) ARC is ready, then why

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Wed, Apr 3, 2024 at 5:21 AM Laura Atkins wrote: > > On 1 Apr 2024, at 13:18, Brotman, Alex 40comcast@dmarc.ietf.org> wrote: > > One item left out of Seth’s text is that due to MBPs who act in this > fashion, these SPF evaluation failures will (understandably) not show up in > DMARC

Re: [dmarc-ietf] SPF follies, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On Mon, Apr 1, 2024 at 8:18 AM Brotman, Alex wrote: > One item left out of Seth’s text is that due to MBPs who act in this > fashion, these SPF evaluation failures will (understandably) not show up in > DMARC reports, and the domain owner may not have visibility for these > failures. However,

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Mon, Mar 18, 2024 at 2:38 AM John R Levine wrote: > On Sun, 17 Mar 2024, Dotzero wrote: > >> Whenever mail is sent, there is a risk that an overly permissive source > >> may send mail which will receive a DMARC pass result that was not, in > >> fact,

Re: [dmarc-ietf] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On Sun, Mar 17, 2024 at 9:36 PM John Levine wrote: > Tightened up a little, reworded in view of the fact that your own > mail provider (M*r*s*ft) may let people spoof you through shared IP ranges. > > > >11.X External Mail Sender Cross-Domain Forgery > > Add this to 11.1 Authentication Methods

Re: [dmarc-ietf] Fwd: The sad state of SPF: research just presented at NDSS

Neil, SPF essentially deals with hosts and IP address ranges. Your suggested solution does not address the main problem(s) raised in the research. One approach that potentially addresses the SPF problem of shared hosting would be for ESPs to use IPv6 address space for sending. Each customer can

Re: [dmarc-ietf] DMARCbis WGLC Significant(ish) Issue - Section 7.6

I agree that the rough consensus landed on "SHOULD NOT" even though there were some who felt "MUST NOT" was "purer". I was one of those who (reluctantly) supported "SHOULD NOT". Todd is simply trying to get consistency within the document to match the outcome that there was rough agreement on.

Re: [dmarc-ietf] DMARC with multi-valued RFC5322.From

On Fri, Jan 19, 2024 at 10:20 AM Todd Herr wrote: > On Thu, Jan 18, 2024 at 9:28 PM Hector Santos 40isdg@dmarc.ietf.org> wrote: > >> Hi, >> >> As a long time implementer and integrator of IETF protocols, my mail >> engineering view …. >> >> The thing is RFC 822, 2822 and 5322 allows for a

Re: [dmarc-ietf] DMARCbis rev 29 (was: Re: DMARCbis way forward: Do we need our session at IETF 118)

On Wed, Oct 25, 2023 at 10:04 AM Todd Herr wrote: > On Tue, Oct 24, 2023 at 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? >>

Re: [dmarc-ietf] DMARC marketing on NPR

On Thu, Nov 23, 2023 at 10:19 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > The gap between what is being attempted and what is needed is a huge > personal disappointment. > > The DMARC goal should be to block malicious impersonation without blocking > wanted messages, where

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Sat, Nov 11, 2023 at 3:45 PM Neil Anuskiewicz wrote: > Michael, I’m realizing I started this discussion thinking we were talking > about failure reports and a bit about aggregate reports when I think we > might have pivoted to Feedback Loops and I was so focused on reports, I > failed to

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Sat, Nov 11, 2023 at 1:47 PM Neil Anuskiewicz wrote: > > The fact that you aren't seeing failure reports doesn't mean they aren't > being generated. My experience has been that they are being made available > through 3rd parties where there is a contractual relationship. > > > > Michael

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Sat, Nov 11, 2023 at 9:17 AM Neil Anuskiewicz wrote: > > > On Oct 25, 2023, at 3:57 AM, Olivier Hureau < > olivier.hur...@univ-grenoble-alpes.fr> wrote: > >  > On 25/10/2023 08:10, Steven M Jones wrote: > > It's not so much changing the handling as changing the reporting. > > * The policy to

Re: [dmarc-ietf] DMARC session at IETF 118

On Sat, Oct 28, 2023 at 1:38 PM Barry Leiba wrote: > I'm starting this in a separate thread that I want to keep for ONLY > the following question: > > Do we want to use the session we have scheduled at IETF 118 to talk > about the issue that clearly is still in discussion about adding a tag > to

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

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

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

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)

Re: [dmarc-ietf] DMARCbis way forward: Do we need our session at IETF 118

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

[dmarc-ietf] Additional Document, was Re: Dmarcbis way forward

I changed the subject line to differentiate the discussion regarding an additional document from the consensus thread. On Tue, Oct 24, 2023 at 1:15 PM Murray S. Kucherawy wrote: > [trimming redundant Ccs] > > On Tue, Oct 24, 2023 at 9:41 AM Dotzero wrote: > >> I'd like to fir

Re: [dmarc-ietf] Dmarcbis way forward

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

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Fri, Oct 20, 2023 at 11:14 AM OLIVIER HUREAU < olivier.hur...@univ-grenoble-alpes.fr> wrote: > Hi, > > > The correct solution is that the person responsible for creating the > problem record should fix the problem record they created. > > How does downgrading p=reject to p=none help the person

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Fri, Oct 20, 2023 at 10:39 AM OLIVIER HUREAU < olivier.hur...@univ-grenoble-alpes.fr> wrote: > Hi, > > > Why would we even consider going down this path? > I am considering this pass in order to fix any miscomprehension in the RFC. > > > Why do you only consider "fixing" quarantine with a

Re: [dmarc-ietf] DMARC policy discovery and invalid tag exception.

On Fri, Oct 20, 2023 at 9:51 AM OLIVIER HUREAU < olivier.hur...@univ-grenoble-alpes.fr> wrote: > Hi, > > Assuming that the comma is an Oxford comma, I do interpret the sentence > with the following boolean: > > ( 'retrieved policy record does not contain a valid "p" tag' || contains > an "sp" or

Re: [dmarc-ietf] Getting the word out and educating

On Mon, Oct 16, 2023 at 7:14 PM Neil Anuskiewicz wrote: > Outside of the official business of the WG, is there a mechanism for > educating people about DMARCbis. Why is it important? What problems does it > solve? What’s different? I think some of it might even surprise some > people: You mean

Re: [dmarc-ietf] Policy Enforcement Considerations

On Tue, Sep 19, 2023 at 8:20 AM Scott Kitterman wrote: > > > On September 19, 2023 8:50:02 AM UTC, Alessandro Vesely > wrote: > >Hi all, > > > >the second sentence of the second paragraph of Section 5.8: > > > >OLD > > In particular, because of the considerations discussed > >

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 ch

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

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

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] Reflections on IETF 117 Conference and DMARC Meeting

On Thu, Aug 3, 2023 at 1:39 PM Hector Santos wrote: > On 8/3/2023 2:07 AM, Murray S. Kucherawy wrote: > > On Mon, Jul 31, 2023 at 9:47 AM Hector Santos > > > > wrote: > > > >- I mentioned using the deprecated SUBMITTER/PRA > > (RFC4405/RFC4407) > >

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

t;we" for "I". You have also wandered from writing a protocol to telling people how they (actually YOUR preference) should implement their operational choices for local policy. Trying to dictate local policy choices is a losing proposition. Trying to dictate to vendors YOUR policy c

Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?

On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Perhaps you can clarify what you think DMARC is. > > Apparently a significant number of evaluators think that "DMARC Fail with > p=reject always means unwanted mail". Or to use Michael Hammer's >

Re: [dmarc-ietf] Protocols All The Way Down (long - sorry)

On Wed, Jul 12, 2023 at 6:47 AM Scott Kitterman wrote: > It's not news that there's a risk for SPF associated with shared IP > addresses. > That's why it's in RFC 7208 (11.4) and was in RFC 4408 similarly before. > +1 > > I understand your view and agree on the problem. I also sympathize

Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD?

On Fri, Jun 30, 2023 at 2:31 PM Murray S. Kucherawy wrote: > On Fri, Jun 30, 2023 at 11:22 AM Todd Herr 40valimail@dmarc.ietf.org> wrote: > >> Why is the mechanism called "Domain-based Message Authentication, >> Reporting, and Conformance" and not "Domain-based Message Authentication, >>

Re: [dmarc-ietf] easier DKIM, DMARC2 & SPF Dependency Removal

On Thu, Jun 22, 2023 at 8:59 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Right, but the messages often get sent anyway. So the evaluator who > blocks the message as malicious impersonation is blocking incorrectly > because the fail result is unreliable. If it only

Re: [dmarc-ietf] DMARC and Data Hygiene

On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman wrote: > I am starting a separate thread, because this isn't just about SPF. > > I think the criticism of the reliability of SPF data is valid, but I think > DKIM is similarly problematic. Once you get rid of SPF, you'll find you > haven't really

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Thu, Jun 8, 2023 at 4:35 PM Barry Leiba wrote: > > A sender using both SPF and DMARC will see a slight > > boost in validation rates due to increased resiliency when there are > > transient DNS failures and other problems. > > Do you mean "both SPF and DKIM", perhaps? > My bad. I responded

Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

On Thu, Jun 8, 2023 at 10:44 AM Barry Leiba wrote: > See, I don't look at it as "harmed". Rather, I think they're using "we > use SPF" as a *reason* not to use DKIM, and I think that *causes* harm. > That might be true but does not address whether or not SPF is/can be useful in the context of

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-10.txt

On Wed, Apr 26, 2023 at 8:58 AM Scott Kitterman wrote: > I'd like to see the 'SHOULD employ a secure transport mechanism' section > added back in. As I mentioned in another message, I think IETF policy > based on RFC 7258 supports it. Alternately, something in privacy > considerations might be

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-aggregate-reporting-09.txt

On Mon, Apr 24, 2023 at 10:18 PM John R. Levine wrote: > > I removed the small section that faced objections. > > > > I updated the ridtxt definition and discovered that mmark was making a > mess of those asterisks. When there are more than one/some on a single > line, it believes you would

Re: [dmarc-ietf] Two basic Issues to address to help complete DMARCbis

On Sun, Apr 23, 2023 at 1:20 PM Hector Santos wrote: > On 4/23/2023 6:10 AM, Alessandro Vesely wrote: > > > > Meanwhile, digressions about ATPS and similar schemes can help > > casting some light on future evolution. From: rewriting cannot be > > the final solution; it is a temporary hack.

Re: [dmarc-ietf] Definitely no Delegated authentication for Gmail

On Sat, Apr 22, 2023 at 2:04 PM Hector Santos wrote: > > On Apr 22, 2023, at 12:58 PM, John Levine wrote: > > It appears that Jesse Thompson said: > > -=-=-=-=-=- > > A DNS-based lookup, perhaps in the style of ATSP as this thread is > describing, to query for not just domain-level

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

On Thu, Apr 20, 2023 at 11:38 AM John Levine wrote: > It appears that Alessandro Vesely said: > >IMHO at least an appendix should say that if you can't do anything better > you > >have to rewrite From: with examples of legitimate display-phrase, > expanding a > >bit the first bullet in Section

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

On Mon, Apr 17, 2023 at 12:05 PM John Levine wrote: > It appears that Laura Atkins said: > >Is this another issue we should document and make recommendations about? > I was thinking along the line that transactional SaaS > >providers should fully support DMARC and should not allow companies

Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

On Mon, Apr 17, 2023 at 4:30 AM Laura Atkins wrote: > Reading through the various discussions about how to document the harm > DMARC causes for general purpose domains, I started thinking.One way that a > lot of major SaaS providers have chose to deal with DMARC is spoofing their > customer’s in

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

k, so I have no reason to > expect better elsewhere. > > Societies depend on trust. Impersonation in all it's forms undermines > trust. > > > Doug > > > > > On Fri, Apr 14, 2023, 9:17 PM Murray S. Kucherawy > wrote: > >> On Fri, Apr 14, 2023 at 12:37 PM Dotze

Re: [dmarc-ietf] Signaling MLMs

On Fri, Apr 14, 2023 at 5:55 PM Hector Santos wrote: > Yes, it is simple DeMorgan’s Theorem where you use short-circuiting logic. > > DMARC says that any FAIL calculated via SPF or DKIM is an overall DMARC > failure. In standard boolean logic is it an OR condition: > > IF SPF FAILS or DKIM

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Apr 13, 2023 at 9:52 PM Barry Leiba wrote: > > I don’t think folks are objecting to cautionary language. I think > > folks are objecting to a blanket MUST NOT. If we're going to qualify > > the MUST NOT with a bunch of language, that's a bit different. The > > original proposal was:

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri, Apr 14, 2023 at 4:25 PM John Levine wrote: > It appears that Dotzero said: > >While the you part of "we" may not see any advantages, quite a few > >financials, greeting card sites, retailers AND many receivers have seen > the > >advantages, includin

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Fri, Apr 14, 2023 at 2:00 PM Laura Atkins wrote: > > > On 14 Apr 2023, at 18:38, Alessandro Vesely wrote: > > On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote: > > On 12 Apr 2023, at 12:21, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > Any form of security creates

Re: [dmarc-ietf] Signaling forwarders, not just MLMs

On Thu, Apr 13, 2023 at 12:19 PM Barry Leiba wrote: > Maybe just add a sentence to the end of the second paragraph: > >The use of SPF alone, without DKIM, is strongly NOT RECOMMENDED. > > Barry > I think the opposite. Something along the lines of "Sending domains SHOULD implement both SPF

Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 9:41 AM John R Levine wrote: > On Tue, 11 Apr 2023, Neil Anuskiewicz wrote: > > If DMARC can protect domains from spoofing which I believe ends up > > costing over $14 billion per year. Forget about the $14 billion and > > think how this crime spree affects people’s view

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 1:57 PM Murray S. Kucherawy wrote: > On Wed, Apr 12, 2023 at 8:27 AM Brotman, Alex > wrote: > >> In the case of DNSSEC, my ISP is the intermediary utilizing DNSSEC, and >> the website signs records via DNSSEC. The website I want to go to breaks >> their DNSSEC. My ISP

Re: [dmarc-ietf] Signaling MLMs

On Wed, Apr 12, 2023 at 11:38 PM Murray S. Kucherawy wrote: > On Wed, Apr 12, 2023 at 12:45 PM Steven M Jones wrote: > >> This puts me in mind of Section 8.5, which calls out some potential >> impacts of blocking policies to "Mediators," which role doesn't otherwise >> appear very often in this

Re: [dmarc-ietf] DMARC is designed to break mail, Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 12, 2023 at 9:41 AM John R Levine wrote: > > When we say that mail systems that don't fit the DMARC threat profile > shouldn't publish DMARC policies, we have good reasons to say so, and > that's what our standards need to say if we're serious about > interoperating. > > R's, >

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Sat, Apr 8, 2023 at 5:10 PM Scott Kitterman wrote: > Possible. I didn't count. > > I didn't see any convergence towards an alternative. > The fact that there hasn't been convergence on an alternative doesn't mean there has been convergence on the proposed new txt. This also doesn't mean the

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Going back through the thread I find more people questioning/disagreeing with the proposed wording than agreeing with it. I don't see a rough consensus. Michael Hammer On Sat, Apr 8, 2023 at 4:17 PM Scott Kitterman wrote: > We've gone nearly a week without any further discussion on this

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Thu, Apr 6, 2023 at 9:19 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hallo, > > Le 06/04/2023 à 01:46, Dotzero a écrit : > > > > Not at all. The discussion (and specific post I was responding to) was > > about mailing lists but it also

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Wed, Apr 5, 2023 at 5:41 PM Jim Fenton wrote: > On 1 Apr 2023, at 8:25, Dotzero wrote: > > > Hmm, let's apply this to DMARC. > > > > " But it interoperates just fine once you make the effort." > > > > Nobody forces a Sender to publ

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

6:30 AM Scott Kitterman wrote: > > > On April 1, 2023 6:53:13 AM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > >On Fri, Mar 31, 2023 at 5:48 PM Dotzero wrote: > > > >> > >> > >> > >>> > >>> > >&g

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Sat, Apr 1, 2023 at 3:02 AM Barry Leiba wrote: > > If we use SHOULD NOT, as you suggest, there's an implication that there > might be a valid reason for > > non-transactional mail to use "p=reject". Are we okay with that? > > When do folks get to line up so they can plead the case for their

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Fri, Mar 31, 2023 at 8:00 AM Barry Leiba wrote: > > Compare that with the move to https everywhere. Having to get > certificates and > > encrypting and decrypting all stuff is certainly not an interoperability > > improvement. > > Say WHAT? There's no interoperability issue there. > >

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Sat, Apr 1, 2023 at 2:53 AM Murray S. Kucherawy wrote: > On Fri, Mar 31, 2023 at 5:48 PM Dotzero wrote: > >> >> >> >>> >>> >>> But when you deploy DMARC and force lists to change the way they work, >>> the experience is altered

Re: [dmarc-ietf] Example of Indirect Mail Flow Breakage with p=reject?

On Fri, Mar 31, 2023 at 3:05 PM Murray S. Kucherawy wrote: > On Thu, Mar 30, 2023 at 8:34 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> The world has changed. Insecure mailing lists did not matter in the >> days before email became a weapon. >> > > A comparison was

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

Douglas Foster wrote " My point was to only restate that "signed" is the only truth that the DMARC policy can assert." This is not true. If a sending domain provides a p=reject policy assertion in their DMARC record, that is truth. They are not saying that fail always means fraud. They are saying

Re: [dmarc-ietf] Proposed text for p=reject and indirect mail flows

On Tue, Mar 28, 2023 at 12:18 PM Scott Kitterman wrote: > > > I don't understand the connection between DMARC policies and open signup > domains? What makes them in any way special relative to DMARC? > > Scott K > I agree with Scott on this. I don't believe that "open signup" domains deserve

Re: [dmarc-ietf] ARC interop and abuse concerns

Let's not conflate "spaminess" with authentication (specifically DMARC and ARC) and forwarding. DMARC deals with direct domain abuse. ARC is an attempt to show an authenticated chain of handling outside of DMARC when DKIM and/or SPF is broken through forwarding. Consideration of "spaminess" is

Re: [dmarc-ietf] Version in aggregate report

I favor being explicit in the reporting. Michael Hammer On Thu, Mar 9, 2023 at 1:51 PM Trent Adams wrote: > > > Alex - > > > > I think that the difference comes down to an inference made by the report > analyst (and assuming enough data to make an informed guess) vs. the report > generator

Re: [dmarc-ietf] Treewalk causing changes

On Mon, Feb 27, 2023 at 12:27 AM Barry Leiba wrote: > I think the failure of this thinking is the idea that there's any > intent going on at cuny.edu, and we need to remind ourselves that it's > a *hierarchy*, and that that word means something specific. In a > hierarchy you expect to inherit

Re: [dmarc-ietf] [PROPOSAL]: Timing data in aggregate reports

On Sun, Feb 19, 2023 at 1:01 PM Scott Kitterman wrote: > Thanks for checking. In that case, I particularly think we should not be > spending time on proposals like this. We should focus on finishing the > work we are chartered to do. > > Scott K > +1 Focus. Michael Hammer

Re: [dmarc-ietf] Aggregate Reporting draft 7 - Server identity

On Sun, Jan 8, 2023 at 2:17 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > re: "These are not forensic reports" > The purpose of aggregate reports is to define WHERE a problem occurs, > while the purpose of a forensic report is to define WHY a problem occurs. > (e.g. "Why do

Re: [dmarc-ietf] Does Aggregate Reporting meet "Internet Scale" test?

On Thu, Dec 8, 2022 at 1:59 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > > 1) DMARC was a successful 2-company experiment, which was turned into a > widely implemented informational RFP. We are now writing the > standards-track version of that concept. We hope that

Re: [dmarc-ietf] Not Multiple From: mailboxes, was I-D Action: draft-ietf-dmarc-dmarcbis-24.txt

ecause you could consistently get a neutral. It drove them nuts for months before they admitted it was a problem with PRA. From != Author. There may be instances where it does but that is not because a standard specifies it to be so. Merely a happy coincidence. Michael Hammer > > > On Thu,

Re: [dmarc-ietf] Not Multiple From: mailboxes, was I-D Action: draft-ietf-dmarc-dmarcbis-24.txt

On Thu, Nov 24, 2022 at 2:22 PM Neil Anuskiewicz wrote: > > > On Nov 24, 2022, at 7:10 AM, Dotzero wrote: > >  > > > On Tue, Nov 15, 2022 at 12:29 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Your solution is straightforward,

Re: [dmarc-ietf] Not Multiple From: mailboxes, was I-D Action: draft-ietf-dmarc-dmarcbis-24.txt

On Tue, Nov 15, 2022 at 12:29 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Your solution is straightforward, but I am not sold. > > DMARC PASS means that the message is free of author impersonation. This > can only be true if all authors are verifiable and verified. > This

Re: [dmarc-ietf] Standardizing signature contents

On Sat, Oct 29, 2022 at 1:30 AM Neil Anuskiewicz wrote: > > DMARC’s job is to flat out prevent unauthorized spoofing. It’s not a > stretch to imagine some higher signature standard without feeling like > you’re on DKIM’s turf. > The above statement is so incorrect. DMARC's "job" is to

Re: [dmarc-ietf] Weak signatures

On Thu, Oct 27, 2022 at 10:33 AM Brotman, Alex wrote: > How will we handle the ever-changing definition of "weak"? > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > This is why I don't believe "weak" should be included in any normative manner. I'm not sure that

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

On Mon, Oct 24, 2022 at 5:47 AM Alessandro Vesely wrote: > On Sun 23/Oct/2022 14:16:30 +0200 Dotzero wrote: > > On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely > wrote: > >> On Sat 22/Oct/2022 18:25:55 +0200 Dotzero wrote: > >>> Unaligned signatures a

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

On Sun, Oct 23, 2022 at 6:29 AM Alessandro Vesely wrote: > On Sat 22/Oct/2022 18:25:55 +0200 Dotzero wrote: > > Unaligned signatures are orthogonal/irrelevant to DMARC. They may be > useful in > > other contexts. In the DKIM standard, signatures mean that the signer is

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

s needed > for reporting. Not 100, not 10, just 1. > > Doug > > On Sat, Oct 22, 2022, 7:43 AM Dotzero wrote: > >> " 3) A signature has been compromised and an unauthorized source is >> sending authenticated mail. SPF FAIL with DMARC PASS provides the alarm >>

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

" 3) A signature has been compromised and an unauthorized source is sending authenticated mail. SPF FAIL with DMARC PASS provides the alarm trigger." This is incorrect. SPF FAIL with DMARC PASS can simply be an indirect mail flow. It might also be an incorrectly configured SPF record. Michael

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

On Tue, Oct 18, 2022 at 11:18 PM Scott Kitterman wrote: > > > On October 18, 2022 10:16:44 PM UTC, Neil Anuskiewicz < > n...@marmot-tech.com> wrote: > > > > > >> On Oct 2, 2022, at 11:01 AM, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> > >>  > >> In many cases, an

Re: [dmarc-ietf] Aggregate Reporting - "Not Evaluated" result

On Sun, Oct 2, 2022 at 2:01 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > In many cases, an evaluator can determine a DMARC PASS result > without evaluating every available identifier. > >- If a message has SPF PASS with acceptable alignment, the evaluator >has no need

Re: [dmarc-ietf] Issue: Domain Owner policy in Section 5

+1 to Scott's suggestion. Michael Hammer On Sat, Aug 27, 2022 at 5:49 PM Barry Leiba wrote: > I’m happy with Scott’s suggestion. > > Barry > > On Sat, Aug 27, 2022 at 5:11 PM Scott Kitterman > wrote: > >> On Thursday, August 25, 2022 1:43:49 PM EDT Barry Leiba wrote: >> > > On Wed 24/Aug/2022

Re: [dmarc-ietf] Issue opened: Use a four-valued token for the four roles of a DMARC policy

+1 to Scott and John's comments. I read it and do not find a compelling value equation for including. Michael Hammer On Sat, Aug 27, 2022 at 10:41 PM John Levine wrote: > It appears that Scott Kitterman said: > >> - If you disagree with Doug's proposal, please clearly and concisely > >>

Re: [dmarc-ietf] Mailing List message authentication

I agree with Scott. We do need to be that blunt given what people have thrown out there because DMARC doesn't say it's not ok. One thing we have been firm about is that if there isn't a DMARC record it isn't DMARC. For "other things", people are free to go off and experiment with consenting

Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)

On Fri, Aug 12, 2022 at 12:28 PM John R Levine wrote: > On Fri, 12 Aug 2022, Alessandro Vesely wrote: > >> When Dave proposed the Author header, part of the idea was that DMARC > could > >> use it rather than From. > > > > IIRC that was the Sender: field. > > No, DMARC decided not to use Sender

Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting

On Mon, Aug 8, 2022 at 4:14 AM Alessandro Vesely wrote: > On Sun 07/Aug/2022 19:20:12 +0200 John Levine wrote: > >>> By remembering failure reports issued in the past, new failures having > >>> already reported characteristics (e.g. same forwarder) can be silently > >>> ignored. That would

Re: [dmarc-ietf] Girl Scout troops vs MLM problems (#70)

On Sun, Aug 7, 2022 at 6:41 PM John R Levine wrote: > Moving this back to the main list: > > I said: > Even if I agreed that it would be a good idea for every mailing list in the > world to rewrite From lines so it's harder to tell who the messages are > from and > you can't reply reliably,

Re: [dmarc-ietf] Collecting message metadata, was Time to work on failure reporting

On Sun, Aug 7, 2022 at 6:04 AM Alessandro Vesely wrote: > On Sat 06/Aug/2022 16:29:47 +0200 John Levine wrote: > >>> I don't understand what you mean by "no data collection." It is true > that > >>> you can send a failure report immediately without saving anything for > >>> later. > >> > >>

Re: [dmarc-ietf] what to document about the tree walk

On Thu, Jul 14, 2022 at 11:12 AM Murray S. Kucherawy wrote: > On Thu, Jul 14, 2022 at 6:13 AM Scott Kitterman > wrote: > >> >> I think a choice within DMARCbis is a bad idea. Effectively the >> choice exists. Evaluators will have the choice to stay with an RFC 7489 >> design or to upgrade to

Re: [dmarc-ietf] Bridging the gap

On Sat, Jun 18, 2022 at 11:45 AM Barry Leiba wrote: > I don't know... I would say that if the working group has rough > consensus to reach out and asks someone(s) to do it, they could then > say that they're calling on behalf of the working group. No? > > Barry > Personally, if this is

Re: [dmarc-ietf] SPF doesn't accommodate third level .name domains?

On Tue, May 31, 2022 at 1:14 PM David Bustos wrote: > John wrote: > > It appears that Scott Kitterman said: > > >On May 30, 2022 9:50:05 PM UTC, David Bustos wrote: > > >>Since I own david.bustos.name, someone forwards da...@bustos.name for > me; I presume Verisign does. > > >> > > >>Lately I

[dmarc-ietf] DMARCbis and Standard Track

My understanding when the DMARCbis effort was spun up was that we were trying to move it to Standard Track. Is this still the goal? A number of experimental things are currently being included. This would seem to preclude DMARC being on Standard Track. If the experimental items being discussed

Re: [dmarc-ietf] Figuring out the tree walk

On Mon, Feb 14, 2022 at 10:46 AM Todd Herr wrote: > On Sun, Feb 13, 2022 at 5:16 PM Dotzero wrote: > >> >> >> On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman >> wrote: >> >> >>> >>> I think "a" would be cleanest, but

Re: [dmarc-ietf] Figuring out the tree walk

On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman wrote: > > I think "a" would be cleanest, but I think it would cause too much > backward > compatibility trouble and should not be further considered. In previous > working group discussions on this I recall specific suggestions that this > would

Re: [dmarc-ietf] (7.1?) DKIM-only authentication

On Fri, Feb 11, 2022 at 3:14 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I know that we took out the reference to default policy at my request, and > I think it was in section 7.1. But subsequent discussion helped me to > understand objectives that were not clear to me in

Re: [dmarc-ietf] 7.1 SPF -ALL

On Fri, Feb 11, 2022 at 7:19 AM Alessandro Vesely wrote: > On Fri 11/Feb/2022 08:57:17 +0100 Douglas Foster wrote: > > This section implies that publishing SPF -ALL is a risky move, which is > made > > worse by DMARC.SPF -ALL is a only risk when (a) the message is forwarded > > without MAILFROM

  1   2   3   >