Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

On Saturday, August 5, 2023 6:11:03 PM EDT Tim Wicinski wrote: > On Sat, Aug 5, 2023 at 6:00 PM Scott Kitterman wrote: > > On August 5, 2023 9:51:54 PM UTC, Tim Wicinski wrote: > > >On Sat, Aug 5, 2023 at 5:35 PM John Levine wrote: > > >

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

On August 5, 2023 9:51:54 PM UTC, Tim Wicinski wrote: >On Sat, Aug 5, 2023 at 5:35 PM John Levine wrote: > >> According to Tim Wicinski : >> >-=-=-=-=-=- >> > >> >Based on the ABNF in -28, how about something like this: >> > >> > >> >dmarc-method = "dkim" / "spf" >> > >> >dmarc-auth = "auth" e

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >>When receivers apply the "MUST NOT reject" in Section 8.6 to accept > >>unauthenticated messages as quarantined messages, receivers SHOULD > >>carefu

Re: [dmarc-ietf] Proposal for auth policy tag in draft-ietf-dmarc-dmarcbis

On August 4, 2023 4:16:39 PM UTC, Wei Chuang wrote: >At IETF-117, I restarted the proposal for a policy "auth=" tag based on the >proposal here >. >The "auth=" policy allows for restriction of SPF in scenarios where it >

Re: [dmarc-ietf] Proposal for additional Security Considerations for SPF Upgrade in draft-ietf-dmarc-dmarcbis

On August 4, 2023 4:15:35 PM UTC, Wei Chuang wrote: >I noted at the DMARC session -117, that with the p=reject downgrade to >quarantine language, this increases the risk of SPF upgrade attacks due to >forwarding. The reply was to propose language for this and below is the >suggested text for

Re: [dmarc-ietf] Reflections on IETF 117 Conference and DMARC Meeting

PRA was not donated to anyone. Licensing terms for it was what blew up MARID. It's not helpful here, let's move on. Scott K On August 4, 2023 2:01:14 PM UTC, Hector Santos wrote: >Overall, DMARCbis has a “SPF comes before DMARC” conflict where SPF can >“preempt” DMARC. > >The implementatio

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

On July 21, 2023 6:53:03 PM UTC, "Jan Dušátko" wrote: > > >Dne 21. 7. 2023 v 16:34 Murray S. Kucherawy napsal(a): >> On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> I don't take DMARC as a certain result to be used in isolation, but >>> cl

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

On July 21, 2023 3:14:58 PM UTC, Alessandro Vesely wrote: >On Fri 21/Jul/2023 10:22:06 +0200 Matthäus Wander wrote: >> Murray S. Kucherawy wrote on 2023-07-08 02:44: >>> "SHOULD" leaves the implementer with a choice.  You really ought to do what >>> it says in the general case, but there might

Re: [dmarc-ietf] Eliminating From Munging from this list

On July 20, 2023 7:46:57 AM UTC, Alessandro Vesely wrote: >On Wed 19/Jul/2023 21:38:44 +0200 Scott Kitterman wrote: >> >> >> On July 19, 2023 5:38:08 PM UTC, Alessandro Vesely wrote: >>> On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote: >>>> O

Re: [dmarc-ietf] Eliminating From Munging from this list

On July 19, 2023 5:38:08 PM UTC, Alessandro Vesely wrote: >On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote: >> On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely wrote: >>> On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote: >>>> On Tue, Jul 18,

Re: [dmarc-ietf] Eliminating From Munging from this list

On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely wrote: >On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote: >> On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> 1) For evaluators that enforce DMARC against lists, are they willing

Re: [dmarc-ietf] SMTP Result Codes was -Re: Another p=reject text proposal

On July 12, 2023 1:11:37 PM UTC, Todd Herr wrote: >On Wed, Jul 12, 2023 at 7:30 AM Scott Kitterman >wrote: > >> On Wednesday, July 12, 2023 7:04:38 AM EDT Alessandro Vesely wrote: >> > On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote: >> > > On Wed

