Re: [dmarc-ietf] What is a policy domain? an org domain? How do we not break existing DMARC?

Which has nothing to do with what is a policy domain, an org domain, or how not to break existing DMARC. As I suggested earlier, we can decide what to call the tags independent of the policy lookup and org domain determination. I think we have those things resolved, modulo me having time to wr

Re: [dmarc-ietf] What is a policy domain? an org domain?

> On Fri, Feb 25, 2022 at 5:42 AM Alessandro Vesely wrote: > > On Thu 24/Feb/2022 18:15:57 +0100 Scott Kitterman wrote: > > >> I don't know why you dismiss possible enhancements as if psd=y were > > > > already > > > > >> standard. Of

Re: [dmarc-ietf] What is a policy domain? an org domain?

On Thursday, February 24, 2022 12:46:13 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >> 1. Take your domain, chop it to the last five labels if it's longer than > >> that. > >> > >> 2. Walk up the tree starting at the origin

Re: [dmarc-ietf] What is a policy domain? an org domain?

On Thursday, February 24, 2022 3:36:18 AM EST Alessandro Vesely wrote: > On Wed 23/Feb/2022 19:55:35 +0100 Scott Kitterman wrote: > > On Wednesday, February 23, 2022 1:25:50 PM EST John Levine wrote: > >> It appears that Scott Kitterman said: > >>>Leaving

Re: [dmarc-ietf] What is a policy domain? an org domain?

On Thursday, February 24, 2022 11:45:18 AM EST John Levine wrote: > It appears that Scott Kitterman said: > >We are, but I think it's needed. I think we are in reasonably good shape > >for backward compatibility. I still have a preference for org is last > >no

Re: [dmarc-ietf] What is a policy domain? an org domain?

On Wednesday, February 23, 2022 8:16:24 PM EST John Levine wrote: > It appears that John Levine said: > >It appears that Scott Kitterman said: > >>If we did first match, but allowed for relaxed alignment for org domains > >>also when one is a subdomain of the othe

Re: [dmarc-ietf] What is a policy domain? an org domain?

On Wednesday, February 23, 2022 4:45:35 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >> I prefer the first (longest) but could live with the last if people think > >> that will in practice be less surprising. I do worry about foo.us.com vs > >&

Re: [dmarc-ietf] What is a policy domain? an org domain?

On Wednesday, February 23, 2022 1:25:50 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >Leaving that aside, then I think it's: > > > >1. Lookup DMARC record for the 5322.From domain. If found, that's the > >policy. > > &g

Re: [dmarc-ietf] What is a policy domain? an org domain?

On Wednesday, February 23, 2022 12:05:43 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >> It looked like the tree walk to find the policy domain was different from > >> the one to find the org domain. If they're the same, that makes things >

Re: [dmarc-ietf] Let's Work on the Tree Walk Text

No. Please explain why you think I'm proposing that? I'm reasonably confident I haven't. Scott k On Wednesday, February 23, 2022 7:10:37 AM EST Douglas Foster wrote: > Do you propose that we ignore private registrars completely? > > Doug > > On Tue, Feb 22, 20

Re: [dmarc-ietf] Let's Work on the Tree Walk Text

On Wednesday, February 23, 2022 6:33:22 AM EST Alessandro Vesely wrote: > On Wed 23/Feb/2022 05:09:19 +0100 Scott Kitterman wrote: > > On Monday, February 21, 2022 6:45:09 PM EST John Levine wrote: > >> It appears that Scott Kitterman said: > >>>Today,

Re: [dmarc-ietf] Let's Work on the Tree Walk Text

On Monday, February 21, 2022 6:45:09 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >Today, if I send mail from 5322.From example.kitterman.com that is signed > >by dkim.kitterman.com, if example.kitterman.com has a DMARC record, then > >that would be t

Re: [dmarc-ietf] Let's Work on the Tree Walk Text

On Monday, February 21, 2022 1:07:15 PM EST John Levine wrote: ... > >If us.com had published a DMARC record with psd=y, then we would know for > >sure that cust.us.com is the org domain. I think when walking up you want > >the first record for policy domain and the last non-PSD record for org > >

