[dmarc-ietf] Re: PSOs sending mail from their PSD

On May 13, 2024 2:37:01 PM UTC, Alessandro Vesely wrote: >On Mon 13/May/2024 12:53:14 +0200 Scott Kitterman wrote: >> >> >> On May 13, 2024 7:59:20 AM UTC, Alessandro Vesely wrote: >>> Hi, >>> >>> someone objected to PSDs being unable

[dmarc-ietf] Re: PSOs sending mail from their PSD

On May 13, 2024 7:59:20 AM UTC, Alessandro Vesely wrote: >Hi, > >someone objected to PSDs being unable to receive failure reports even if the >PSD is the From: domain. For example: > >_dmarc.psd.example IN TXT "p=none psd=y ruf=reports@psd.example > >In case a mail having "From:

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

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

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

On Tuesday, April 16, 2024 5:17:44 PM EDT 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] Description of 'n' value for the 'psd' tag AND/OR Clarify the Tree Walk

On Wednesday, April 17, 2024 11:41:34 AM EDT Alessandro Vesely wrote: > On Tue 16/Apr/2024 23:17:44 +0200 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

Re: [dmarc-ietf] Thoughts on choosing N

On Wednesday, April 17, 2024 9:20:10 PM EDT 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 Wednesday, April 17, 2024 9:42:23 AM EDT 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 in this cas

Re: [dmarc-ietf] Thoughts on choosing N

On Tuesday, April 16, 2024 4:55:49 PM EDT Todd Herr wrote: > On Mon, Apr 15, 2024 at 8:08 PM Douglas Foster < > > dougfoster.emailstanda...@gmail.com> wrote: > > Todd, can you clarify this? > > > > N is not concerned with maximum labels on a subdomain. We are interested > > in the maximum

Re: [dmarc-ietf] Thoughts on choosing N

On Tuesday, April 16, 2024 2:24:07 PM EDT John Levine wrote: > It appears that Scott Kitterman said: > >In the case of a.b.c.example.com and example.com is in the PSL, the DMARC > >records in a.b.c.example.com (if present) and example.com (otherwise) are > >consulted.

Re: [dmarc-ietf] Thoughts on choosing N

On April 16, 2024 2:36:53 AM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>>I'm with Scott, pick a number, 5, 8, whatever, and be done with it. >>> >>Modulo we do need to explain why 8. Related, I think we also need to explain >&g

Re: [dmarc-ietf] Thoughts on choosing N

On April 15, 2024 4:34:40 PM UTC, John Levine wrote: >It appears that Alessandro Vesely said: >>8 is not needed and not justified. A mail site using 8 labels would have >>troubles with the RFC 7489 version, which uses the PSL. They'd have to ask >>for >>PSL upgrades, right? > >No, they

Re: [dmarc-ietf] Thoughts on choosing N

On April 15, 2024 11:43:08 AM UTC, Alessandro Vesely wrote: >On Mon 15/Apr/2024 13:16:50 +0200 Douglas Foster wrote: >> Our original choice of N was based on the PSL.    The PSL could not detect >> organizational boundaries could not boundaries below level 5, because it had >> no entries

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

On April 8, 2024 1:02:53 AM UTC, Neil Anuskiewicz wrote: > > >> 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: >>>>

Re: [dmarc-ietf] the long march, WGLC editorial review of draft-ietf-dmarc-dmarcbis-30

On April 7, 2024 4:32:06 PM UTC, "John R. Levine" wrote: >On Sat, 6 Apr 2024, Scott Kitterman wrote: >> As a side effect of the switch to the tree walk approach in DMARCbis, this is >> no longer true. For any subdomain without a DMARC record, the domains above &

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

osure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > > On Sat, Apr 6, 2024 at 13:44 Scott Kitterman wrote: > > Th

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

d of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. > > On Sat, Apr 6, 2024 at 13:01 Scott Kitte

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

On Saturday, March 30, 2024 4:05:17 PM EDT Seth Blank wrote: > Section 4.6: DNS Tree Walk: > > The text is correct, but N is wrong. I've shared my notes with this list > but we never reached consensus: > https://mailarchive.ietf.org/arch/msg/dmarc/GoExCeJYWhxnvH8lwjbr7nAcFh4/ > > tl;dr: N of 5

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

On Monday, April 1, 2024 4:45:20 PM EDT Todd Herr wrote: > Greetings. > > Issue 141 has been opened to collect ideas around the discussion about what > to say in DMARCbis (if anything) about honoring SPF records that end in > -all when SPF fails. > >

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

