About this paragraph:
>> The original pre-standardization version of this protocol included a
>> mandatory check of this nature. It was ultimately removed, as the
>> method's error rate was too high without substantial manual tuning
>> and heuristic work. There are indeed use cases this work
On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster"
wrote:
>About this paragraph:
>
>>> The original pre-standardization version of this protocol included a
> >> mandatory check of this nature. It was ultimately removed, as the
>>> method's error rate was too high without substantial manua
+1 on Scott's comment.
Michael Hammer
On Mon, Jul 22, 2019 at 6:44 AM Scott Kitterman
wrote:
>
>
> On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" <
> fost...@bayviewphysicians.com> wrote:
> >About this paragraph:
> >
> >>> The original pre-standardization version of this protocol included
On Mon, Jul 22, 2019, 04:44 Scott Kitterman wrote:
>
> On July 22, 2019 4:31:40 AM UTC, "Douglas E. Foster" <
> fost...@bayviewphysicians.com> wrote:
>
> >"Senders SHOULD register all domains in DNS, as MTA operators MAY block...
>
> I think that it is well outside the scope of this document to i
Reviewing as the document shepherd:
Abstract
[...]
organization can use to improve mail handling. DMARC policies can be
applied at the individual domain level or for a set of domains at the
organizational level.
I think the abstract is a bit too abstract. Which set of domains?
Th
Sorry, I hit "send" when I didn't mean to. Finishing up:
On Mon, Jul 22, 2019 at 9:23 AM Murray S. Kucherawy
wrote:
>
>o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
> PSD DMARC based reports will only be generated for domains that do
> not publish a DMARC
One (hopefully) last thing:
On Mon, Jul 22, 2019 at 9:23 AM Murray S. Kucherawy
wrote:
>
> 3.4. Section 6.6.3. Policy Discovery
>
>A new step between step 3 and 4 is added:
>
>3A. If the set is now empty and the longest PSD (Section 2.3) of the
> Organizational Domain is one tha