Re: [dmarc-ietf] Let's Work on the Tree Walk Text

On Wednesday, February 16, 2022 6:52:42 PM EST John Levine wrote: > > 5. > > > > Count the number of labels found in the subject DNS domain. Let that > > number be "x". If x < 5, remove the left-most (highest-numbered) label > > from > > the subject domain. If x >= 5, remove the left-most (highest

Re: [dmarc-ietf] Let's Work on the Tree Walk Text

On Saturday, February 19, 2022 12:47:33 PM EST John R Levine wrote: > >> Um, surely you've been around long enough to know that "transition > >> period" > >> means "forever". > > > > Yes, if the PSL lasts forever. > > No, if old DMARC verifiers last forever, which they will. For example, we > pu

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

On Monday, February 14, 2022 10:45:39 AM EST Todd Herr wrote: > On Sun, Feb 13, 2022 at 5:16 PM Dotzero wrote: > > On Sun, Feb 13, 2022 at 4:30 PM Scott Kitterman > > > > wrote: > >> I think "a" would be cleanest, but I think it would cause too much >

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

On Friday, February 11, 2022 1:25:15 PM EST John Levine wrote: > It appears that Alessandro Vesely said: > >I think it is already clear to the WG that the tree walk is screwed up. > > Yes, we know we have to rewrite sections 4.5 and 4.6. > > I think there are 2 1/2 situations we need to look at

Re: [dmarc-ietf] Organizational Domain

On Sunday, January 30, 2022 2:57:56 PM EST Dave Crocker wrote: > On 1/30/2022 10:39 AM, Scott Kitterman wrote: > > On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote: > >> On 1/29/2022 7:53 PM, Scott Kitterman wrote: > >>>> 1. Using 7489 or 9091 a

Re: [dmarc-ietf] Organizational Domain

On Sunday, January 30, 2022 11:14:18 AM EST John R Levine wrote: > On Sun, 30 Jan 2022, Alessandro Vesely wrote: > > Let me ask if the following scenario is possible at all: > > > > .BANK admins decide to setup a DKIM signing service for .bank domains. > > They register dkim.bank, and accept and

Re: [dmarc-ietf] Organizational Domain

On Sunday, January 30, 2022 7:34:35 AM EST Alessandro Vesely wrote: > (This message is not going to be accepted by the IETF today, so I CC John > too) > On Sun 30/Jan/2022 05:25:30 +0100 Dave Crocker wrote: > >>> 3. The role of the function that uses the PSD and the role of the > >>> function that

Re: [dmarc-ietf] Organizational Domain

On Saturday, January 29, 2022 11:25:30 PM EST Dave Crocker wrote: > On 1/29/2022 7:53 PM, Scott Kitterman wrote: > >> 1. Using 7489 or 9091 as fixed, controlling documents is problematic, as > >> I've noted. So, 'consistency' with them is frankly irrelevant.

Re: [dmarc-ietf] Organizational Domain

On Saturday, January 29, 2022 10:26:37 PM EST Dave Crocker wrote: > On 1/29/2022 1:58 PM, Scott Kitterman wrote: > > So going > > back to Dave's proposed text that started the thread: > > > > On Saturday, January 29, 2022 1:11:29 PM EST Dave Crocker wrote: > &

Re: [dmarc-ietf] Organizational Domain

On Saturday, January 29, 2022 3:48:46 PM EST John R Levine wrote: > >> Since a PSD can't be an organizational domain, I don't think that's going > >> to work. > > > > Please provide the foundation to this assertion, because I believe the > > text > > I've offered makes your premise wrong. > > The

Re: [dmarc-ietf] tree walk is experimental

On Wednesday, January 26, 2022 1:47:37 PM EST Dave Crocker wrote: > On 1/26/2022 10:38 AM, John R Levine wrote: > >>> It appears that Dave Crocker said: > The method of finding the organizational domain should be specified > outside of the base DMARC specification. I suggested this back

Re: [dmarc-ietf] tree walk is experimental

On Wednesday, January 26, 2022 12:30:01 PM EST Seth Blank wrote: > Yes, this is a core ticket that needs to be addressed: > https://trac.ietf.org/trac/dmarc/ticket/46 > > I believe right now the group is just dialing in the definition/text, but > there has been broad agreement (I don't remember he

Re: [dmarc-ietf] Tree walk is screwed up

On Wednesday, January 26, 2022 10:27:04 AM EST Steve Siirila wrote: > After reading this thread, I couldn't help but wonder about how the > addition of a "PSD flag" specifically targeted to DMARC might be repurposed > for other non-DMARC applications since my understanding is that the PSL is > curr

Re: [dmarc-ietf] Timeline for Release of draft-ietf-dmarc-dmarcbis-5

On Tuesday, January 25, 2022 2:48:24 PM EST Todd Herr wrote: > Greetings. > > I've been monitoring the on-list discussion and I would like to take a stab > at incorporating it into the next draft. > > My plan is to get a next draft released either Monday, January 31 > or Tuesday, February 1, but

Re: [dmarc-ietf] Tree walk is not a heuristic, was screwed up

On January 25, 2022 5:40:09 PM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>My impression is that the group is generally okay with PSD=y. I prefer it >>over your suggestion. My strongest preference is that we pick something, >>stick with it, and

Re: [dmarc-ietf] Tree walk is screwed up

On January 25, 2022 5:36:23 PM UTC, Alessandro Vesely wrote: >On Tue 25/Jan/2022 12:47:21 +0100 Scott Kitterman wrote: >> On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely >> wrote: >>> On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote: >>>> On

Re: [dmarc-ietf] Tree walk is screwed up

On January 25, 2022 11:30:51 AM UTC, Alessandro Vesely wrote: >On Tue 25/Jan/2022 06:56:26 +0100 Scott Kitterman wrote: >> On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote: >>> On January 25, 2022 12:46:48 AM UTC, John Levine wrote: >>>> It appea

Re: [dmarc-ietf] Tree walk is screwed up

On Monday, January 24, 2022 10:15:49 PM EST Scott Kitterman wrote: > On January 25, 2022 12:46:48 AM UTC, John Levine wrote: > >It appears that Scott Kitterman said: > >>What I implemented is roughly: > >> > >>For policy determination, first check the From do

Re: [dmarc-ietf] Tree walk is screwed up

On January 25, 2022 12:46:48 AM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>What I implemented is roughly: >> >>For policy determination, first check the From domain, if that has a DMARC >>record, then that's the policy domain. Oth

Re: [dmarc-ietf] Tree walk is screwed up

On Monday, January 24, 2022 5:23:27 PM EST Scott Kitterman wrote: > On Wednesday, January 19, 2022 1:38:15 PM EST John Levine wrote: > > I took a look at sections 4.5 and 4.6 of the draft, the part that > > describes > > the tree walk and PSD, and unfortunately what

Re: [dmarc-ietf] Tree walk is screwed up

On Wednesday, January 19, 2022 1:38:15 PM EST John Levine wrote: > I took a look at sections 4.5 and 4.6 of the draft, the part that describes > the tree walk and PSD, and unfortunately what it currently says is > seriously wrong. Apologies for not catching this sooner. > > It currently says you

Re: [dmarc-ietf] Tree walk is screwed up

On Friday, January 21, 2022 9:28:07 AM EST John R Levine wrote: > >> For the same reason the PSL has a lot of two- and three-label domains. > > > > Except that the PSL is somehow vetted; that is, there are no > > self-appointed > > PSDs. > > Sorry, but that is simply false. The entire "private d

Re: [dmarc-ietf] Tree walk is screwed up

he match string > used for alignment is the organizational domain, one segment down from the > PSD policy. Any SPF or DKIM domain must match or be a child of the > organizational domain, so there is no secondary tree walk, > > Does that correct the problem? > > > > On

Re: [dmarc-ietf] Tree walk is screwed up

On Thursday, January 20, 2022 9:57:48 AM EST Douglas Foster wrote: ... > -- If a policy is found with PSD=y, the domain does not participate in > DMARC but may need to be tested for non-existence. If the policy also > specifies NP=reject, query the next-lower domain name for a resource > record.

Re: [dmarc-ietf] Tree walk is screwed up

wrong. >> Apologies for >> not catching this sooner. >> >> >> >No worries; that's what draft revisions are for... > >I'll work to rewrite these sections for the next version. > >Scott Kitterman, do you mind if I just incorporate you

Re: [dmarc-ietf] What is a PSD for, was Evaluator reference model

No. That's not how DMARC records work and there's no reason to make psd=y mean anything other than "don't use this domain when evaluating alignment". Scott K On Tuesday, January 18, 2022 5:44:34 PM EST Douglas Foster wrote: > You could declare that "DMARCv1 psd=y np=reject" is a valid policy, t

Re: [dmarc-ietf] What is a PSD for, was Evaluator reference model

On Tuesday, January 18, 2022 4:16:57 PM EST John Levine wrote: > It appears that Todd Herr said: > >If the intent of the tree walk is, at least in part, to allow for > >publishing of policy records at the PSD level and for those records to be > >inherited by existing subdomains (e.g., _dmarc.tld

[dmarc-ietf] PSD tag reprised and related updates

Last month I made the comment that I thought the PSD flag should be just psd, not psd=y. I've studied it some more and concluded that psd=y is fine. The amount of text (and potentially code) that would be needed is disproportionate to the benefit of a simpler tag. While looking through this,

Re: [dmarc-ietf] 5.7.2.1. DMARC Policy Discovery - How to handle a missing policy

On January 6, 2022 9:34:44 PM UTC, Douglas Foster wrote: >Please explain what you think is wrong and why. We are not voting yet, we >are discussing. This being the IETF, we aren't voting. Scott K ___ dmarc mailing list dmarc@ietf.org https://www

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

On Tuesday, December 21, 2021 2:32:12 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >>> What definition are you wondering why we didn't stick to? > >> > >>Real non-existence. I'm not sure how to define it formally, ... >

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

On December 21, 2021 12:05:35 PM UTC, Alessandro Vesely wrote: >On Mon 20/Dec/2021 18:41:25 +0100 Scott Kitterman wrote: >> On Monday, December 20, 2021 12:39:15 PM EST Alessandro Vesely wrote: >>> On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote: >>> > If

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

On Monday, December 20, 2021 12:39:15 PM EST Alessandro Vesely wrote: > On Sun 19/Dec/2021 21:42:16 +0100 Scott Kitterman wrote: > > If the domain owner has suggested that you reject mail from a sub-domain > > that has none of A, , or MX records, why would you not do that? >

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence (Sample Data)

On Monday, December 20, 2021 12:10:31 PM EST Alessandro Vesely wrote: > On Mon 20/Dec/2021 12:53:12 +0100 Douglas Foster wrote: > > I am not doing any root domain lookups. If that is part of the proposed > > algorithm, somebody needs to document it. I am simply looking for a > > resource record

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

gt; I am not entirely happy with that workaround, as it may have unwanted side > effects about how reporting occurs back to the domain owner. > > DF > > > > On Sun, Dec 19, 2021 at 3:42 PM Scott Kitterman > > wrote: > > If the domain owner has suggested t

Re: [dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

If the domain owner has suggested that you reject mail from a sub-domain that has none of A, , or MX records, why would you not do that? Just as with any DMARC policy it's on the sender to ensure authorized email conforms to the policy. My impression is that you think that rejecting mail f

Re: [dmarc-ietf] Agenda Denial Was: IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

And then spent three years in a set of stepwise refinements that brought us >back to the starting point because DNS is still DNS-ing and even harder. > > > >On Sat, Dec 18, 2021 at 3:44 PM Scott Kitterman >wrote: > >> Okay. I didn't mention the fence as an endors

Re: [dmarc-ietf] Agenda Denial Was: IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

r unpleasant chap. Like most of the English >establishment of the time, his goal was to avoid sharing any of the wealth >of Empire with the undeserving masses who created/looted it. > >I strongly caution against anyone attempting to raise his standard in a >technical discussion. > &g

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

On Friday, December 17, 2021 8:43:17 PM EST Tim Wicinski wrote: > On Fri, Dec 17, 2021 at 6:56 PM Douglas Foster < > > dougfoster.emailstanda...@gmail.com> wrote: > > That is not my position, and I don't know how you drew that > > conclusion from those words. > > Then my mistake. > > > I do take

[dmarc-ietf] IETF Process/Culture was Re: 3.2.6 The meaning of non-existence

On December 17, 2021 11:26:38 PM UTC, Douglas Foster wrote: .. >A year after raising my concerns, I am still trying to get a collaborative >discussion started about what the optimal test looks like. In a >collaborative discussion, those who are happy with the status quo convince >the skeptics

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

lice.uk doesn't seem to have the 'np' tag. > > There are a number of domains with policies that have 'p=quarantine|reject > sp=none' - it would be good to see if 'np=reject' is added to any. > > tim > > > > On Wed, Dec 15, 2021

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

On Wednesday, December 15, 2021 5:44:46 PM EST Barry Leiba wrote: > > Scott, I have many problems with your response. Was it intended as an > > ad hominem? It certainly came across that way. > > It doesn't seem even remotely so to me. Please be careful with > attributing intent. No one tried

Re: [dmarc-ietf] 3.2.6 The meaning of non-existence

On December 15, 2021 4:16:13 AM UTC, Douglas Foster wrote: >What does we mean for an RFC5322.From address to be “non-existent”? > >We have said that it is non-existent because it fails the MX/A/ test, >but we have not documented what that test represents. Perhaps it seemed >obvious, but le

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

On Friday, December 10, 2021 2:45:29 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >>apply the DMARC check using each of those domains found in the > >> > >>RFC5322 <https://datatracker.ietf.org/doc/html/rfc5322>.From field

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

On Friday, December 10, 2021 2:24:12 PM EST Scott Kitterman wrote: > On Friday, December 10, 2021 2:14:36 PM EST Alessandro Vesely wrote: > > On Fri 10/Dec/2021 19:58:48 +0100 Scott Kitterman wrote: > > > On Friday, December 10, 2021 1:46:34 PM EST Alessandro Vesely wro

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

On Friday, December 10, 2021 2:18:47 PM EST Todd Herr wrote: > On Fri, Dec 10, 2021 at 1:59 PM Scott Kitterman > > wrote: > > Ordering isn't guaranteed to be preserved. I think the options are: > > > > 1. Do not test for DMARC (current, no backward compatib

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

On Friday, December 10, 2021 2:14:36 PM EST Alessandro Vesely wrote: > On Fri 10/Dec/2021 19:58:48 +0100 Scott Kitterman wrote: > > On Friday, December 10, 2021 1:46:34 PM EST Alessandro Vesely wrote: > >> RFC5322 explicitly allows multiple mailboxes: > >> from

Re: [dmarc-ietf] 5.7.1 - Mulitple FROM

On Friday, December 10, 2021 1:46:34 PM EST Alessandro Vesely wrote: > On Fri 10/Dec/2021 05:11:28 +0100 Douglas Foster wrote: > > The language in the quoted document about "multiple from messages are > > usually rejected" was interesting. It reflects what I would intend to > > do, and what I thi

Re: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and Domain Hierarchy

gt;> ><http://yoursubdomainhere.managebuilding.com>*. Depending on your needs, >>> >you may want to use another name when talking with clients, residents, >>> >friends, and family." None of the users of these subdomains has a >>> >relationship wi

Re: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and Domain Hierarchy

. We know to some extent that a relationship exists between a domain and > it's subdomains. What can we know about the relationship between sister > domains? Basically nothing. By allowing sister domains to act as "aligned" > we enable a potential ly gaping security hole in va

Re: [dmarc-ietf] dmarcbis-04, 4.7.1 and 4.7.2 Relaxed Alignment and Domain Hierarchy

On December 7, 2021 5:00:58 PM UTC, John Levine wrote: >It appears that Todd Herr said: >>-=-=-=-=-=- >>I've been engaged in a spirited off-list discussion regarding the topic of >>relaxed alignment and the idea of a required relationship between two >>domains in relaxed alignment. I won't re

Re: [dmarc-ietf] Best Guess SPF is a dead hack from 18 years ago

On Monday, December 6, 2021 4:22:16 PM EST Dave Crocker wrote: > On 12/6/2021 1:18 PM, John Levine wrote: > > Please can we all pretend it never existed, we never heard of it, > > and we certainly are not going to say anything about it. > > My best guess is that you are referencing something that

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On Monday, December 6, 2021 3:04:37 PM EST Dave Crocker wrote: > On 12/6/2021 11:56 AM, Scott Kitterman wrote: > > Somewhere we need to explain about how ARC related to DMARC. If it's > > going to be in the protocol specification, this is the place. Otherwise > > it

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On December 6, 2021 7:16:06 PM UTC, Dave Crocker wrote: >On 12/6/2021 5:29 AM, Scott Kitterman wrote: >> I think what better goes in this spot is a more general comment about local >> policy (it doesn't seem to be discussed elsewhere). > > >"Local policy&quo

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

On Monday, December 6, 2021 1:59:19 PM EST Dave Crocker wrote: > On 12/6/2021 10:48 AM, Scott Kitterman wrote: > > I understand you don't like what's there, but not how you think it should > > be changed. The proposed revision addresses the concern I had raised. > If

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On Monday, December 6, 2021 2:01:10 PM EST Alessandro Vesely wrote: > On Mon 06/Dec/2021 14:29:02 +0100 Scott Kitterman wrote: > > On December 6, 2021 1:04:44 PM UTC, Todd Herr wrote: > >>On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster wrote: > >>> I have multiple o

Re: [dmarc-ietf] Experiments

On Monday, December 6, 2021 1:53:13 PM EST Murray S. Kucherawy wrote: > To those who said they're collecting data and hope to have some stuff to > share soon, is there anything interesting to report? > > The topic of ARC's efficacy came up in another IETF context today (tools) > and I'm wondering

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

On December 6, 2021 6:39:17 PM UTC, Dave Crocker wrote: >On 12/6/2021 10:06 AM, Scott Kitterman wrote: >> OK. What's your recommendation then? > >Scott, > >I think my note contained a series of very basic recommendations.  I'm >not sure what else you are look

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

On Monday, December 6, 2021 1:01:51 PM EST Dave Crocker wrote: > On 12/6/2021 9:38 AM, Scott Kitterman wrote: > >> In the interests of future-proofing, should there ever be additional > >> underlying authentication protocols, I propose this: > >> > >>

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

On Monday, December 6, 2021 11:40:47 AM EST Todd Herr wrote: > On Mon, Dec 6, 2021 at 9:08 AM Scott Kitterman wrote: > > On December 6, 2021 1:35:10 PM UTC, Todd Herr > > > 40valimail@dmarc.ietf.org> wrote: > > >On Mon, Dec 6, 2021 at 7:

Re: [dmarc-ietf] 3.2.6. Non-existent Domains

On Sunday, December 5, 2021 9:35:15 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >> For your #2 you seem to be saying that if I send no-reply transactional > >> mail, my DNS would look like this: > >> > >> notifiy.bigcorp.com.

Re: [dmarc-ietf] dmarcbis-04, 5.5. Domain Owner Actions

On December 6, 2021 1:35:10 PM UTC, Todd Herr wrote: >On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely wrote: ... >>Should any overlooked systems be found in the >> reports, the Domain Owner can adjust the SPF record and/or configure >> DKIM signing for tho

Re: [dmarc-ietf] PSD Flag

On December 6, 2021 1:10:02 PM UTC, Todd Herr wrote: >On Sat, Dec 4, 2021 at 11:28 PM Scott Kitterman >wrote: > >> I think the addition of the PSD flag to support organizational domain >> determination is a good change. I have some quibbles about the exact

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On December 6, 2021 1:04:44 PM UTC, Todd Herr wrote: >On Sat, Dec 4, 2021 at 5:35 PM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> I have multiple objections to this paragraph in section 5.7.2 >> >> "Heuristics applied in the absence of use by a Domain Owner of either SPF

Re: [dmarc-ietf] 3.2.6. Non-existent Domains

On December 5, 2021 9:54:42 PM UTC, Douglas Foster wrote: >It is a relief to finally have this topic open for discussion. The issues >go deeper than null MX. > >The goal is to domain names that the domain owner never uses for >RFC5321.From addresses. No direct test exists, so there are two

Re: [dmarc-ietf] 3.2.6. Non-existent Domains

On Sunday, December 5, 2021 2:40:16 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >> How about if it has a null MX and a DMARC record or DKIM keys? Remember > >> that those records are at different names than the MX. ... > > > >There's

Re: [dmarc-ietf] 3.2.6. Non-existent Domains

On Sunday, December 5, 2021 2:04:20 PM EST John Levine wrote: > It appears that Scott Kitterman said: > >Should we modify the definition of non-existent domains so that a domain > >that only has an RFC 7505 null mx record is still considered non-existent? > How about if it h

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 1/5

On Saturday, December 4, 2021 11:12:22 PM EST Murray S. Kucherawy wrote: > On Fri, Dec 3, 2021 at 9:37 AM Alessandro Vesely wrote: > > The second paragraph says: > > Section 8 creates a registry for known DMARC tags and registers the > > initial set defined in this document. Only tags def

[dmarc-ietf] PSD Flag

I think the addition of the PSD flag to support organizational domain determination is a good change. I have some quibbles about the exact definition though: > psd: A flag indicating whether the domain is a PSD. (plain-text; > OPTIONAL; default is 'n'). Possible values are: > >

[dmarc-ietf] 3.2.6. Non-existent Domains

Should we modify the definition of non-existent domains so that a domain that only has an RFC 7505 null mx record is still considered non-existent? I'll propose text if it's agreed this would be a useful change? Scott K ___ dmarc mailing list dmarc@i

[dmarc-ietf] RFC 9091 Downrefs

Currently the draft (as did the previous revision) has: > 3.2.8. Public Suffix Domain (PSD) > > The term Public Suffix Domain is defined in [RFC9091]. > > 3.2.9. Public Suffix Operator (PSO) > > The term Public Suffix Operator is defined in [RFC9

Re: [dmarc-ietf] Additions to introduction

On December 4, 2021 10:09:48 PM UTC, Seth Blank wrote: >On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski wrote: > >> >> I am Ok with adding text of this nature, and I think it's helpful in >> explaining to folks approaching >> DMARC for the first time. But I start to lose focus on reading long >>

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

RFC7489 (6729) >>To: , , >>Cc: , >> >> >>The following errata report has been submitted for RFC7489, >>"Domain-based Message Authentication, Reporting, and Conformance (DMARC)". >> >>-- >>You may revie

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On December 4, 2021 10:35:17 PM UTC, Douglas Foster wrote: >I have multiple objections to this paragraph in section 5.7.2 > >"Heuristics applied in the absence of use by a Domain Owner of either SPF >or DKIM (e.g., [Best-Guess-SPF >

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

On December 5, 2021 12:23:40 AM UTC, "Murray S. Kucherawy" wrote: >On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster < >dougfoster.emailstanda...@gmail.com> wrote: > >> I think this text was inserted because of an open ticket when discussion >> was going nowhere and a new draft was created. Perha

Re: [dmarc-ietf] Reversing modifications from mailing lists

On November 30, 2021 5:30:39 PM UTC, John R Levine wrote: >On Tue, 30 Nov 2021, Wei Chuang wrote: >> What about adding a footer to some html mime part is poorly handled when >> using "l="? Multipart bodies could be handled by other techniques. > >See section 8.2 in the DKIM spec which says if

Re: [dmarc-ietf] Organizational Alignment Options

I don't think that's the question we want to try and answer in this working group. That's roughly the question dbound tried and failed to answer. If I could reframe the question, I would make it "Is it feasible that DNS flags could provide a less-bad replacement for the PSL for DMARC". We have

Re: [dmarc-ietf] Organizational Alignment Options

Why. Walk one, jump to five, and then walk up adds complexity and matches no current behavior. Complexity for complexities sake is a bad idea. Has anyone posted to this list that they are having an actual problem that this would solve? Also, it usually results in clearer communication when

Re: [dmarc-ietf] Organizational Alignment Options

RCv1 had not created this anomaly by using subdomains, but it is > too late to fix. > > Do we leave these as anomalies, or give them the best available DMARC > participation by ensuring that their parent policy is checked? > > On Wed, Nov 3, 2021, 11:08 AM Scott Kitterman wrote

Re: [dmarc-ietf] Organizational Alignment Options

t we will be walking the top n levels, it is only an issue on >long domain names. > > > > >On Wed, Nov 3, 2021, 10:19 AM Scott Kitterman wrote: > >> Would you please provide a specific example where this would be needed? >> I'm not sure I understand what

Re: [dmarc-ietf] Organizational Alignment Options

the closest possible layer. > >On Tue, Nov 2, 2021, 10:09 PM John Levine wrote: > >> It appears that Scott Kitterman said: >> >4. Common parent domain not marked PSD. We could add a new tag to the >> DMARC >> >records for PSDs to indicate it's a PSD, so i

Re: [dmarc-ietf] Organizational Alignment Options

On November 3, 2021 9:58:34 AM UTC, Alessandro Vesely wrote: >On Wed 03/Nov/2021 04:04:38 +0100 Scott Kitterman wrote: >> On November 3, 2021 2:09:04 AM UTC, John Levine wrote: >>>It appears that Scott Kitterman said: >>> >>>> 4. Common parent domain

Re: [dmarc-ietf] Organizational Alignment Options

On November 3, 2021 2:09:04 AM UTC, John Levine wrote: >It appears that Scott Kitterman said: >>4. Common parent domain not marked PSD. We could add a new tag to the DMARC >>records for PSDs to indicate it's a PSD, so it's record shouldn't be used for >&

[dmarc-ietf] Organizational Alignment Options

I've been thinking about options for how to determine if message identifiers are aligned. Based on recent feedback, I've discarded mfrom/d= domain equals or is a subdomain of from domain as a feasible idea. Here's what I'm left with: 1. No change. For relaxed alignment, as long as there is

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

utside of this discussion here. We have > enough examples with other standards that opted for a dependency instead of > trying to solve it alone. And if that is so important, "dbound" is not > dead, only concluded... > -Ursprüngliche Nachricht- > Von: dmarc Im Auft

Re: [dmarc-ietf] same old org domain, Topic for IETF 112 - Policy Discovery

On November 1, 2021 10:51:13 PM UTC, Dotzero wrote: >On Mon, Nov 1, 2021 at 6:08 PM Tobias Herkula >wrote: > >> Yes this is used in a significant way, dropping the mechanic of the >> org-domain would make a lot of things in processing inbound mail streams a >> lot more complicated. >> >> The P

Re: [dmarc-ietf] treewalk and org domain, Topic for IETF 112 - Policy Discovery

On November 1, 2021 10:29:46 PM UTC, John Levine wrote: >It appears that Joe Humphreys said: >>We send tens of millions of such messages daily. These are messages where >>the From address is nore...@application.organization.com, and the DKIM >>signing domain is just organization.com. >> >>I s

Re: [dmarc-ietf] Topic for IETF 112 - Policy Discovery

MARC record. > >Regards, >Joe Humphreys > > >On Mon, Nov 1, 2021 at 4:26 PM Scott Kitterman wrote: > >> That was addressed in Message-ID: >> <7ca0f341-7a14-46ee-8be6-66e3f2537...@kitterman.com>. >> >> Scott K >> >> On Monday, Nove

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