Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

On Tue 19/Jan/2021 07:43:01 +0100 Murray S. Kucherawy wrote: [...] On Mon, Nov 16, 2020 at 7:16 PM Dale R. Worley wrote: My apologies for not tending to this promptly. In regard to the description of the experiments, the result criteria are rather subjective, but I don't see that as a problem

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

I raised objections to the definition of "non-existent", which never received an adequate response before the discussion went silent. DMARC checks the From header address, which may exist only as an identifier used for mass mailings. These mailings are often sent by an ESP using an unrelated SM

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

Picking up the thread on a ticket that was brought before the group pre-holidays and has lain fallow since the end of 2020... In reviewing the discussion, I don't believe a consensus has emerged on how to implement this feature, or even whether to do it. John proposed a new tag, ruap, for specify

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

On Tue, Jan 19, 2021 at 2:31 AM Alessandro Vesely wrote: > I guess "[this document]" refers to the RFC number to be. I think it's > useless > and can be safely removed, all of the five occurrences of it. > That's fine too. >> I believe that my strongest critique was that section 1 is difficult

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

On Tue, Jan 19, 2021 at 4:34 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > I raised objections to the definition of "non-existent", which never > received an adequate response before the discussion went silent. > > DMARC checks the From header address, which may exist only as

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On 1/19/2021 9:02 AM, Todd Herr wrote:> Other concerns were raised about privacy and security issues that might be inherent in and unique to adding this kind of functionality, issues that may not have been fully discussed or understood by the community over the years. There was also a question ab

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On Tue 19/Jan/2021 15:02:39 +0100 Todd Herr wrote: Concerns were voiced about interoperability impacts for Ale's suggestions, and Ale committed to running an experiment to see if there were changes to his inbound report flows when he implemented one variant for expressing the URI in the rua tag (

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

It seems that I was not successful in conveying my meaning in a few statements, so allow me to try again... On Tue, Jan 19, 2021 at 10:28 AM Hector Santos wrote: > On 1/19/2021 9:02 AM, Todd Herr wrote:> > > Other concerns were raised about privacy and security issues that > > might be inherent

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

On Tue, Jan 19, 2021 at 2:18 PM Alessandro Vesely wrote: > On Tue 19/Jan/2021 15:02:39 +0100 Todd Herr wrote: > > Concerns were voiced about interoperability impacts for Ale's > suggestions, > > and Ale committed to running an experiment to see if there were changes > to > > his inbound report fl

Re: [dmarc-ietf] Ticket #1 - SPF alignment

Picking up the thread on another ticket that was brought before the group pre-holidays and has lain fallow since the end of 2020... John Levine asserted that there wasn't a lot of strong opinion on the matter, and therefore we'd be leaving the spec as is, with the MAIL FROM SPF check the only one

Re: [dmarc-ietf] Ticket #80 - DMARCbis Should Have Clear and Concise Definition of DMARC

I am going to close this ticket. I have opened ticket 96, Tweaks to Abstract and Introduction , for Ale's suggestions and for any tweaks that John might still suggest. On Tue, Jan 5, 2021 at 8:36 AM Todd Herr wrote: > On Tue, Jan 5, 2021 at 7:25 AM A

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

No Murray, I was speaking to the PSD document. PSD's entire purpose is to detect abuse of non-existent organizational domains, so the definition of non-existent is crucial to its success.I believe the current language will produce false positives, albeit probably a small number.The current

Re: [dmarc-ietf] [Gen-art] [Last-Call] Genart last call review of draft-ietf-dmarc-psd-08

On Tue, Jan 19, 2021 at 2:11 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > No Murray, I was speaking to the PSD document. > > PSD's entire purpose is to detect abuse of non-existent organizational > domains, so the definition of non-existent is crucial to its success.I > be

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

In article you write: >My mention of "other concerns ... about privacy and security" is in >reference to a post in this thread that Mike Hammer made in early December, >where he wrote: > >"I don't recall a strong security and privacy concerns discussion around >HTTP(S) reporting. Presumably the r

Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

In article you write: >Can you provide more details, please? > >Are you receiving reports by HTTPS, or have you not seen any reduction in >reports, or both, or other? I didn't try Ale's OR- thing but I did add an https URL to my rua= tag and set up a web server to catch any POST or PUT traffic.