Re: [dmarc-ietf] PSD simplification

["John Levine" <[e-mail]>]

In article <[e-mail]> you write:
>So I think that the functional goal of kitterman-dmarc-psd is fully 
>satisfied by merely doing a version of the 3A update to DMARC, directing 
>the client to query the immediate parent of the organizational domain, 
>if the OD has been queried and no DMARC record has been found.

Given that anything we do to handle public suffix defaults will need
some code changes, this seems about the simplest change that would do
the trick.

I am aware of two security or privacy issues that might come up.  If
we used a DNS scheme like my DBOUND one, whoever runs the DNS policy
server can see all the queries and will have some idea of the mail
traffic from various names.  This approach doesn't have that problem.
The DNS operator can tell that someone is asking about a subdomain,
but not which subdomain.

The other is that the DMARC record might have rua= and ruf= and get
detailed reports about subdomains.  This is not an unreasonable concern --
I am the legacy registrar for various <geographic>.ny.us domains and
my DMARC reports tell me a lot about one of my registrants who sends
a lot of mail.  (Real mail, they're the county govermnent.)  This is
easily addressed by clients ignoring the report advice in the OD
parent record.

One issue that is not our problem but might be Scott's is that in
ICANN contracted TLDs, they're not allowed to publish TXT records at
_dmarc.BANK or _dmarc.INSURANCE unless they apply to get special
permission to do so.  I happen to know the people who evaluate the
applications (as do many other people here) and I'm sure they would
say yes for those two TLDs, but it would involve some time and money.
This might actually be a feature, since a similar appplication for
_dmarc.XYZ or _dmarc.SUCKS would be treated with a lot more
scepticism.

R's,
John