[dmarc-ietf] Re: Proxy signatures to combat SPF upgrade?

> On Jun 7, 2024, at 1:14 AM, Richard Clayton wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > In message il.com>, Douglas Foster writes > >> Google applies annotation signatures from .. >> gappsstmpt.com, with periods replaced in the domain name. >> Microsoft applies proxy

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

> On May 8, 2024, at 12:59 PM, John Levine wrote: > > According to Mark Alley : >> -=-=-=-=-=- >> >> p=none is one solution, the other ( interoperable method) is to exempt the >> traffic from whatever process is breaking DKIM (i.e. external subject/body >> warning tags, URL rewriting,

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

> On May 7, 2024, at 6:09 PM, 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 by the FBI. Although we are in last call, I >> have to wonder if a) the attack itself, and/or b)

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

> On May 7, 2024, at 7:19 PM, John Levine wrote: > > It appears that Scott Kitterman said: >>> Addressing this issue - perusing Section 5.5.6, is there anything else >>> we could add that would be acceptable language in an Standards track >>> document to encourage urgency behind a

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

SPF.” I said no, > because that’s unworkable. > > It seems to me that until ARC is in widespread use, there will be mail that > is too important to use p=reject for. Yes, in fact, if I’m not mistaken the concept of the “general purpose” domain that’s perpetually p=none came about because of these kind of scenarios. One or more subdomains set aside for such use cases. It might be just a necessity as an intermediate step along this journey. Neil ___ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org

Re: [dmarc-ietf] Thoughts on choosing N

> On Apr 17, 2024, at 6:20 PM, John Levine wrote: > > It appears that Todd Herr said: >> When DMARC was first developed, there was concern about DNS load and >> needing to minimize DNS lookups. Operational expertise now shows that this >> is no longer cause for concern. >> >> Short

Re: [dmarc-ietf] Thoughts on choosing N

> On Apr 17, 2024, at 8:29 AM, Alessandro Vesely wrote: > > On Wed 17/Apr/2024 15:42:23 +0200 Todd Herr wrote: >>> On Wed, Apr 17, 2024 at 1:06 AM Scott Kitterman >>> wrote: >>> I am confused. >>> >>> Under the current (7489) rules a record for _dmarc.c.d.e.f.tld won't be >>> found either

Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

On Apr 17, 2024, at 6:33 AM, Todd Herr wrote:On Wed, Apr 17, 2024 at 1:18 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:On Apr 16, 2024, at 2:18 PM, Todd Herr 40valimail@dmarc.ietf.org> wrote:Colleagues,DMARCbis currently describes the value of 'n' for the 'ps

Re: [dmarc-ietf] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

> On Apr 16, 2024, at 2:18 PM, Todd Herr > wrote: > >  > Colleagues, > > DMARCbis currently describes the value of 'n' for the 'psd' tag in a policy > record as follows: > > The DMARC policy record is published for a PSD, but it is not the > Organizational Domain for itself and its

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

> On Apr 1, 2024, at 2:43 PM, John R. Levine wrote: > > On Sun, 31 Mar 2024, Jim Fenton wrote: >> Based on the above problems, I do not think DMARC-bis should be published as >> a standards track document by IETF. > > This reminds me of the NAT wars in the 1990s. We all understand that

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

On Mar 31, 2024, at 12:45 PM, Seth Blank wrote:On Sun, Mar 31, 2024 at 2:00 PM John Levine wrote:It appears that Mark Alley  said: >>   People who publish -all know what they do. > >I posit that there is a non-insignificant amount of domain owners that

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

> On Apr 7, 2024, at 6:20 PM, Scott Kitterman wrote: > >  > >> On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz >> wrote: >> >> >>>> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote: >>> >>>  >>> >&g

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

> On Mar 17, 2024, at 9:12 AM, Alessandro Vesely wrote: > > On Sun 17/Mar/2024 16:50:40 +0100 internet-drafts wrote: >> Internet-Draft draft-ietf-dmarc-failure-reporting-10.txt is now available. It >> is a work item of the Domain-based Message Authentication, Reporting & >> Conformance

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

> On Apr 7, 2024, at 7:00 AM, Neil Anuskiewicz wrote: > >  > >> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote: >> >> Scott Kitterman writes: >>> I hear you. Your operational issue is my system working as designed. >>> DMARC works on top

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