On Sunday, March 31, 2024 3:45:31 PM EDT 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 > > >don't

Re: [dmarc-ietf] DMARCbis WGLC - Issue 144 Mention of ARC in DMARCbis

On April 1, 2024 11:05:02 PM UTC, John Levine wrote: >It appears that Todd Herr said: >>Issue 144 has been opened for the question of what to say about ARC (RFC >>8617) in the context of indirect mail flows, a la Murray's example text >>from this post

Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

On March 31, 2024 7:49:08 PM UTC, Seth Blank wrote: >On Sun, Mar 31, 2024 at 1:40 PM Scott Kitterman >wrote: > >> >> >> On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote: >> >>>> I’m probably being pedantic here: is “gov” a dom

Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

On March 31, 2024 5:32:13 PM UTC, "John R. Levine" wrote: I’m probably being pedantic here: is “gov” a domain? >>> Yup, it's a domain. >> I stand corrected on that. > >Anything that meets the DNS spec is a domain namen, e.g., argle.bargle.parp is >a domain name. If and how particular

Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

On March 30, 2024 11:27:42 PM UTC, "Murray S. Kucherawy" wrote: >On only the charter point: > >On Sat, Mar 30, 2024 at 2:27 PM Jim Fenton wrote: > >> >> >> ??? Not Found >> >> - >> >> >> >> I expected to find some text at least recommending a rewriting strategy >> for From

Re: [dmarc-ietf] WGLC review of draft-ietf-dmarc-dmarcbis-30

On March 31, 2024 3:20:41 PM UTC, Jim Fenton wrote: > > >On 30 Mar 2024, at 17:22, John R. Levine wrote: > > Entities other than domains: Public suffixes aren’t (necessarily) domains, Of course they're domains. What else could they be? The things that are out of scope are

Re: [dmarc-ietf] no DMARC result for DKIM testing and policy

On March 22, 2024 2:52:28 AM UTC, John Levine wrote: >According to Mark Alley : >>> I don't feel particularly strongly about this, but I can see people >>> thinking there's some correlation between DKIM testing and DMARC >>testing. It's not completely illogical, so it might be better to be

Re: [dmarc-ietf] DMARC result for DKIM testing and policy

On March 21, 2024 11:39:35 PM UTC, "Murray S. Kucherawy" wrote: >On Fri, Mar 22, 2024 at 12:59 AM Scott Kitterman >wrote: > >> >> For t=y, DKIM says: >> >> >> >>y This domain is testing DKIM. Verifiers MUST NOT treat &

Re: [dmarc-ietf] DMARC result for DKIM testing and policy

On March 21, 2024 2:15:00 PM UTC, Todd Herr wrote: >On Thu, Mar 21, 2024 at 5:55 AM Alessandro Vesely wrote: > >> On Wed 20/Mar/2024 23:11:20 +0100 Matthäus Wander wrote: >> > Alessandro Vesely wrote on 2024-03-20 15:42: >> >> what is the result of DMARC on having, say >> >> >> >>

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

On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote: > On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote: > > On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote: > >>On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: > >>> On Mon, Mar 18,

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

On March 18, 2024 6:53:29 PM UTC, John R Levine wrote: >On Mon, 18 Mar 2024, Alessandro Vesely wrote: >> The text should be terser and clearer, possibly with an example. > >I would be happy to remove the whole thing, since it's only distantly related >to defining or implementing DMARC. I

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

On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely wrote: >On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote: >> 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

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

On March 18, 2024 3:15:42 AM UTC, "Murray S. Kucherawy" wrote: >On Mon, Mar 18, 2024 at 1:08 PM Dotzero wrote: > >> >> Add this to 11.1 Authentication Methods >>> >>> >>> Both of the email authentication methods that underlie DMARC provide >>> some assurance that an email was transmitted by

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

On March 18, 2024 1:36:29 AM UTC, 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] DMARCbis WGLC - Issue 135 - What To Say About Too-Permissive/Third-Party SPF and Where To Say It?

On March 17, 2024 11:11:04 AM UTC, Alessandro Vesely wrote: >On Sat 16/Mar/2024 20:01:22 +0100 Scott Kitterman wrote: >> On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote: >>> On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: >>&g

Re: [dmarc-ietf] Working Group Last Call on draft-ietf-dmarc-dmarcbis-30