Re: [dmarc-ietf] SMTP Result Codes was -Re: Another p=reject text proposal

On Wednesday, July 12, 2023 7:04:38 AM EDT Alessandro Vesely wrote: > On Wed 12/Jul/2023 12:54:38 +0200 Scott Kitterman wrote: > > On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote: > > ... > > > >> Why? Because it's brittle and will only bri

[dmarc-ietf] SMTP Result Codes was -Re: Another p=reject text proposal

On Wednesday, July 12, 2023 3:29:34 AM EDT Baptiste Carvello wrote: ... > Why? Because it's brittle and will only bring them more headaches? At > the very least, DMARC would need to use its own 5xy reply code to avoid > the need for parsing the reply text… ... This is a very good point. The IANA

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

se PTR lookup and match the SPF record domain name (or > match some subset like the org domain) to forward validate. Only one > domain can claim ownership for the IPs and be allowed to SPF authenticate > for DMARC. > > -Wei > > On Mon, Jul 10, 2023 at 5:38 PM Scott Kitterman

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

I've been thinking about the thread on ditching SPF relative to DMARC. DMARC is built on other protocols. Piles of them. DMARC is built most directly on DNS, DKIM, and SPF. It is also built on SMTP and Email. DKIM and SPF are also built on DNS and SMTP (SPF) or Email (DKIM). These protocols

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

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 lan

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

On Friday, July 7, 2023 3:18:29 AM EDT Alessandro Vesely wrote: > On Thu 06/Jul/2023 21:01:48 +0200 internet-drafts wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This Internet-Draft is a work item of the Domain-based > > Message > > Authentication, R

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

Doesn't sieve happen during delivery, after the message has been accepted? Is so, I don't think it's a useful comparison to make. The lack of bounce/rejection messages results in messages that vanish and undermines the reliability of the email ecosystem. I agree that silent discard between MT

[dmarc-ietf] Fwd: Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows

-- Begin Message --- On Tuesday, April 25, 2023 2:27:18 PM EDT Scott Kitterman wrote: > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > > I raised this issue in the DMARC session in Vienna, and have let it > > sit for a while so as not to derail other discussion. As we&

Re: [dmarc-ietf] DMARC session agenda for IETF 117

For clarity: When you say, "AD will call consensus on this issue", you mean after the results of the discussion are brought to the list and reviewed by the working group, not at the meeting, right? Also, I expect to have a proposal on protocol reliability related to the "drop SPF" discussion,

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

I think it's quite relevant. The assumption that this is based on is there's a need to specify because SPF data is not reliable enough for everyone. If that premise is correct (I don't agree with it, but it's a separate issue), then I think telling people that they should use DKIM because it I

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

On June 26, 2023 12:51:06 PM UTC, florian.kun...@telekom.de wrote: > >> In theory, DKIM is enough for DMARC (this was always true), but in practice >> it >> is not. > >May be you can afford to use SPF, DKIM, DMARC in pure theory for your day job, >but people here expect to apply it to solve rea

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