> On Apr 7, 2024, at 9:27 AM, John R Levine wrote: > > On Sun, 7 Apr 2024, Neil Anuskiewicz wrote: >> I think clear statement and supporting text explaining clearly that SPF is >> no longer the policy layer would be a good idea. While it might be slightly >> out o

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

> On Apr 7, 2024, at 6:54 AM, Tero Kivinen wrote: > > Scott Kitterman writes: >> I hear you. Your operational issue is my system working as designed. >> DMARC works on top of SPF, it doesn't change it. > > Yes, DMARC works on top of SPF, and DKIM and provides policy layer. We > are trying to

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

Forgive me if this a dumb idea but, Scott and others, any discussion of just deprecating SPF hardfail at some point? > On Apr 6, 2024, at 1:40 PM, John Levine wrote: > > It appears that Scott Kitterman said: >> I hear you. Your operational issue is my system working as designed. DMARC >>

Re: [dmarc-ietf] DMARCbis WGLC - Issue 141 DMARC and What To Say About SPF -all

> On Apr 6, 2024, at 1:40 PM, John Levine wrote: > > It appears that Scott Kitterman said: >> I hear you. Your operational issue is my system working as designed. DMARC >> works on top of SPF, it doesn't change it. >> >> Anything like this belongs in an operational guidance document,

[dmarc-ietf] General Purpose Domain

grok what exactly they’re supposed to do and why. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

planation of the general purpose domain. It’s not complicated but I think the idea is going to be new for a lot of people. Some people might misunderstand in less than useful ways as well. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] DMARCbis WGLC Issue 136 - DMARC Records Can Be CNAMEs

wn. > Those who don't are better off not trying it. It’s mostly ESP’s with large customer bases that ask for CNAMES, providing them with scalability, and the ability to rotate keys. It’s the appropriate choice in some contexts. Why is this a concern of the WG? Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

> On Mar 11, 2024, at 10:38 PM, Neil Anuskiewicz wrote: > >  > The solution to that vulnerability is in part use a subdomain and, when > possible, narrow the scope of what you permit. Better yet, choose a vendor > that’s known for tight security. A quick Look at the the

Re: [dmarc-ietf] Fwd: Break SPF response: DKIM Only

> On Mar 4, 2024, at 11:07 PM, Chuhan Wang wrote: > >  > Hi Douglas, > > Thank you for your insightful summary of our paper. I'd like to share some of > my opinions. > > You mentioned clients lose control of their SPF integrity. It's one of the > key problems exactly. Clients host their

Re: [dmarc-ietf] Don't trivialize psd=n

Is there any reason to lead with don’t worry about the tag but there is one critical use case. I think a more declarative statement in favor of the tag for those who will be stressed and skimming. Sure they might add a psd where it’s not needed but that’s better than not know the important

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

until threat actors started writing thank you notes.On Tue, Mar 12, 2024 at 1:38 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:The solution to that vulnerability is in part use a subdomain and, when possible, narrow the scope of what you permit. Better yet, choose a vendor that’s kn

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

The solution to that vulnerability is in part use a subdomain and, when possible, narrow the scope of what you permit. Better yet, choose a vendor that’s known for tight security. A quick Look at the the security headlines will show you some vendor red flags. But the sad state of spf is a

Re: [dmarc-ietf] DMARCbis WGLC Issue - Description of rua and ruf Tags

> On Mar 1, 2024, at 5:39 PM, John R Levine wrote: > > On Fri, 1 Mar 2024, Seth Blank wrote: >>> It seems OK but I would say that at this point that mailto: URI are the >>> only ones currently defined. >>> >> >> Participating, to this point. Throwing out an idea, that may be >>

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-30.txt

Well done! This was a technical and quasi political journey and I felt I had front row seats. Neil > On Feb 28, 2024, at 3:05 PM, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-dmarc-dmarcbis-30.txt is now available. It is a > work > item of the Domai

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

I’d say extend your thinking on why beyond the format itself. What else could be the cause? On Mar 11, 2024, at 7:33 PM, Neil Anuskiewicz wrote:Wow, the stat on how many domain operators move to enforcing reject policy sans aggregate reports shocked me. Trust the force, Luke.On Feb 28, 2024

Re: [dmarc-ietf] Inconsistencies in DMARC Aggregate Report XML Schema