On Wednesday, February 28, 2024 7:37:30 PM EDT Barry Leiba wrote: > The editors and chairs think version -30 resolves the open issues and is > ready for a final look, so this message starts a working group last call > for the DMARCbis spec. Because of the upcoming IETF 119 meeting, we’ll let >

[dmarc-ietf] DMARCbis WGLC Issue - Section 11.5

Not sure if this is "significant" or not. I don't particularly like the title, but that's been that way for quite some time, so for WGLC, meh. The particular concern I have is with the text that was added right before WGLC about multi-valued RFC5322.From fields. It includes the statement: >

Re: [dmarc-ietf] DMARCbis WGLC Issue - Clarify When Tree Walk Starts?

On Thursday, March 7, 2024 8:55:55 AM EDT Todd Herr wrote: > On Thu, Mar 7, 2024 at 5:08 AM Alessandro Vesely wrote: > > On 06/03/2024 21:00, Todd Herr wrote: > > > Section 4.7, DMARC Policy Discovery, starts with the following sentence: > > > For policy discovery, a DNS Tree Walk starts at

Re: [dmarc-ietf] The description of psd=n

On Wednesday, March 6, 2024 6:04:01 AM EDT Alessandro Vesely wrote: > On 05/03/2024 21:47, Scott Kitterman wrote: > > On March 5, 2024 8:10:46 PM UTC, Todd Herr wrote: > >> On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman wrote: > >>> On March 5, 2024 2:4

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

On Thursday, March 14, 2024 12:24:50 PM EDT Scott Kitterman wrote: > On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: > > Colleagues, > > > > Issue 135 is open for the subject topic. Please add your thoughts to this > > thread and/or to the issue in

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

On Saturday, March 16, 2024 4:52:54 AM EDT Tero Kivinen wrote: > John Levine writes: > > It appears that Todd Herr said: > > >I agree that clarifying it can't hurt, obviously, ... > > > > I disagree, it does hurt. > > > > If we say you're allowed to use CNAMEs to point to DMARC records, > >

Re: [dmarc-ietf] DMARC exceptions

On Friday, March 15, 2024 10:15:55 AM EDT Todd Herr wrote: > On Fri, Mar 15, 2024 at 1:47 AM Douglas Foster < > > dougfoster.emailstanda...@gmail.com> wrote: > > DMARC is an imperfect tool, as evidenced by the mailing list problem, > > among others. DMARCbis has failed to integrate RFC7489 with

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

On March 14, 2024 8:38:17 PM UTC, Todd Herr wrote: >On Thu, Mar 14, 2024 at 4:34 PM Scott Kitterman >wrote: > >> >> I think this is correct. I think it's obviously enough correct that I'm >> surprised anyone was confused. >> >> Do we know what

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

On March 14, 2024 8:18:31 PM UTC, Todd Herr wrote: >Colleagues, > >There was a discussion among M3AAWG members on March 13 that centered on >the question of whether DMARC records can be published in DNS as CNAMEs, >e.g., > >_dmarc.example.com IN CNAME _dmarc.example.org > >_dmarc.example.org

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thursday, March 14, 2024 1:59:58 PM EDT Alessandro Vesely wrote: > On Thu 14/Mar/2024 18:35:05 +0100 Scott Kitterman wrote: > > On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote: > >> On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote: > >>> [...]

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thursday, March 14, 2024 11:27:03 AM EDT Alessandro Vesely wrote: > On Thu 14/Mar/2024 15:09:37 +0100 Todd Herr wrote: > > [...] > > > > In the ticket, I propose the following replacement text: > > > > == > > Because DMARC relies on SPF

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

On Thursday, March 14, 2024 11:44:22 AM EDT Todd Herr wrote: > Colleagues, > > Issue 135 is open for the subject topic. Please add your thoughts to this > thread and/or to the issue in Github. > > Thank you. I'd suggest we discuss where to say it first. I think the right place is security

Re: [dmarc-ietf] DMARCbis WGLC Issue 132 - 5.5.1 and 5.5.2 SHOULD vs MUST (was Another point for SPF advice)

On Thursday, March 14, 2024 10:09:37 AM EDT Todd Herr wrote: > Colleagues, > > After reviewing the "Another point SPF advice" thread and Murray's separate > post re: SHOULD vs. MUST, I have opened issue 132 on the topic: > > The current text of section 5.5.1, Publish and SPF Policy for an

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

