Add checkbox for contact method to the PR template

[groundcat]

Currently, domain submissions often use personal email addresses despite our preference for role-based addresses. However, this requirement isn't explicitly stated in our guidelines.

This PR attempts to add a new checkbox to the PR template to ensure submitters are using appropriate contact methods and understand the communication requirements for PSL inclusion. Also we've observed a "set and forget" pattern not only with the domains but also with the contact emails too, where submitters either use personal emails (which become invalid when they leave the organization) or set up role-based emails like [email protected] that aren't actively monitored after submission.

The changes include:

1. Requirements for a role-based email addresses
2. Specified 14-day maximum response time for PSL inquiries
3. Added guidance for reporting suspicious communications - attempts to partially address Email Spam Prevention #2184 and then possibly close Add email policy #2296 as the solutions proposed there seem impracticable/challenging to implement...

Note: The guidelines should also be updated to include this requirement by someone with write access. (This would be easier if we migrate the guideline to a new website powered by GitHub Pages as previously discussed, allowing for better collaboration on such documentation.)

---

Preview:

In your domain block submission, please include a role-based email address (e.g., [email protected], [email protected]) rather than a personal email address (e.g., [email protected]) under your organization name, so that the PSL project can maintain contact with your organization, independent of personnel changes.
This email address will be used for any required verification or inquiries regarding your PSL listing. This inbox must be actively maintained and monitored for future communications from the PSL project for as long as the domain remains in the PSL. Any PSL inquiries sent to this address must receive a response within 14 days, as maintaining timely communication is required for continued inclusion in the PSL. If you receive any suspicious emails related to the PSL that deviate from PSL guidelines, please notify the PSL maintainers immediately.

• A role-based email address has been used and this inbox is actively monitored with a response time of no more than 14 days.

[simon-friedberger]

Maybe I am misunderstanding something but why would we want Github pages? The site is already on Github: https://github.com/publicsuffix/publicsuffix.org

So you should already be able to create PRs for it!

[groundcat]

Ah, you caught me there! 😅 I completely forgot about the existence of the publicsuffix.org repo; yeah it's already on GitHub and definitely needs some love.

[simon-friedberger]

Do we really want to get notified when people are getting spam? What are we going to do about it?

[simon-friedberger]

LGTM in general!

[wdhdev]

The site is open source, but as far as I'm aware it isn't deployed using GitHub Pages, so I'm not sure if we would be able to actively deploy to the site easily. GitHub Pages would make it so any commits to the repo are automatically deployed, as well as removing the requirement for an external web server.

[groundcat]

Do we really want to get notified when people are getting spam? What are we going to do about it?

Good point! I added this notification line because I noticed that the project previously updated the readme.md with PSAs about suspicious emails (like the clarification from 2023-09-01).

list/README.md

Line 24 in a12cce0

2023-09-01 : ~~**We are not sending _PSL txt record email notices to anyone**~~

[simon-friedberger]

The site is open source, but as far as I'm aware it isn't deployed using GitHub Pages, so I'm not sure if we would be able to actively deploy to the site easily. GitHub Pages would make it so any commits to the repo are automatically deployed, as well as removing the requirement for an external web server.

It's deployed automatically! https://github.com/publicsuffix/publicsuffix.org/blob/main/.github/workflows/deploy-site.yaml

[wdhdev]

That's good, however I still think we should use GitHub Pages as it wouldn't require using any external services outside of GitHub. Also, for a simple website like publicsuffix.org, there's no reason to be paying for a server for it.

[simon-friedberger]

Do we really want to get notified when people are getting spam? What are we going to do about it?

Good point! I added this notification line because I noticed that the project previously updated the readme.md with PSAs about suspicious emails (like the clarification from 2023-09-01).

list/README.md

Line 24 in a12cce0

2023-09-01 : ~~**We are not sending _PSL txt record email notices to anyone**~~

True but we don't need people to report back to us. If somebody wants to they can but let's not explicitly suggest it. I don't want to be included in any spam people are getting.

Make the response time four weeks and then we can merge this.

[groundcat]

That's good, however I still think we should use GitHub Pages as it wouldn't require using any external services outside of GitHub. Also, for a simple website like publicsuffix.org, there's no reason to be paying for a server for it.

It appears that Mozilla-managed websites, including PSL's website and mozilla.org, are typically hosted on Google Cloud Platform and likely centrally managed. Not sure if moving to GitHub/Microsoft hosting would have any feasibility implications from Mozilla's legal/corporate perspective. @simon-friedberger @mozfreddyb

Since both approaches provide a standalone website, I don't have a strong preference between GitHub Pages vs. a GCP web server - either option would serve the purpose equally well I think.

Edit:

• According to GitHub's status history (https://www.githubstatus.com/history), they do experience downtime from time to time and probably more frequent lately. If we used GitHub Pages and it went down, it would prevent access to https://publicsuffix.org/list/public_suffix_list.dat. While I'm not familiar with GCP's reliability metrics for Mozilla's infrastructure, this potential availability impact on the PSL list is an important factor to consider when choosing between hosting options.

• Some of the Github Pages restrictions (https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages#usage-limits) may impact our ability to host the list if we use GitHub Pages, such as:

GitHub Pages sites have a soft bandwidth limit of 100 GB per month.

In order to provide consistent quality of service for all GitHub Pages sites, rate limits may apply. These rate limits are not intended to interfere with legitimate uses of GitHub Pages. If your request triggers rate limiting, you will receive an appropriate response with an HTTP status code of 429, along with an informative HTML body.

[groundcat]

True but we don't need people to report back to us. If somebody wants to they can but let's not explicitly suggest it. I don't want to be included in any spam people are getting.

Make the response time four weeks and then we can merge this.

That makes sense. I have just revised the wording.

[dnsguru]

No we do not, that is a giant volunteer time/cycle vortex