On Thu, Aug 19, 2021 at 1:50 PM Dotzero wrote:
> I'm troubled by this whole section. Unless IETF is getting into the
> certification or enforcement business, documenting anything about
> "implementation claims" would seem to be a non-starter. Do we have any
> similar requirements for "claims" abo
It appears that Todd Herr said:
> flows for the domain or sub-domains. It is not yet ready to commit
> to conveying a severity of concern for unauthenticated email using
> its domain.
That's just wrong. I've looked at the numbers, and p=none perfectly
communicates
my level of concern.
I'm troubled by this whole section. Unless IETF is getting into the
certification or enforcement business, documenting anything about
"implementation claims" would seem to be a non-starter. Do we have any
similar requirements for "claims" about implementing SMTP, DNS or other
standards? We should s
On Thu, Aug 19, 2021 at 3:53 PM Brotman, Alex wrote:
> I also feel like the document needs a better definition of Mediator (I
> didn’t see one in the document).
>
It's implied/inferred from this text in Section 3.1, Conventions Used in
This Document:
Readers are encouraged to be familiar w
I tend to agree on that last Receiver bullet being unenforced. If I had to
choose between an organization deploying DMARC without reporting, or holding up
on deploying DMARC because they can’t provide reporting for X,Y,Z reasons ..
I’m choosing the former. Does it potentially leave a hole in i
On Thu, Aug 19, 2021 at 3:22 PM Murray S. Kucherawy
wrote:
>
> I agree the parsers won't break from this change, but an operator
> currently advertising "pct=33" will suddenly stop getting what it thought
> it was asking for. One could argue that this constitutes "breakage".
>
>
It has been argu
On Thu, Aug 19, 2021 at 5:53 AM Todd Herr wrote:
> On Thu, Aug 19, 2021 at 7:19 AM Alessandro Vesely wrote:
>
>> On Wed 18/Aug/2021 22:17:57 +0200 Todd Herr wrote:
>> >
>> > The main update in this draft is removal of the "pct" tag, with an
>> > explanation as to why, and an introduction of the
On Thu, Aug 19, 2021 at 11:24 AM Todd Herr wrote:
>
>Mail Receiver: To implement DMARC, a mail receiver MUST do the
>
>following:
>
>
>* Perform DMARC validation checks on inbound mail
>
>
>* Perform validation checks on any authentication check results
>
> recorded by med
On Thu 19/Aug/2021 14:52:41 +0200 Todd Herr wrote:
On Thu, Aug 19, 2021 at 7:19 AM Alessandro Vesely wrote:
On Wed 18/Aug/2021 22:17:57 +0200 Todd Herr wrote:
The main update in this draft is removal of the "pct" tag, with an
explanation as to why, and an introduction of the "t" tag in an eff
Greetings.
Opening a discussion on two tickets at once, because I think they're
related, especially as presented in the current revision of DMARCbis.
Both topics are addressed in Section 8, Minimum Implementations, which
currently reads in its entirety:
8. Minimum Implementations
Domain ow
On Thu, Aug 19, 2021 at 7:19 AM Alessandro Vesely wrote:
> On Wed 18/Aug/2021 22:17:57 +0200 Todd Herr wrote:
> >
> > The main update in this draft is removal of the "pct" tag, with an
> > explanation as to why, and an introduction of the "t" tag in an effort
> > to maintain the functionality pro
On Wed 18/Aug/2021 22:17:57 +0200 Todd Herr wrote:
The main update in this draft is removal of the "pct" tag, with an
explanation as to why, and an introduction of the "t" tag in an effort
to maintain the functionality provided today by "pct=0" and "pct=100".
As held earlier, I disagree wit
On Wed 18/Aug/2021 22:30:06 +0200 Brotman, Alex wrote:
If you feel as though something is amiss, or I've misinterpreted the consensus,
please let me know.
I'd swap SHOULD and MUST between the following sentences:
If a report generator needs to re-send a report, the system
SHOULD use
13 matches
Mail list logo