On March 12, 2024 11:42:11 PM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send >>mail for anything other than their own domains. ESP customers, don't use >>ESPs that do t

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

On March 12, 2024 5:37:47 PM UTC, Richard Clayton wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >In message , Scott >Kitterman writes > >>Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send >>mail for anything other than the

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

Or, as RFC 4408 and RFC 7208 warn against, ESPs don't allow customers to send mail for anything other than their own domains. ESP customers, don't use ESPs that do this. Scott K On March 12, 2024 4:05:15 PM UTC, Dotzero wrote: >Neil, SPF essentially deals with hosts and IP address ranges.

Re: [dmarc-ietf] The description of psd=n

On March 5, 2024 8:10:46 PM UTC, Todd Herr wrote: >On Tue, Mar 5, 2024 at 1:30 PM Scott Kitterman wrote: > >> >> >> On March 5, 2024 2:47:47 PM UTC, Todd Herr > 40valimail@dmarc.ietf.org> wrote: >> >On Tue, Mar 5, 2024 at 6:12 AM

Re: [dmarc-ietf] The description of psd=n

On March 5, 2024 2:47:47 PM UTC, Todd Herr wrote: >On Tue, Mar 5, 2024 at 6:12 AM Alessandro Vesely wrote: > >> Hi, >> >> Section 5.3, in the format description of psd: >> >>n: The DMARC policy record is published for a PSD, but it is the >> Organizational Domain for itself

Re: [dmarc-ietf] Another point for SPF advice

On March 5, 2024 3:46:39 PM UTC, Alessandro Vesely wrote: >Todd Herr writes: >> On Tue, Mar 5, 2024 at 9:30 AM Alessandro Vesely wrote: >> >>> in section 5.5.1, Publish an SPF Policy for an Aligned Domain, the last >>> sentence says: >>> >>> The SPF record

Re: [dmarc-ietf] A possible point for SPF advice

On March 5, 2024 2:54:10 PM UTC, Todd Herr wrote: >On Mon, Mar 4, 2024 at 6:30 AM Alessandro Vesely wrote: > >> Hi, >> >> Section 5 has a paragraph that can fit Scott's solution to SPF spoofing. >> Here's a possible change: >> >> OLD >> A Domain Owner or PSO may choose not to participate

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

which was a mistake he wants to fix transparently. > >On Thu, Feb 29, 2024 at 4:04 PM Scott Kitterman >wrote: > >> I think it ought to be resolved by the same AD that made the consensus >> call. >> >> Scott K >> >> On February 29, 2024 8:58:21 PM UTC, Dotze

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

pefully the chairs will rule on this so we don't have a previous issue >reopened during last call. > >Michael Hammer > >On Thu, Feb 29, 2024 at 2:53 PM Seth Blank 40valimail@dmarc.ietf.org> wrote: > >> I thought we landed on SHOULD NOT, there was strong resistance to MUST

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

:10 PM UTC, Seth Blank wrote: >I thought we landed on SHOULD NOT, there was strong resistance to MUST NOT > >On Thu, Feb 29, 2024 at 2:48 PM Scott Kitterman >wrote: > >> Okay. I think 8.6 is the one in error. You see how this is going to go, >> right? >> >&g

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

my part when the new text in 8.6 was published, and I just want to >confirm that 7.6 is indeed wrong. > >On Thu, Feb 29, 2024 at 2:10 PM Scott Kitterman >wrote: > >> In what way is this a new issue that has not already been argued to death >> in the WG? I think for WGLC, we'

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

In what way is this a new issue that has not already been argued to death in the WG? I think for WGLC, we've already done this. We will, no doubt get to have this conversation during the IETF last call, but for the working group, this strikes me as exactly the type of relitigation of issues

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

On February 29, 2024 6:15:37 PM UTC, Benny Pedersen wrote: >Douglas Foster skrev den 2024-02-29 18:48: >> I am surprised at the lack of feedback about Barry's research link. >> It is a devastating attack on our ability to trust SPF when shared >> infrastructure is involved. As a result of

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

On Thursday, February 29, 2024 9:04:03 AM EST Todd Herr wrote: > On Wed, Feb 28, 2024 at 6:27 PM Douglas Foster < > > dougfoster.emailstanda...@gmail.com> wrote: > > I interpret your data differently. These domains collected data until it > > was clear that they could safely move to

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

