Re: [dmarc-ietf] Ticket #111 - MX/A/AAAA test needs justification

2021-05-08 Thread Douglas Foster
Justification and Implementation of the NP Policy The NP Policy is used to hinder attacks of type “Invention”, as defined below: · *Impersonation* attacks utilize an existing subdomain of the parent. The domain owner can hinder impersonation attacks using DMARC and SPF policies published

Re: [dmarc-ietf] https reports, or nits in draft-ietf-dmarc-aggregate-reporting-02

2021-05-08 Thread John Levine
It appears that Seth Blank said: >-=-=-=-=-=- > >(With Chair hat off and Valimail hat on) > >Email works fine for reports, even huge ones at scale. HTTPS adds nothing >for us and adds complexity to report processing (multiple paths to >ingestion) that we’d rather avoid. Just out of nosinesss, ho

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

2021-05-08 Thread John Levine
It appears that Murray S. Kucherawy said: >Personally, I think mandatory reporting wouldn't survive Last Call or IESG >Evaluation. Even if it did, there's no mechanism to enforce it ... Indeed. I check DMARC on all my incoming mail, but it is unlikely that I will ever get around to sending rep

Re: [dmarc-ietf] https reports, or nits in draft-ietf-dmarc-aggregate-reporting-02

2021-05-08 Thread Seth Blank
(With Chair hat off and Valimail hat on) Email works fine for reports, even huge ones at scale. HTTPS adds nothing for us and adds complexity to report processing (multiple paths to ingestion) that we’d rather avoid. Of course, were HTTPS added to the spec, we’d implement it. Seth On Sat, May 8

Re: [dmarc-ietf] https reports, or nits in draft-ietf-dmarc-aggregate-reporting-02

2021-05-08 Thread Murray S. Kucherawy
On Fri, May 7, 2021 at 12:22 PM John R Levine wrote: > On Fri, 7 May 2021, Murray S. Kucherawy wrote: > > [ mail and web departments don't talk to each other ] > > If that logic also holds for mail people and web people, > > I imagine the lack of interest here has a similar basis; we're talking >

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

2021-05-08 Thread Murray S. Kucherawy
On Sat, May 8, 2021 at 7:31 AM Alessandro Vesely wrote: > > - #62 makes reporting mandatory, which leaves the mail receiver with no > > means to mitigate the privacy threat. > #62 (assuming it has WG consensus) makes it clear we really want reporting to be mandatory, but at a glance I don't see

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

2021-05-08 Thread Murray S. Kucherawy
On Fri, Apr 23, 2021 at 11:21 AM wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain-based Message Authentication, > Reporting & Conformance WG of the IETF. > > Title : DMARC Aggregate Reporting >

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

2021-05-08 Thread Alessandro Vesely
On Sat 08/May/2021 14:29:11 +0200 Matthäus Wander wrote: Laura Atkins wrote on 2021-05-08 13:59: The current system does not allow for reconstruction of the forwarding pathway. I agree in that envelope_to makes it easier for reconstruction of the pathway, but disagree otherwise. DMARC reporti

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

2021-05-08 Thread Matthäus Wander
Laura Atkins wrote on 2021-05-08 13:59: >> What happens to the existing "envelope_to"? > > The proposal objected to was adding a new piece of information to pass > along information that would allow reconstruction of a forwarding pathway.  > > Case 1: Identify mail flows along forwarders. Th

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

2021-05-08 Thread Laura Atkins
> On 8 May 2021, at 10:50, Matthäus Wander > wrote: > > Barry Leiba wrote on 2021-05-06 16:16: >> Chair weighing in, as chair: >> >> We're divided in the sense that there are some who want to add this >> information, but as I see it the rough consensus is not divided: >> - This is extra inform

Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

2021-05-08 Thread Matthäus Wander
Barry Leiba wrote on 2021-05-06 16:16: > Chair weighing in, as chair: > > We're divided in the sense that there are some who want to add this > information, but as I see it the rough consensus is not divided: > - This is extra information that's being proposed... so, a new > feature. That require