My conclusion (it won't surprise you to learn) from this thread is precisely the opposite. In theory, DKIM is enough for DMARC (this was always true), but in practice it is not. I don't think there's evidence of a systemic weakness in the protocol. We've seen evidence of poor deployment of

Re: [dmarc-ietf] DMARC and Data Hygiene

ence (some mixture of DKIM, SPF, > and fcDNS) or blind faith. "Positive assertions" are intrinsic to what > we are doing. Without them, we have only blind faith. > > Doug Foster. > > On Tue, Jun 20, 2023, 1:29 PM Dotzero wrote: > > On Tue, Jun 20, 2023 at 11

Re: [dmarc-ietf] DMARC and Data Hygiene

On Wednesday, June 21, 2023 2:41:35 AM EDT 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 i

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

On June 20, 2023 4:33:48 PM UTC, John Levine wrote: >It appears that Tobias Herkula said: >>-=-=-=-=-=- >>Sadly they can’t, there are Mailbox Providers that expect SPF Records, so to >>maintain deliverability to those, you have to keep SPF >>records in place and can’t switch to an DKIM only D

[dmarc-ietf] DMARC and Data Hygiene

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 solved much. The next logical step will be to get rid of DKIM.

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

On Tuesday, June 13, 2023 5:33:50 PM EDT Tero Kivinen wrote: > Barry Leiba writes: > > > DKIM only: ~99.5% > > > DKIM + SPF: ~100% > > > SPF only: ~100% > > > > That's interesting and disturbing if it remains consistent. > > The statistics I have are quite different. The failure rate is much > bi

Re: [dmarc-ietf] PSD flag vs Version bump

On June 10, 2023 9:04:57 PM UTC, John Levine wrote: >It appears that Scott Kitterman said: >> >>What's the incentive that any existing DMARC users (senders or receivers) >>would have to invest additional resources in another email >>authentication protoco

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

>(I had a network engineer recently tell me that DNS packets *MUST* be no >larger than 512 bytes - and EDNS0 was 1999?) > >tim > >On Sat, Jun 10, 2023 at 3:03 PM Scott Kitterman >wrote: > >> >> >> On June 8, 2023 12:58:51 PM UTC, Tobias Herkula > 401

[dmarc-ietf] Version bump: was DMARC2 & SPF Dependency Removal

On June 8, 2023 12:58:51 PM UTC, Tobias Herkula wrote: ... > >However, such a fundamental shift in the protocol's architecture warrants a >clear signifier. I suggest we upgrade our DMARC version string from the >current state to 'DMARC2.' This upgrade would not only denote the change of >S

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

On Friday, June 9, 2023 4:33:54 AM EDT Barry Leiba wrote: > I think, Scott, that you and I have a fundamental disagreement that's > not resolvable, and I won't just repeat what I've already said. But a > couple of the things you said are ones I can't make sense of, so I'll > > talk about those: >

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

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 domain's SPF record. I understand that in theory, it shouldn't matt

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

On June 8, 2023 8:35:24 PM UTC, 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? > >I don't see how that ma

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

Isn't the way to say I don't use SPF for DMARC to not publish an SPF record? Scott K On June 8, 2023 3:35:38 PM UTC, Seth Blank wrote: >I’ll bring data. I think there’s a practical problem here and a class of >services that are not email-first which will break completely (ie get >immediately re

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

On June 8, 2023 2:20:44 PM UTC, "Murray S. Kucherawy" wrote: >On Thu, Jun 8, 2023 at 6:00 AM Tobias Herkula 401und1...@dmarc.ietf.org> wrote: > >> My team recently concluded an extensive study on the current use and >> performance of DMARC. We analyzed a staggering 3.2 billion emails, and the >

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

On Tuesday, May 2, 2023 9:00:54 AM EDT internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This Internet-Draft is a work item of the Domain-based Message > Authentication, Reporting & Conformance (DMARC) WG of the IETF. > >Title

Re: [dmarc-ietf] Messages from the dmarc list for the week ending Sun Apr 30 06:00:04 2023

On April 30, 2023 4:06:49 PM UTC, Hector iPhone6 wrote: > > >> On Apr 30, 2023, at 8:53 AM, Eliot Lear wrote: >> >>  >> >> >>> On 30.04.23 13:49, Hector Santos wrote: >>> What is the count based on? Is the count the amount of mail created since >>> the last date of this report which was

[dmarc-ietf] Summary: Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On Tuesday, April 25, 2023 2:27:18 PM EDT Scott Kitterman wrote: > On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > > I raised this issue in the DMARC session in Vienna, and have let it > > sit for a while so as not to derail other discussion. As we're pretty &

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On Friday, April 28, 2023 3:57:55 AM EDT Alessandro Vesely wrote: > On Fri 28/Apr/2023 05:14:16 +0200 Jesse Thompson wrote: > > On Thu, Apr 27, 2023, at 9:54 PM, Scott Kitterman wrote: > >> On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: > >>>On Thu, A

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 28, 2023 2:49:48 AM UTC, Jesse Thompson wrote: >On Thu, Apr 27, 2023, at 9:40 PM, Jesse Thompson wrote: >> On Thu, Apr 27, 2023, at 10:44 AM, Alessandro Vesely wrote: >>> Also, state that serious consideration includes testing p=quarantine; >>> pct=0^H t=y. >> >> I was going to say s

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 28, 2023 2:25:57 AM UTC, Jesse Thompson wrote: >On Thu, Apr 27, 2023, at 9:30 AM, Brotman, Alex wrote: >> Attempt to make it a tad more concise (I think), altering some of the >> language: >> >> - >> There can be inherent damage to the ability to use certain SMTP-

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 27, 2023 4:02:32 PM UTC, Alessandro Vesely wrote: >On Wed 26/Apr/2023 13:21:33 +0200 Scott Kitterman wrote: >> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: >>> On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: >>>> My recollection

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

On April 27, 2023 3:36:29 PM UTC, Alessandro Vesely wrote: >On Thu 27/Apr/2023 16:11:17 +0200 Brotman, Alex wrote: >> In summary: >> >> “Report senders SHOULD attempt delivery via SMTP using STARTTLS to all >> receivers.  Transmitting these reports via a secured session is preferrable.” >> >>

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

chanism. > >Restored in some useful place? > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >> -----Original Message- >> From: dmarc On Behalf Of Scott Kitterman >> Sent: Thursday, April 27, 2023 10:26 AM >> To: dmarc@iet

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

TLS. > > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >From: dmarc On Behalf Of Hector Santos >Sent: Wednesday, April 26, 2023 4:29 PM >To: Scott Kitterman >Cc: IETF DMARC WG >Subject: Re: [dmarc-ietf] I-D Action: >draft-

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 27, 2023 2:32:49 AM UTC, Jim Fenton wrote: >On 26 Apr 2023, at 9:06, John Levine wrote: > >> It seems to me there are two somewhat different kinds of DMARC damange >> that we might separate. One is what happens on discussion lists, where >> messages get lost and in the process unrelated

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 26, 2023 9:39:08 PM UTC, Jesse Thompson wrote: >On Wed, Apr 26, 2023, at 11:06 AM, John Levine wrote: >> It appears that Scott Kitterman said: >> >>Domains owners who have users who individually request 3rd parties to emit >> >>mail as an address w

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 26, 2023 9:52:29 PM UTC, Jesse Thompson wrote: >On Wed, Apr 26, 2023, at 6:21 AM, Scott Kitterman wrote: >> >> >> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: >> >On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: >>

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

On April 26, 2023 7:22:55 PM UTC, "Matthäus Wander" wrote: >Scott Kitterman wrote on 2023-04-26 21:05: >> I think if a non-encrypted transport is used there's a privacy issue with >> sending the report. I think that's one approach. >> >> Cur

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

On April 26, 2023 6:49:32 PM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>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 o

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 26, 2023 3:24:58 PM UTC, Hector Santos wrote: > > >On 4/26/2023 7:21 AM, Scott Kitterman wrote: >> On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: >>> On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: >>>> My recollection

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

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 okay. I think it's better to have the SHOULD, but I could liv

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 26, 2023 8:08:39 AM UTC, Alessandro Vesely wrote: >On Tue 25/Apr/2023 20:27:18 +0200 Scott Kitterman wrote: >> My recollection is that a general formulation that I proposed had at least >> some traction out of both groups: >> >>> [some appropriate

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 26, 2023 2:50:16 AM UTC, Hector Santos wrote: >On 4/25/2023 10:06 PM, Scott Kitterman wrote: >> On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote: >>> On 4/25/2023 9:06 PM, John Levine wrote: >>>> PS: If anyone was going to suggest we just tell p

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 26, 2023 2:23:52 AM UTC, Jesse Thompson wrote: >On Tue, Apr 25, 2023, at 8:06 PM, John Levine wrote: >> It appears that Scott Kitterman said: >> >My recollection is that a general formulation that I proposed had at least >> >some traction out of bo

Re: [dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On April 26, 2023 1:47:14 AM UTC, Hector Santos wrote: >On 4/25/2023 9:06 PM, John Levine wrote: >> It appears that Scott Kitterman said: >>> My recollection is that a general formulation that I proposed had at least >>> some traction out of both groups:

[dmarc-ietf] Search for some consensus, was: Proposed text for p=reject and indirect mail flows

On Tuesday, March 28, 2023 4:15:04 AM EDT Barry Leiba wrote: > I raised this issue in the DMARC session in Vienna, and have let it > sit for a while so as not to derail other discussion. As we're pretty > close to finished with the DMARCbis document, I'd like to raise it > again, this time with sp

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

some receivers to decline >to send reports. > >Otherwise, I'll remove 6.3. > >-- >Alex Brotman >Sr. Engineer, Anti-Abuse & Messaging Policy >Comcast > >> -Original Message- >> From: dmarc On Behalf Of Scott Kitterman >> Sent: Tuesday, April 25, 202

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

On April 25, 2023 5:31:41 PM UTC, Benny Pedersen wrote: >John R. Levine skrev den 2023-04-25 18:28: Since the only mechanism is mail and nobody's going to S/MIME encrypt their reports, I suggest just deleting it. >>> >>> TLS vs not TLS. >> >> I suppose, but that's not up to the repo

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

there is no privacy violation. You violate privacy when you >collect personal data of (several) people *different from yourself*. > >Best >Ale > > >On Tue 25/Apr/2023 18:36:34 +0200 Scott Kitterman wrote: >> My suggestion is delete all of it. It's accurate for som

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

My suggestion is delete all of it. It's accurate for some cases, not for others. If you want to keep any of it, I think it needs to be properly caveated. I expect that would be a Sisyphean task that's not worth the effort. Scott K On April 25, 2023 2:54:46 PM UTC, "Brotman, Alex" wrote: >>

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

Thanks, I think this is an improvement over the last version. Scott K On Monday, April 24, 2023 7:41:45 PM EDT Brotman, Alex 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 th

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

On April 21, 2023 3:57:54 PM UTC, Alessandro Vesely wrote: >On Fri 21/Apr/2023 05:41:03 +0200 Scott Kitterman wrote: >> On April 20, 2023 4:18:08 PM UTC, Dotzero wrote: >>> On Thu, Apr 20, 2023 at 11:38 AM John Levine wrote: >>>> It appears that Alessandro Vese

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

On April 20, 2023 4:18:08 PM UTC, Dotzero wrote: >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

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

On April 19, 2023 1:37:25 PM UTC, Laura Atkins wrote: > > >> On 19 Apr 2023, at 14:20, John Levine wrote: >> >> It appears that Jesse Thompson said: >>> -=-=-=-=-=- >>> >>> On Mon, Apr 17, 2023, at 8:37 AM, Laura Atkins wrote: Should the IETF make the interoperability recommendation th

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

On April 18, 2023 10:25:00 PM UTC, Jim Fenton wrote: >On 9 Apr 2023, at 11:33, Barry Leiba wrote: > >> There is an alternative, though: we can acknowledge that because of how >> those deploying DMARC view their needs over interoperability, DMARC is not >> appropriate as an IETF standard, and we

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

On April 18, 2023 10:00:45 PM UTC, Jim Fenton wrote: >On 9 Apr 2023, at 0:50, Murray S. Kucherawy wrote: > >> (Note, here, that Barry has in his proposed text limited the constraint to >> those types of deployments where the damage is likely. I concur. DMARC, >> as currently defined, works jus

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

On Monday, April 17, 2023 9:37:55 AM EDT Laura Atkins wrote: > > On 17 Apr 2023, at 14:15, Scott Kitterman wrote: > > > > On Monday, April 17, 2023 4:29:45 AM EDT Laura Atkins wrote: > >> Reading through the various discussions about how to document the harm > >&

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

On Monday, April 17, 2023 4:29:45 AM EDT 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 > custome

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

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 goal is working towards consensus is to find something we can >> live with, so that's exactly what I was hoping

Re: [dmarc-ietf] list history, Signaling MLMs

On April 15, 2023 8:17:41 PM UTC, John R Levine wrote: >> I'm assuming that the "long list of stinky possible workarounds" are the >> existing "whatever" mitigations, and rewriting seems to be acceptable enough >> as a mitigation to convince large [enterprise] mail systems to move forward >>

Re: [dmarc-ietf] Signaling MLMs

On Saturday, April 15, 2023 11:45:34 AM EDT Alessandro Vesely wrote: > On Sat 15/Apr/2023 16:42:32 +0200 Scott Kitterman wrote: > > On April 15, 2023 1:55:59 PM UTC, Jesse Thompson wrote: > >>And the "If a mailing list would like to provide the best customer > &

Re: [dmarc-ietf] Signaling MLMs

On April 15, 2023 1:55:59 PM UTC, 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 S

Re: [dmarc-ietf] Signaling MLMs

On April 15, 2023 12:26:16 PM UTC, Laura Atkins wrote: >On Apr 15, 2023, at 4:25 AM, Scott Kitterman wrote: ... >> Or [person] gets a Gmail account for his IETF work and doesn't bother >> tilting at >> windmills. > >That solution only works until gmail publi

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

nd > workarounds. > > If I'm being honest, given the different versions put forth so far, it > seems like this type of language is closer to the compromise on the > interoperability statement. The other versions say relatively the same > thing. > > - Mark Alley > >

Re: [dmarc-ietf] Signaling MLMs

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 the ability to participate in a list due > > to its policies seems to me like it puts this customer service problem > > where it belongs

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

On Friday, April 14, 2023 5:54:06 PM EDT Dotzero wrote: > Barry wrote: > > " The idea is MUST NOT because it harms interop with long-standing > deployments. If you decide you're more important than that, you do > what you want and there it is. It's as simple as that" > > I could live with the n

Re: [dmarc-ietf] Signaling MLMs

On Friday, April 14, 2023 1:20:28 PM EDT Alessandro Vesely wrote: > On Fri 14/Apr/2023 15:47:12 +0200 Scott Kitterman wrote: > > On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" wrote: > >> On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely wrote: > >&g

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

On Friday, April 14, 2023 1:38:42 PM EDT Alessandro Vesely wrote: > On Wed 12/Apr/2023 13:41:16 +0200 Laura Atkins wrote: > >> On 12 Apr 2023, at 12:21, Douglas Foster > >> wrote: > >> > >> Any form of security creates inconvenience. > > > > Yes. And we make tradeoffs between that. In this case,

Re: [dmarc-ietf] Signaling MLMs

On April 14, 2023 1:29:58 PM UTC, "Murray S. Kucherawy" wrote: >On Fri, Apr 14, 2023 at 4:31 AM Alessandro Vesely wrote: > >> Heck, MLMs should start rejecting messages sent from domains that publish >> a >> blocking policy *when they fail authentication on entry*!! >> > >That's not enough to

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

On April 13, 2023 5:49:30 PM UTC, "Brotman, Alex" wrote: >> That's the sort of thing I proposed, and which some participants here are >> objecting to. I continue not to understand the objection to clear language >> that >> says that if you do under conditions, it will cause problems, >> so

Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

On April 12, 2023 9:51:14 AM UTC, Alessandro Vesely wrote: >On Wed 12/Apr/2023 10:35:06 +0200 Scott Kitterman wrote: >> >> >> On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely wrote: >>> On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote: >&g

Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

On April 12, 2023 7:27:12 AM UTC, Alessandro Vesely wrote: >On Fri 07/Apr/2023 00:03:49 +0200 Scott Kitterman wrote: >> On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote: >>> On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: >>>> I don't feel

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

On April 12, 2023 3:24:39 AM UTC, Neil Anuskiewicz wrote: > > >> 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. T

Re: [dmarc-ietf] Weakening of enforcement concern

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 person say that > most domains don’t need to go to p=reject. I’ve seen all sorts of domains > at

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

On April 9, 2023 6:33:54 PM UTC, Barry Leiba wrote: >> As Todd previously stated, my preference is for language that >> acknowledges the primacy of the domain owner over interoperability > >The problem is that IETF standards are about interoperability, not about >anyone’s primacy. > >There is an

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

On Sunday, April 9, 2023 3:50:46 AM EDT Murray S. Kucherawy wrote: > Emphatically "wearing no hat" here, just speaking as a long-time > participant: > > On Sat, Apr 8, 2023 at 2:13 PM Mark Alley > 40tekmarc@dmarc.ietf.org> wrote: > > Re-looking at the definition of "SHOULD NOT", I don't see

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

On Sunday, April 9, 2023 9:55:29 AM EDT John Levine wrote: > It appears that Matthäus Wander said: > >Earlier in the discussion, the term high-value domain has been used > >(along with transactional email domain) in opposition to domain for > >general-purpose email. ... > > "High value" isn't a u

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

vice > versa with p=reject, in my opinion. Is that not considered "acceptable" > by this definition's context? > > On 4/8/2023 4:10 PM, Scott Kitterman wrote: > > Possible. I didn't count. > > > > I didn't see any convergence towards an alter

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

versal consensus. Scott K On April 8, 2023 8:58:13 PM UTC, Dotzero wrote: >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

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

s and move forward on to the next thing? Scott K On Wednesday, March 29, 2023 7:42:49 PM EDT Barry Leiba wrote: > I'm happy with that suggestion. > > Barry > > On Thu, Mar 30, 2023 at 6:00 AM Scott Kitterman wrote: > > Would you feel any better if the M

Re: [dmarc-ietf] THIS IS A DISTRACTION (it might be)

On Saturday, April 8, 2023 10:24:09 AM EDT John Levine wrote: > It appears that Scott Kitterman said: > >I think you have gotten yourself side tracked. > > > >The problem with DMARC and mailing lists is that receivers doing DMARC > >checks can't (absent a

Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

On Saturday, April 8, 2023 9:49:24 AM EDT John Levine wrote: > It appears that Seth Blank said: > >So how do we handle this? What’s the worst case? Looking at the above > >example, the longest “complex org” would be 5 labels long. I think we’ve > >already agreed, backed by data from the PSL, that

Re: [dmarc-ietf] THIS IS ABUSE (it might be)

> accepting incoming messages from a list." > > > > However, this type of truthfulness does not seem to be what the charter > > document intended. > > > > Doug Foster > > > > On Fri, Apr 7, 2023 at 4:24 PM Scott Kitterman wrote: > >> On April 7

Re: [dmarc-ietf] THIS IS ABUSE (it might be)

On April 7, 2023 6:43:33 PM UTC, Alessandro Vesely wrote: >It is going to be problematic to kick off someone who impersonates different >users. What do you do, block IP numbers? > >We keep on saying that mailing list have worked this way for decades. Sure. >And email in general has been work

Re: [dmarc-ietf] Tree walk max depth concern and impact on reporting for domain owners working as expected

On April 6, 2023 5:51:50 PM UTC, Alessandro Vesely wrote: >On Thu 06/Apr/2023 00:54:15 +0200 Seth Blank wrote: >> I don't feel strongly about N=10, but I do feel strongly that N=5 is >> insufficient. My gut feel is that 6 or 7 is likely more than enough to cover >> all real world examples, bu

Re: [dmarc-ietf] THIS IS ABUSE (no it's not)

This is not a significant problem in my experience. To the extent this is a problem I think it's primarily a list owner problem, not an Internet protocol problem. Not kidding that if I ran this list I'd probably kick you off the list for awhile to give you a chance to ponder the error of your

Re: [dmarc-ietf] Proposed text to close out Ticket 96

On April 5, 2023 10:20:28 PM UTC, Seth Blank wrote: >On Wed, Apr 5, 2023 at 2:57 PM Scott Kitterman wrote: > >> My understanding is that the IETF doesn't do implementation >> specifications. I'm not sure what problem that's related to >> interoperab

<    1   2   3   4   5   6   7   8   9   10   >