Wow, the stat on how many domain operators move to enforcing reject policy sans aggregate reports shocked me. Trust the force, Luke.On Feb 28, 2024, at 4:54 AM, OLIVIER HUREAU wrote:Hello,TLDR: I think Dmarcbis should not have reference to the XML format of the aggregate reports in 5.5.3 and

Re: [dmarc-ietf] 4.1 DMARC Basics

> On Mar 3, 2024, at 1:41 AM, ves...@tana.it wrote: > > Hi, > > the last two paragraphs of section 4.1 also show a neat asymmetry between rua > and ruf. The first sounds like the notification that feedback exists rather > than something a mail receiver should do. The second is good, but

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

> On Feb 29, 2024, at 10:55 AM, Todd Herr > wrote: > >  > Colleagues, > > I've been reading DMARCbic rev -30 today with a plan to collect the first set > of minor edits and I came across a sentence that I believe goes beyond minor, > so wanted to get a sanity check. > > Section 7.6,

Re: [dmarc-ietf] A.5 Issues with ADSP in Operation

Please remove the pct tag from the spec. > On Mar 9, 2024, at 7:05 AM, Alessandro Vesely wrote: > > Hi, > > as ADSP is historical, perhaps we can strike A5 entirely. If not, we should > at least eliminate bullet 5: > > 5. ADSP has no support for a slow rollout, i.e., no way to configure

Re: [dmarc-ietf] picking nits with the ABNF

> On Mar 9, 2024, at 7:33 PM, OLIVIER HUREAU > wrote: > >  > >> dmarc-version = "v" equals %s"DMARC1 > > I believe the "%s" should be dropped > > 'DMARC1' is case-sensitive in 7489. > Either we keep the "%s" or we go back to 7489 version : "%x44 %x4d %x41 %x52 > %x43 %x31" > > > I think

Re: [dmarc-ietf] DMARCbis rev 29

Well done! I feel that rough consensus must be close. > On Dec 2, 2023, at 5:10 AM, Alessandro Vesely wrote: > > On Fri 01/Dec/2023 21:06:24 +0100 Steven M Jones wrote: >> There are only four open items on the issue tracker - though I think the SPF >> question >>

Re: [dmarc-ietf] Dmarcbis way forward

> 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 >

Re: [dmarc-ietf] Dmarcbis way forward

> 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 >> stat

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

eresting to know what they sent and how it assuaged those worried about the PII. Eventually, I’d reckon, Yahoo will stop sending failure reports, rendering them worthless as nobody you’ve heard of will send them. This issue isn’t a five alarm fire. I figure

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

ata or send straight up failure reports? Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Dmarcbis way forward

> 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,

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

On Nov 11, 2023, at 1:21 PM, Dotzero wrote:On Sat, Nov 11, 2023 at 3:45 PM Neil Anuskiewicz <n...@marmot-tech.com> 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 p

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

On Nov 11, 2023, at 11:56 AM, Dotzero wrote:On Sat, Nov 11, 2023 at 1:47 PM Neil Anuskiewicz <n...@marmot-tech.com> 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

Re: [dmarc-ietf] Dmarcbis way forward

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

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

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 Hammer > ___ > dmarc

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

On Oct 25, 2023, at 3:57 AM, Olivier Hureau 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 apply is "none," because the p/sp/np value was

Re: [dmarc-ietf] Dmarcbis way forward

few minutes to avoid dead horse beating that I’m sure is annoying. Neil > > >> On Mon 23/Oct/2023 10:03:36 +0200 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 abou

Re: [dmarc-ietf] Codifying "Apex Domain"?

On Nov 9, 2023, at 6:40 AM, Todd Herr wrote:Colleagues,I note that lately in various email fora that the term "apex domain" has found some favor, said term being used interchangeably with "organizational domain", and having the same contextual meaning as "organizational domain".DMARCbis does not

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

> 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

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

For routine, remote is perfect but I’d imagine hums leave no doubt in Prague and a chance for rapport to be established. As an observer this proces made me tense and annoyed at time. Myn2 cents is go to Prague. It’s a gorgeous city. This group has a gruff vibe in the tradition of Usenet but our

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

On Oct 29, 2023, at 7:57 AM, Dotzero wrote: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

Re: [dmarc-ietf] (no subject)