Looks good to me. Are we there yet? Scott K On February 28, 2024 11:09:24 PM UTC, Todd Herr wrote: >Summary of changes from rev -29... > > 1. Removed mention of "XML" from Section 5.5.3, Setup a Mailbox to > Receive Aggregate Reports. This is future-proofing against any format > changes

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

On Saturday, February 10, 2024 7:39:37 PM EST Murray S. Kucherawy wrote: > On Sat, Feb 10, 2024 at 12:34 PM Jim Fenton wrote: > > > No, it's perfectly fine to declare that DMARC only applies to certain > > > classes of messages. > > > > This actually concerns me a bit. If having multiple From:

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

On Saturday, January 27, 2024 8:00:24 AM EST Alessandro Vesely wrote: > On Fri 19/Jan/2024 18:00:35 +0100 Hector Santos wrote: > >> On Jan 19, 2024, at 10:19 AM, Todd Herr > >> wrote: > >> > >> Perhaps the way forward for DMARC is to look for a Sender header when > >> there is more than one

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

On January 15, 2024 4:49:10 PM UTC, Alessandro Vesely wrote: >On 11/01/2024 18:15, Todd Herr wrote: >> On Thu, Jan 11, 2024 at 11:51 AM Damien Alexandre wrote: >> >>> https://datatracker.ietf.org/doc/html/rfc7489#section-6.6.1 >>> >>> "The case of a syntactically valid multi-valued

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

Thanks. I think we will come to regret the decision to privilege DKIM over SPF in this section. For the moment, it's not wrong, but I think the moment will be fairly transitory. Scott K On Tuesday, January 2, 2024 3:12:09 PM EST Todd Herr wrote: > Revision 28 was due to expire this weekend,

Re: [dmarc-ietf] Dmarcbis way forward

;say? > >> On Oct 23, 2023, at 9:07 PM, Scott Kitterman wrote: >> >> On Monday, October 23, 2023 4:03:36 AM EDT Francesca Palombini wrote: >>> I have been asked by Murray to assist with a consensus evaluation on the >>> discussion that has been going on fo

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

On Saturday, October 28, 2023 4:03:30 PM EDT Emanuel Schorsch wrote: > > As to why, I don't think there's a valid use case and the proponents for > > this haven't really thought it through. As an example, someone (I don't > > recall who) cited the issue of domain owners that publish SPF, but

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

On October 28, 2023 5:38:00 PM UTC, 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

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

On Saturday, October 28, 2023 11:26:40 AM EDT Richard Clayton wrote: > In message <3316620.Pp0j0xxFaF@localhost>, Scott Kitterman > writes > > >What's your plan for when easily getting a DMARC pass due to bad SPF > >records doesn't work anymore, so the bad guy

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

On Saturday, October 28, 2023 10:51:27 AM EDT Scott Kitterman wrote: > >Even if we don't add the feature, we should address the vulnerability. Currently there is only a bullet in Section 4.8, Organizational Domain Discovery, saying: > > * The domain found in the RFC5321.Mai

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

On Saturday, October 28, 2023 10:49:46 AM EDT Richard Clayton wrote: > In message <6bb2871c-da84-42ad-bae1-7b4828b0f...@tana.it>, Alessandro > Vesely writes > > >On Fri 27/Oct/2023 20:06:46 +0200 Scott Kitterman wrote: > >> On October 27, 2023 5:54:03 PM

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

On October 28, 2023 12:01:05 PM UTC, 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: >>>> >>>&g

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

On October 27, 2023 5:54:03 PM UTC, Alessandro Vesely wrote: >On Fri 27/Oct/2023 12:34:11 +0200 John Levine wrote: >> It appears that Scott Kitterman said: >>>> That is unfortunately true, but if we could decouple the DMARC from SPF, >>>> then at least w

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

On October 26, 2023 9:46:04 PM UTC, Tero Kivinen wrote: >John Levine writes: >> It appears that Scott Kitterman said: >> >>* Is there consensus on moving ahead with the idea of a way to indicate >> >>which authentication method(s) the Domain Owner wa

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

On Wednesday, October 25, 2023 11:01:27 AM EDT Richard Clayton wrote: > In message , Scott > Kitterman writes > > >>> My reading of the discussion is: > >>> > >>> 1. We did not have rough consensus to eliminate the use of SPF in DMARC. > >

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

On Wednesday, October 25, 2023 10:46:09 AM EDT Emanuel Schorsch wrote: > > >There's the counterargument "so don't publish SPF" but it's on so many > > > > checklists > > > > >that even though that would be a fine idea, it's not practical. > > > > Diving into the SPF angle, if someone has a

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

