Since as long as the pct is not zero, any message can have the policy applied,
I don't think this is a substantiative compatibility break that warrants a
version bump. A version bump effectively translates to 'this is a new protocol
with zero deployment', which is not what this group is
I don't find this to be a surprise.
I believe we discussed this specific type of case early in the tree walk
discussion. An early proposal was to walk up the tree to find the PSD and then
reverse back down the tree to find the org domain (PSD +1). This approach
would have provided an
I agree... given that changes are being made, it makes total sense to rev the
version number.
- Trent
From: dmarc on behalf of Emil Gustafsson
Date: Thursday, February 23, 2023 at 11:18 AM
To: DMARC IETF
Subject: [dmarc-ietf] Pros & cons with keeping v=1 when replacing pct with t
I
If anyone in the DMARC wg has status information for us to include in
the Silicon Valley Red Cross chapter monthly report, I'll be glad to
include it. For the rest of you, apologies for the misaddressed message...
d/
On 2/23/2023 2:58 PM, Dave Crocker wrote:
On 2/23/2023 2:23 PM, Meyerson,
I haven’t done extensive research but here is a live example where treewalk will cause a result change. From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record. _dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_...@emaildefense.proofpoint.com;
The issue here, Tim, is that the current way of checking the PSL would send
you to the DMARC record for cuny.edu and p=none, while using the new tree
walk would send you to the DMARC record for bmcc.cuny.edu and p=quarantine.
In this case, it’s showing that the tree walk is the better mechanism,
It appears that Trent Adams said:
>-=-=-=-=-=-
>
>
>I agree... given that changes are being made, it makes total sense to rev the
>version number.
That means that everyone will have to publish two DMARC records, one
with v=1 and one with v=2. How long until it's safe not to publish the
v=1?
On 2/23/2023 11:20 AM, Trent Adams wrote:
I agree... given that changes are being made, it makes total sense to
rev the version number.
a natural assessment. unfortunately it has problems. version numbers
mostly don't work.
if the changes produce a spec that is a superset of the previous
On 2/23/2023 2:23 PM, Meyerson, Julie wrote:
As I discussed last volunteer meeting, I'm not able to access the doc
for editing the SitRep.
Here's what I'd like to include for community disaster education.
Julie, I'll add your text, but would like to do a session with you to
try to figure
Elizabeth,
(speaking as a DNS person). I think this is "OK" - at my last job we set
up DMARC records which stricter in certain subdomains than
the parent domain. (Now I need to go find the machine where I left my code
which did all this validation).
(As a DNS person I want to find the folks
I haven’t done extensive research but here is a live example where treewalk will cause a result change.
From: is in the domain Ret.bmcc.cuny.edu which has no DMARC record.
_dmarc.bmcc.cuny.edu.300INTXT"v=DMARC1; p=quarantine; fo=1;
I recognize that the changes in DMARCbis without also changing v=2 are
possible and don't cause a security problem as ignoring "pct" when parsers
are updated should result in the more restricive policy being applied.
I think however there is a practical problem. As a mailbox provider I would
not
It appears that Douglas Foster said:
>-=-=-=-=-=-
>
>I seem to have missed this redesign. I thought the plan had always been
>to take the top-most policy not flagged as PSD=Y.
The current design has been in the draft since October, and we discussed
it on this list at great length.
R's,
John
I seem to have missed this redesign. I thought the plan had always been
to take the top-most policy not flagged as PSD=Y.Taking the first
policy found is less work, but it turns subdomain policies into
organizational domain policies. I expect that to be an unwanted surprise
to many domain
I don't understand your point here, Doug. It seems more likely that a
subdomain of a subdomain should be following the latter subdomain's
policy by default, rather than the higher-level domain's. That is,
for a.b.c.d, "a" would be more likely to expect to follow "b" than
"c". Which means that
Oh well. It is hardly the first time that consensus did not involve my
consent.
On Thu, Feb 23, 2023, 9:03 PM Barry Leiba wrote:
> I don't understand your point here, Doug. It seems more likely that a
> subdomain of a subdomain should be following the latter subdomain's
> policy by default,
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This Internet-Draft is a work item of the Domain-based Message Authentication,
Reporting & Conformance WG of the IETF.
Title : Domain-based Message Authentication, Reporting, and
Conformance
17 matches
Mail list logo
