Seems like a reasonable way to do it.
Please consider the environment before reading this message.
John Levine, jo...@taugh.com
> On Jul 20, 2021, at 23:47, tjw ietf wrote:
>
> I like Dave’s idea here about leaving them changing their value to none.
>
>
>
> Sent from my iPhone
>
>>> On J
I like Dave’s idea here about leaving them changing their value to none.
Sent from my iPhone
> On Jul 20, 2021, at 22:45, Dave Crocker wrote:
>
> On 7/20/2021 7:04 PM, John Levine wrote:
>> I suppose we should have a Former DMARC Tags registry to prevent them
>> from being recycled with a d
On 7/20/2021 7:04 PM, John Levine wrote:
I suppose we should have a Former DMARC Tags registry to prevent them
from being recycled with a different meaning.
Or keep the current entry, changing the specification citation to NONE,
or even just keep the existing one.
d/
--
Dave Crocker
dcroc.
It appears that Dave Crocker said:
>If something is to be removed from a protocol, it needs to be removed.
>So, remove it.
Since you're supposed to ignore unknown tags in the DMARC record, that seems
straightforward enough.
I suppose we should have a Former DMARC Tags registry to prevent them
On 7/20/2021 1:13 PM, Barry Leiba wrote:
One of the points of "deprecation" is that we don't eliminate it
entirely, but say that it's no longer used. New implementations no
longer generate it, but implementations that are interested in
backward compatibility will still include support for it on
>> One of the points of "deprecation" is that we don't eliminate it
>> entirely, but say that it's no longer used. New implementations no
>> longer generate it, but implementations that are interested in
>> backward compatibility will still include support for it on receipt.
>>
>> Eventually, when
It appears that Dotzero said:
>As soon as we say deprecated, the justifications for backwards
>compatibility become tenuous. If a sender has no reasonable expectation
>that most validators will respect their request, why would they make such a
>request (other than in ignorance). I think very few
On Tue, Jul 20, 2021 at 4:13 PM Barry Leiba wrote:
> One of the points of "deprecation" is that we don't eliminate it
> entirely, but say that it's no longer used. New implementations no
> longer generate it, but implementations that are interested in
> backward compatibility will still include
One of the points of "deprecation" is that we don't eliminate it
entirely, but say that it's no longer used. New implementations no
longer generate it, but implementations that are interested in
backward compatibility will still include support for it on receipt.
Eventually, when we see that its
On 2021-07-20 19:16, Dotzero wrote:
On Tue, Jul 20, 2021 at 12:39 PM Dave Crocker
wrote:
On 7/20/2021 7:54 AM, Barry Leiba wrote:
I would like to see us deprecate PCT entirely,
+1
+1
if this was postfix it would not be accepted, old habist must stay to be
backward compatible, sadly not al
On Tue, Jul 20, 2021 at 12:39 PM Dave Crocker wrote:
> On 7/20/2021 7:54 AM, Barry Leiba wrote:
> > I would like to see us deprecate PCT entirely,
>
> +1
>
> d/
>
> --
> Dave Crocker
> dcroc...@gmail.com
> 408.329.0791
>
+1
Michael Hammer
___
dmarc ma
On 7/20/2021 7:54 AM, Barry Leiba wrote:
I would like to see us deprecate PCT entirely,
+1
d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791
Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org
__
On 7/20/2021 7:50 AM, Barry Leiba wrote:
I don't agree with the characterization of the second group. I would
say that we are partitioning messages into these two groups:
- Those for which we can confirm that they originated in the domain
they say they did.
- Those for which we can not confirm t
Indeed: I see PCT as a feature that was put in early, in order to
allow us to experiment with things and ease into DMARC. As we move to
a Proposed Standard version, I don't see a continuing need for such a
phase-in feature, and aggregate reporting covers the desire to reduce
reporting volume. I w
Doug, I think the issue here is that I disagree with your premise, so
the rest of the argument fails for me:
> The goal is to partition all incoming messages into two mutually exclusive
> groups: Those messages which
> originated under domain owner control, and those which originated under
> d
15 matches
Mail list logo