> On Nov 8, 2023, at 8:46 AM, John R. Levine wrote: > > On Mon, 6 Nov 2023, Douglas Foster wrote: >> Since IETF cannot protect its own lists from conspicuous impersonation, it >> seems poorly qualified to tell anyone else how to do so. > > Actually, that message had nothing whatsoever to do

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

> On Oct 20, 2023, at 8:43 AM, Alessandro Vesely wrote: > > On Fri 20/Oct/2023 15:50:29 +0200 OLIVIER HUREAU 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'

Re: [dmarc-ietf] Why Relaxed Alignment?

On Oct 18, 2023, at 7:24 AM, Todd Herr wrote:On Tue, Oct 17, 2023 at 9:51 PM Douglas Foster wrote:Why do we need to support relaxed alignment at all?A common use case for relaxed alignment is when an organization (e.g., WeSellStuff) employs a third party

Re: [dmarc-ietf] DBOUND

On Oct 16, 2023, at 6:48 PM, Neil Anuskiewicz wrote: > > >> On Oct 16, 2023, at 6:43 PM, Seth Blank >> wrote: >>  >> I'm sorry, to what are you referring? I co-chair the M3AAWG technical >> committee, and am unaware of any advocacy for relitigating D

Re: [dmarc-ietf] DBOUND

See section VOn Oct 16, 2023, at 6:43 PM, Seth Blank wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3A

Re: [dmarc-ietf] DBOUND

On Oct 16, 2023, at 6:43 PM, Seth Blank wrote:I'm sorry, to what are you referring? I co-chair the M3AAWG technical committee, and am unaware of any advocacy for relitigating DBOUND...On Mon, Oct 16, 2023 at 6:36 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:M3AAWG is advocat

[dmarc-ietf] DBOUND

M3AAWG is advocating for DBOUND as most of you likely know. Does it seem a viable alternative? We could sure use the support of M3AAWG. How could we earn their support or are they committed to DBOUND? Perhaps once we prove that DMARCbis works they’ll reconsider. Neil

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

> On Oct 16, 2023, at 4:53 PM, Dotzero wrote > https://www.m3aawg.org/ had sessions on DMARCbis, DKIM replay, etc. at their > meeting in Brooklyn last week. I did not attend. A number of ISPs, mailbox > providers, ESPs, etc. participate. I don't see it as something IETF organizes. > >

[dmarc-ietf] Getting the word out and educating

through multiple mediums. I think good articles and videos will be key. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

> On Oct 16, 2023, at 11:00 AM, Scott Kitterman wrote: > >  > >> On October 16, 2023 5:53:13 PM UTC, Alessandro Vesely wrote: >>> On Fri 13/Oct/2023 16:35:43 +0200 Neil Anuskiewicz wrote: >>> Thank you, sir. That’s part of the reason to cautiously trans

Re: [dmarc-ietf] Tree Walk impact

that these domains want to be treated as organizations, not PSOs, and tbe stop-last Tree Walk will enable what they have been wanting.DougOn Fri, Oct 13, 2023, 1:06 AM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote: > On Oct 10, 2023, at 11:57 AM, Alessandro Vesely <ves...@tana.

Re: [dmarc-ietf] Tree Walk impact

thers may find minor variants of this data.Doug FosterOn Fri, Oct 13, 2023 at 7:18 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote: > On Oct 13, 2023, at 3:59 AM, Douglas Foster <dougfoster.emailstanda...@gmail.com> wrote: > >  > The first step in my research has been t

Re: [dmarc-ietf] Tree Walk impact

luence your decisions. The low numbers at this stage make getting the basic data much easier. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Tree Walk impact

I’d say it’s best practice to have a separate policy subdomains. We should encourage it.foo.example.com’s spoofed by one vendor most likely, so switching vendors isn’t too big a task. No need to roll example.com back to none. Just role foo back. It’s clearly a better way to go. Set things up so

Re: [dmarc-ietf] Tree Walk impact

ile for DNS will become largely irrelevant in the big picture, taking the Internet another step out of childhood toward adulthood. That’s a good thing even if some things go wrong along the way that need to be fixed or mitigated. The Internet is a place where the perfect is often more blatantly the enemy of the good. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

From: Dave Crocker Date: Saturday, August 5, 2023 at 9:49 AM To: Jesse Thompson , Neil Cc: Todd Herr , IETF DMARC WG Subject: Re: [dmarc-ietf] Idle Musings - Why Is It DMARC and not DMARD? > The language used for DMARC has always been problematic. "Policy" > implies control

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