On October 25, 2023 1:37:55 PM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>>* 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 does

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

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) the Domain Owner wants Receivers to use? If so, it doesn't

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

On October 25, 2023 3:38:01 AM UTC, "Murray S. Kucherawy" wrote: >On Tue, Oct 24, 2023 at 11:15 AM 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)

Re: [dmarc-ietf] Dmarcbis way forward

On October 24, 2023 3:38:54 PM UTC, "Murray S. Kucherawy" wrote: >On Mon, Oct 23, 2023 at 9:07 PM Scott Kitterman >wrote: > >> I don't think this is consistent with the IETF's mandate to provide >> documents >> which promote interoperability. I do

Re: [dmarc-ietf] Dmarcbis way forward

On Monday, October 23, 2023 4:03:36 AM EDT 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 about the dmarcbis document > and how to move forward. > > I have made an attempt to evaluate consensus

Re: [dmarc-ietf] Tree Walk impact

On October 17, 2023 5:56:47 PM UTC, Alessandro Vesely wrote: >On Tue 17/Oct/2023 14:03:40 +0200 Scott Kitterman wrote: >> On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely wrote: >>> On Mon 16/Oct/2023 20:00:00 +0200 Scott Kitterman wrote: >>>> On O

Re: [dmarc-ietf] Tree Walk impact

On October 17, 2023 7:32:22 AM UTC, Alessandro Vesely wrote: >On Mon 16/Oct/2023 20:00:00 +0200 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: &g

Re: [dmarc-ietf] Tree Walk impact

On October 16, 2023 9:20:26 PM UTC, Neil Anuskiewicz wrote: > > >> 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/202

Re: [dmarc-ietf] Tree Walk impact

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 transition away from >> the PSL. It has the feel of a throwback to a time when people thought the >> number of

Re: [dmarc-ietf] Tree Walk impact

ic, and consequently we can be >certain of heuristic-induced harm. We should give domain owners full >control over their organizational boundary, and stop guessing. > >Doug Foster > > > > > >On Mon, Oct 9, 2023 at 9:00 AM Scott Kitterman wrote: > >> Where does it sa

Re: [dmarc-ietf] Tree Walk impact

Where does it say to stop at the first policy found? Scott K On October 9, 2023 12:51:33 PM UTC, Douglas Foster wrote: >Right, but we walk up from both domains separately, and each walk stops at >the first policy found. Since the two walks stop at different policies, >they are presuned to be

Re: [dmarc-ietf] Policy Enforcement Considerations

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 > in [RFC7960] and in Section 8.6 of this document, it is important > that

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

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

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

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

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

On August 7, 2023 7:47:03 PM UTC, "Murray S. Kucherawy" wrote: >On Sat, Aug 5, 2023 at 1:09 PM Tim Wicinski wrote: > >> Based on the ABNF in -28, how about something like this: >> >> >> dmarc-method = "dkim" / "spf" >> >> dmarc-auth = "auth" equals dmarc-method *(*WSP "," *WSP dmarc-method)

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

it's feasible with DKIM too. The RFC should ask forwarders to >do this review when they p=reject downgrade otherwise it does add systemic >risk to the DMARC protected From identity. > >-Wei > >On Sun, Aug 6, 2023 at 11:38 AM Scott Kitterman >wrote: > >> On

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

On Sunday, August 6, 2023 2:10:35 PM EDT Hector Santos wrote: > > On Aug 5, 2023, at 5:37 PM, Scott Kitterman wrote: > > > > On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote: > >> It appears that Scott Kitterman said: > >>>> When receivers

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

On August 6, 2023 11:02:04 AM UTC, Alessandro Vesely wrote: >On Sat 05/Aug/2023 21:37:31 +0000 Scott Kitterman wrote: >> On Saturday, August 5, 2023 3:59:02 PM EDT John Levine wrote: >>> It appears that Scott Kitterman said: >>>>> When receivers apply the

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

On Saturday, August 5, 2023 7:38:21 PM EDT Dave Crocker wrote: > On 8/5/2023 4:23 PM, Neil wrote: > > > The language used for DMARC has always been problematic. "Policy" > > > > > > implies control, but the domain owner has no control over the receiving > > > platform. Quarantine and Reject

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"

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

  1   2   3   4   5   6   7   8   9   >