[dmarc-ietf] tree walk and DNS optimization

Performance is probably a BCP issue. However, since DNS performance concerns are a limiting factor on our specification options, the topic seems relevant menioning now. In my mail stream, only a small subset requires a DMARC policy lookup to determine disposition. I wonder if others have

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

On Fri, Nov 13, 2020 at 1:41 PM Tim Wicinski wrote: > > All > > During the chairs call this morning we were discussing the upcoming > meeting. Now Seth has a conflict with the meeting time that can't be > altered. Since work items have been progressing rather well recently, and > the editors

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

Dave It's the latter. Alexey and I are quite fine with running the meeting, that was part of our conversation. tim On Fri, Nov 13, 2020 at 3:23 PM Dave Crocker wrote: > On 11/13/2020 10:40 AM, Tim Wicinski wrote: > > During the chairs call this morning we were discussing the upcoming > >

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

On 11/13/2020 10:40 AM, Tim Wicinski wrote: During the chairs call this morning we were discussing the upcoming meeting.  Now Seth has a conflict with the meeting time that can't be altered.   Since work items have been progressing rather well recently, and the editors are in positing, we

[dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.txt)

Hi. I wanted to call everyone's attention to how draft-ietf-dmarc-dmarcbis-00 differs from the existing RFC 7489. The key differences are as follows: - Section 7, DMARC Feedback, has been mostly removed except for a paragraph that mentions that reporting will be discussed in a different

Re: [dmarc-ietf] IETF 109 possible agenda/session discussion

On Fri, Nov 13, 2020 at 10:41 AM Tim Wicinski wrote: > > All > > During the chairs call this morning we were discussing the upcoming > meeting. Now Seth has a conflict with the meeting time that can't be > altered. Since work items have been progressing rather well recently, and > the editors

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

In article <903acb7d-847e-c87c-f21b-dcfa698bf...@wisc.edu> you write: >You can't think of universities as single entities with central management >authority. For the longest time our CS department owned >wisc.edu and central IT had to ask them for permission to use it for >campus-wide email. I

[dmarc-ietf] Second WGLC for draft-ietf-dmarc-psd

All During the IESG reviews of draft-ietf-dmarc-psd, there were several issues raised with some of the document. Most of them are editorial but the one big item was the description of the Experiment. The chairs sat down and broke out the experiment section into three separate experiments, and

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

I beleive that we can and should address the Columbia University problem. Here are some thoughts: Policy Types =--- We have three types of policies: - "p=" policy for a specific domain - "sp=" policy for subdomains that do not enumerate their own - "sp=" policy for non-existent

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

On 11/13/2020 9:09 AM, Jesse Thompson wrote: You can't think of universities as single entities with central management authority. For the longest time our CS department owned wisc.edu and central IT had to ask them for permission to use it for campus-wide email. This highlights that the

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

On 11/13/20 9:03 AM, dotz...@gmail.com wrote: > > > On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan > wrote: > > > > As another case, would people be surprised that email for the > medical center cumc.columbia.edu is a

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

On 11/12/20 5:06 PM, Kurt Andersen (b) wrote: > On Thu, Nov 12, 2020 at 2:58 PM Jesse Thompson > mailto:40wisc@dmarc.ietf.org>> > wrote: > > On 11/12/20 3:23 PM, John Levine wrote: > > You now can put a DMARC > > record on a name below the org domain to shadow a subtree, but I

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

On 11/13/2020 6:46 AM, Joseph Brennan wrote: The simple solution is for cumc.columbia.edu to publish its own record. Done. Michael Hammer I don't think I have the right to force the owner of another domain to publish dmarc. The owner of the other domain

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

On Fri, Nov 13, 2020 at 9:46 AM Joseph Brennan wrote: > > >>> As another case, would people be surprised that email for the medical >>> center cumc.columbia.edu is a separate system managed by a separate IT >>> group from columbia.edu, and that any authentication for one should not >>> be

Re: [dmarc-ietf] Organizational domains, threat or menage, was On splitting documents and DBOUND

> >> As another case, would people be surprised that email for the medical >> center cumc.columbia.edu is a separate system managed by a separate IT >> group from columbia.edu, and that any authentication for one should not >> be applied to the other? I don't think this is unique in large >>

Re: [dmarc-ietf] Organizational domains, threat or menace, was On splitting documents and DBOUND

On Thu 12/Nov/2020 22:31:25 +0100 Dave Crocker wrote: On 11/12/2020 1:23 PM, John Levine wrote: The semantics are definitely not the same. You now can put a DMARC record on a name below the org domain to shadow a subtree, that's why the group should first focus on the semantics it