> On Jul 19, 2023, at 3:21 PM, Douglas Foster > 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 language, > "DMARC Fail with

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

% authentication effort.   I have to depend on content filtering to flag those suspicious actors, and the confirmed attackers will be given a block rule.Doug FosterOn Sun, Jul 23, 2023 at 9:30 AM Neil Anuskiewicz <n...@marmot-tech.com> wrote:Doug, you’ve done a fine job of explaining as I

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

> On Jun 8, 2023, at 4:25 PM, Scott Kitterman wrote: > > The data I have seen (and it sounds like Mike is saying the same thing) > shows DKIM verification results are less than 100%, consistently, for direct > connections. It was always lower than the SPF pass rate for hosts listed in > a

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

Michael,As someone who did work for an ESP, your bit about the conflict between short term cash flow that a short term customer with some money to spend for a few months and the optimizing for customer lifetime value. That war, or shall I say tension, was always there. I’d imagine the little ESP I

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

Yes sir, I’m convinced. Some of my more conservative customers who take security deadly serious won’t even bounce a DMARC failure with a helpful message. It’s discard. I respect the person I’m thinking of who hates bouncing. He’s appropriately paranoid for a InfoSec manager. > On Jul 23, 2023,

Re: [dmarc-ietf] DMARC and Data Hygiene

 At a fundamental authentication property level, there are additional differences too.  IPs tend to be shared more than private keys. Proving an IP based validation to a third party is harder than with a digital signature.  (This is one the issues of trusting the SPF results in

Re: [dmarc-ietf] DMARC and Data Hygiene

On Jun 20, 2023, at 11:42 PM, Wei Chuang wrote:On Tue, Jun 20, 2023 at 8: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

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

> On Jun 30, 2023, at 11:33 AM, Dave Crocker wrote: > > On 6/30/2023 11:22 AM, Todd Herr wrote: >> Why is the mechanism called "Domain-based Message Authentication, Reporting, >> and Conformance" and not "Domain-based Message Authentication, Reporting, >> and Disposition"? > > Say DMARC

Re: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-28.txt

I hated that concept until I tried it out with a client, a law firm, and they loved it and I saved them massive headaches. The general purpose we used was a subdomain just for lists and it’s worked perfectly so far. I’m now in favor of advocating general purpose domains. Let’s get ESR to put

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

> On Jul 12, 2023, at 3: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. > > I understand your view and agree on the problem. I also sympathize

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

> On Jul 7, 2023, at 8:48 AM, John Levine wrote: > > It appears that Barry Leiba said: >> I, too, prefer MUST to SHOULD there, but it was clear to me that we >> will not reach rough consensus on MUST, but that we can reach rough >> consensus on SHOULD. >> >> I do like your suggestion of

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

> On Jul 6, 2023, at 12:04 PM, Barry Leiba wrote: > > As I've said before, I think we should specify what we think is right, > and allow implementers to make their decisions. We can't and won't > police them. No way. It wouldn’t be possible even if we all made it our life’s work to be

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

>> >> > > I think it is a mistake to consider technologies such as SPF, DKIM, and DMARC > as anti-spam. They are a component of spam mitigation, but authentication of > an identifier isn't a solution for spam. Meng Wong (for those of you that > weren't around, he's the one that synthesized

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

later to mitigate damage while you investigate? I guess I’m saying the two ideas aren’t mutually exclusive. Neil > On Jul 15, 2023, at 4:27 AM, Douglas Foster > wrote: > >  > Murray recently observed, correctly, that something went horribly wrong with > the DMARC rollout,

Re: [dmarc-ietf] Signaling MLMs

> On Apr 15, 2023, at 6:56 AM, Jesse Thompson wrote: > >  >> On Fri, Apr 14, 2023, at 10:24 PM, Scott Kitterman wrote: >> On Friday, April 14, 2023 10:31:33 PM EDT Jesse Thompson wrote: >> > On Fri, Apr 14, 2023, at 7:17 PM, Murray S. Kucherawy wrote: >> > > The Sender's users being denied

Re: [dmarc-ietf] Signaling MLMs

lished players that gets there first or it could be an upstart. I think the odds favor one of the better established players. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

of the established players that gets there first or it could be an upstart. I think the odds favor one of the better established players. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Signaling MLMs

On Apr 15, 2023, at 7:52 AM, Hector Santos wrote:On Apr 14, 2023, at 7:31 PM, Dotzero wrote:On Fri, Apr 14, 2023 at 5:55 PM Hector Santos isdg.net> 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

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

nt. The other versions say relatively the same thing. > > - Mark Alley I think what Mark’s saying isn’t perfect for but I think it can get the rough consensus we’re seeking. That’s my humble opinion. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

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

> On Apr 15, 2023, at 4:21 PM, Scott Kitterman wrote: > >  > >> On April 15, 2023 10:58:06 PM UTC, Neil Anuskiewicz >> wrote: >> >> >>>> On Apr 14, 2023, at 8:26 PM, Scott Kitterman wrote: >>> >>> Perfect. The

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

w men and especially the red herrings. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Author vs Signer Domains

> On Apr 14, 2023, at 6:42 PM, Hector Santos > wrote: > > On 4/14/2023 7:31 PM, Dotzero wrote: >> On Fri, Apr 14, 2023 at 5:55 PM Hector Santos >> mailto:40isdg@dmarc.ietf.org>> wrote: >> >>Yes, it is simple DeMorgan’s Theorem where you use >>short-circuiting logic. >> >>

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

On Apr 14, 2023, at 2:54 PM, Dotzero wrote: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

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

On Apr 11, 2023, at 9:25 PM, Murray S. Kucherawy wrote:On Tue, Apr 11, 2023 at 8:25 PM Neil Anuskiewicz 40marmot-tech@dmarc.ietf.org> wrote:The standard and the document should reflect that it’s already making a massive difference and could do even more. I don’t think it’s unreasona

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

> On Apr 8, 2023, at 6:56 AM, John Levine wrote: > > We're never going to persuade DMARC absolutists that the damage is real, > nor the rest of us that we can wave our hands and ignore the damage. John, the damage is real. There’s no doubt about that. Trade offs, painful trade offs, have to

Re: [dmarc-ietf] Weakening of enforcement concern

that is pretty impressive.   My Gmail accounts have very few problems with either spam getting through or wanted messages getting blocked.I don't have the same content filtering sophistication, so I have ramped up my sender filtering.Doug FosterOn Tue, Apr 11, 2023, 11:15 AM Neil Anuskiewicz <n...@mar

Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 11, 2023, at 2:45 PM, Neil Anuskiewicz wrote: > >  > >> On Apr 11, 2023, at 2:29 PM, John Levine wrote: >> >> It appears that Neil Anuskiewicz said: >>> Thanks. Even if it hasn’t always been the case, DMARC has evolved to be >>>

Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 11, 2023, at 2:29 PM, John Levine wrote: > > It appears that Neil Anuskiewicz said: >> Thanks. Even if it hasn’t always been the case, DMARC has evolved to be >> thought of by most technical people as focused on security. > > I can believe that's t

Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 11, 2023, at 9:14 AM, Mark Alley > wrote: > >  > I agree with where you're coming from, as these were my same concerns as > well. That's why I also tried to say a couple of times that I feel if we make > an effort to make clear the interoperability expectations, but also have >

Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 11, 2023, at 4:29 AM, Douglas Foster > wrote: > >  > Neil, I am slowly embracing the position of the Mailing List advocates. > > If mailing lists and all other exceptional situations could be eliminated, > evaluators could mindlessly apply a rule to &quo

Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz wrote: > >  > >>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote: >>> >>> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: >>> I’m a bit concerned that the document will

Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote: > > On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: >> I’m a bit concerned that the document will discourage domain owners from >> working toward an enforcing policy. I’ve seen at least one pe

Re: [dmarc-ietf] Weakening of enforcement concern

> On Apr 10, 2023, at 9:13 PM, Neil Anuskiewicz wrote: > > I’m a bit concerned that the document will discourage domain owners from > working toward an enforcing policy. I’ve seen at least one person say that > most domains don’t need to go to p=reject. I’ve seen all s

[dmarc-ietf] Weakening of enforcement concern

will receive the most attention but threat actors absolutely do attack all sorts of organizations all the time. Maybe I’ve misunderstood but I hope that no langue that could be construed as discouraging domain owners from moving toward an enforcing policy would be a mistake. Neil

  1   2   >