Remove `ghost.io`

[sam-lord]

Submitter affirms the following:

• [x] We are listing any third-party limits that we seek to work around in our rationale such as those between IOS 14.5+ and Facebook (see Issue #1245 as a well-documented example)

• [x] This request was not submitted with the objective of working around other third-party limits

• [x] The Guidelines were carefully read and understood, and this request conforms
• [x] The submission follows the guidelines on formatting and sorting

---

For Private section requests that are submitting entries for domains that match their organization website's primary domain, please understand that this can have impacts that may not match the desired outcome and take a long time to rollback, if at all.

To ensure that requested changes are entirely intentional, make sure that you read the affectation and propagation expectations, that you understand them, and confirm this understanding.

PR Rollbacks have lower priority, and the volunteers are unable to control when or if browsers or other parties using the PSL will refresh or update.

(Link: about propagation/expectations)

• [x] Yes, I understand. I could break my organization's website cookies etc. and the rollback timing, etc is acceptable. Proceed.

Description of Organization

Ghost is an open source CMS, with an emphasis on publishing, memberships & email. We provide a hosting service, which uses subdomains of ghost.io as the default domain.

Organization Website: https://ghost.org

Reason for PSL Removal

We cannot comply with DMARC with our current setup. The organizational domain of the subdomains (of ghost.io) that we use for email are different to the organizational domain of the apex domain (ghost.io) we use for customer RFC5322.From addresses.

Our customers don't have the ability to set their own DNS records for their subdomain, and they don't control the server software (so they can't set HttpOnly cookies for other domains). Since we can overcome the security downside of the removal, and we can't easily overcome the DMARC issue, removal seems appropriate.

Previous PR adding us to the PSL: https://github.com/publicsuffix/list/pull/1180

Number of users this request is being made to serve:

Around 20k subdomains of ghost.io.

DNS Verification via dig

dig +short TXT _psl.ghost.io
"https://github.com/publicsuffix/list/pull/1969"

Results of Syntax Checker (make test)

============================================================================
Testsuite summary for libpsl 0.21.5
============================================================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
============================================================================

[simon-friedberger]

@sam-lord Would you mind answering a few questions?

1. How exactly are you planning to overcome the cookie issues? It seems if you remove the PSL entry any cookies for customer1.ghost.io will be sent to customer2.ghost.io and if anybody has two accounts they will constantly get logged out because the session cookies get overwritten.
2. What exactly is the problem with adding DMARC entries? Can you solve that problem by publishing a policy for each customer domain? Would your problem be solved by https://www.rfc-editor.org/rfc/rfc9091 but it's not implemented or does that not help?

[sam-lord]

Hi Simon,

1. We use cookies set for each subdomain. Our staging system is not on the PSL and we don't have any issues with logging out of other sites. The cookies used for security are all HttpOnly, and the server side code is all controlled by us, so our customers can't read / write the cookies on other subdomains.
2. The organisational domain in the DMARC standard is defined by the PSL. A customer with the subdomain example.ghost.io sends from example@ghost.io. We sign emails with a few different subdomains of ghost.io to separate customers by volume / other factors, but the organisational domain of m.ghost.io is m.ghost.io, because of our appearance on the PSL. The organisational domain of the from address is ghost.io, which doesn't match m.ghost.io, causing us to fail on a relax alignment check.

I have had a read through RFC 9091 while I was trying to find a solution to this, and I don't think it will fix our use-case. Since the emails need to be sent from @ghost.io, DMARC records at the subdomain level wouldn't help.

Let me know if you've got any other concerns about this change.