Ale asks:
Hm... but PSDs don't seem to gain any extras by letting receivers know
they're
a PSD, do they?
I think they do. They get the benefits of name protection which DMARC
previously afforded only to organizational domains and subdomains, which I
would expect them to consider very valuable. While the publicsuffix.org
provides some protection, I would think they should prefer transferring
control of their status from the volunteers to themselves.
"I am a PSD means" four things:
1. "If you see a message with an SMTP address that uses my PSD name, it is
fraudulent and should be blocked."
2. "If you see a message with a FROM header that uses my PSD name, it is
fraudulent and should be blocked."
3. "If you see a DKIM signature that uses my PSD name, it will not verify
because the public key will be missing, but it is not merely unverified
material to ignore, it is positive evidence of a fraud attempt."
4. "If you are doing DMARC alignment testing, don't match on my PSD name,
You are not looking at an organization record."
As an evaluator, all of this would be pretty valuable information to me.
The first three flags are useful in other contexts, which is why I proposed
four independent flags. Nobody seemed to grasp that idea, so Scott has
simplified my idea down to a single flag serving a single purpose.
A related question is whether there is any incentive for malicious use of
the "I'm a PSD" flag by entities that are not actually PSDs. Since the
only effect of this flag is to cause mail to be blocked, I do not see any
such incentive, so I do not see any risk.
This assumption holds as long as the flag is only used for email filtering
purposes. If the HTML Cookie people want to use DNS to replace their
PSL, they need to use their own flags and evaluate their own vulnerability
to malicious use. I worry that having a character flag ("I am a PSD")
instead of a feature flag ("I never send mail") will increase the risk of
unplanned uses which will then create unexpected opportunities for
malicious use.
Based on something that was said a long time ago, I thought the real
obstacle would be that PSDs will not cooperate. Scott believes that the
cooperation problem is solvable, so it seems like a viable option.
Doug Foster
On Wed, Nov 3, 2021 at 5:59 AM Alessandro Vesely <[email protected]> wrote:
> On Wed 03/Nov/2021 04:04:38 +0100 Scott Kitterman wrote:
> > On November 3, 2021 2:09:04 AM UTC, John Levine <[email protected]> wrote:
> >>It appears that Scott Kitterman <[email protected]> said:
> >>
> >>> 4. Common parent domain not marked PSD. We could add a new tag to
> the DMARC
> >>> records for PSDs to indicate it's a PSD, so it's record shouldn't be
> used for
> >>> alignment. Getting this added to the literal handful of PSD records
> that
> >>> exist and specifying it should be used going forward is doable. To
> implement
> >>> this approach should produce identical (modulo PSL errors and
> omissions)
> >>> results to the RFC 7489 approach. It seems like we've decided to
> trust that
> >>> ICANN and ccTLD operators will effectively manage publication of PSL
> records
> >>> for policy discovery, so this leverages that trust to simplify
> alignment while
> >>> maintaining backward compatibility.
> >>
> >> This is a much better worked out version of my DNS tree climbing
> proposal. I like it too.
> >>
> >> PS: Just out of nosiness, what PSD records exist now?
> >
> > Thanks. As far as I know, .gov, .mil, .gov.uk, and .police.uk.
>
>
> Hm... but PSDs don't seem to gain any extras by letting receivers know
> they're
> a PSD, do they?
>
> For a similar extension, subdomains could indicate their Organizational
> Domain.
> That's in case a subdomain wants to override its OD policy, for example
> to
> add themselves to the feedback reporting addresses. A subdomain can still
> be
> interested in letting receivers know what is the actual OD, for example if
> they
> want the receiver to find their BIMI certificate. This sounds similar to
> SPF's
> include or redirect keywords. The receiver would have to load yet another
> TXT
> record and somehow produce a merged policy.
>
> OTOH, a subdomain that wants to distinguish itself from its OD wouldn't
> publish
> any reference to the latter. They can already do this.
>
>
> jm2c
> Ale
> --
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
