Add email policy

[groundcat]

This PR attempts to address Issue #2184 based on some of the potential solutions that @simon-friedberger proposed.

Changes made

• Removed outdated announcement
• Added an email policy to readme.md (or, should we add it to the guidelines instead?)

I'm not 100% sure whether what I've added fully aligns with the expectations of contributors and maintainers based on the issue thread, so I'm open to any edits or feedback! Please feel free to make/suggest changes if needed!

[DRAFT] Email Communication Policy

We tend to use the subject line tag "[PSL notification]" in all Public Suffix List communications. For effective spam filtering, you can create a case-insensitive filter to allow only emails with exact "[PSL notification]" in the subject line. If you choose to set up such a filter in your email application, please verify the filter is implemented correctly and test it thoroughly to ensure you don't accidentally miss important communications from us.

---

CC @wdhdev @dnsguru @simon-friedberger @mozfreddyb

[wdhdev]

This looks good, definitely needed. Good job 👍

[simon-friedberger]

I would probably drop the part about "verifies message authenticity" because everybody can open an issue here and then send an email referencing that issue.

[groundcat]

I would probably drop the part about "verifies message authenticity" because everybody can open an issue here and then send an email referencing that issue.

I agree. I used poor wording with "Verifies message authenticity." I meant to say that the PR link would contain information consistent with the email's content, but that issue is actually addressed in the item below. I have now removed the line about authenticity verification.

[simon-friedberger]

Should we also add this at https://publicsuffix.org/ or https://publicsuffix.org/submit/? 🤔

[wdhdev]

I don't think so. I'm in favour of deprecating the publicsuffix.org website as seen in #2197.

[groundcat]

I would approach this by a thought experiment imagining I am someone receiving a personal email from a contributor/maintainer. If I knew nothing about the PSL, I would likely search for it online (using Google or another search engine). The first thing I would probably find is the publicsuffix.org website, which would be where most people would go first when they have questions.

Should we also add this at https://publicsuffix.org/ or https://publicsuffix.org/submit/? 🤔

We could include a paragraph like the one below on the website or wherever people typically look first.

---

Did you receive an email from us?

Starting December 2024, the Public Suffix List (PSL) team occasionally sends verification emails to entry requestors to confirm the continued necessity of existing entries. To help you identify legitimate PSL communications and protect against spam, all emails from the PSL project will include a [PSL notification] prefix in the subject line, contain a GitHub issue or pull request link (https://github.com/publicsuffix/list/*), and may be CC'd to the psl-discuss mailing list or maintainers. We encourage you to respond through GitHub rather than email whenever possible. If you're unsure about the authenticity of a PSL-related email, please verify that it follows these guidelines and check the referenced GitHub link. If you receive a request to make DNS changes that don't align with the PSL guidelines, please do not implement these changes and instead seek confirmation through the psl-discuss mailing list or the referenced GitHub issue.

[groundcat]

Having a website provides the advantage of appearing more prominently in places like search results compared to a GitHub repository. Currently, publicsuffix.org ranks first when searching for "public suffix list." If we remove or redirect the website, our search ranking would likely decrease, and the official repository https://github.com/publicsuffix/list/ might have similar search rankings to forks like https://github.com/attacker/list/ as all GitHub repos rely on the github.com namespace. We should make sure people can easily find the authoritative source, and I believe maintaining a website is somewhat essential for this purpose.

I personally would hope the website to serve as a neutral, platform-independent source of truth. It gives us the flexibility to communicate directly with our users without being constrained by GitHub's interface or features. We can present information in a way that makes the most sense for our specific needs, rather than fitting into GitHub's repository structure. This independence helps establish and maintain the project's authority as the official source of the Public Suffix List and make it very clear to users they are accessing the authentic resource.

Also, maintaining our own web presence ensures long-term sustainability. While GitHub is a stable platform today, having our own website provides resilience against potential future changes in GitHub's policies, ownership, or availability. Though, this might reflect my personal preference against centralized tech giants :)

ps. I understand the value of GitHub as our collaboration platform, but I think maintaining our own website has special meaning for PSL as a Mozilla initiative. Having a neutral, platform-independent space for information aligns nicely with Mozilla's principle that "The effectiveness of the internet as a public resource depends upon interoperability (protocols, data formats, content), innovation and decentralized participation worldwide." I feel that both approaches have their strengths, and we can benefit from using them together - GitHub for collaboration and our website as an independent information source.

[wdhdev]

You make a very good point regarding SEO. Maybe we shouldn't completely deprecate the website, however I think it would be worth redesigning or at the very least, updating the information on it. Also it would be worth migrating the website to a static page host such as GitHub Pages, which would be much better and cheaper.

[simon-friedberger]

Yes, we should definitely redesign the website.

[dnsguru]

+1 on github pages replacing current "website"

Just have to not break the cdn setup for downloading the .dat file in the process.

Would be hood to share stats on how much it gets downloaded

[wdhdev]

We could easily setup a GitHub action to push any changes from public_suffix_list.dat here to the website repo.

[simon-friedberger]

(We should really have that discussion in the other issue.)

Regarding the wording here:
I generally agree with the contents now but the phrasing sounds a bit like "you can check for these three things to make sure you are getting an email from us" but I would prefer if they only checked the first. I don't want to end up in a situation where people are not getting our mails because they created a spam filter that is too strict because we suddenly found a reason to send emails without a Github issue or some personalized email which we don't want to copy to the list for all 500 recipients.

[groundcat]

Regarding the wording here:
I generally agree with the contents now but the phrasing sounds a bit like "you can check for these three things to make sure you are getting an email from us" but I would prefer if they only checked the first. I don't want to end up in a situation where people are not getting our mails because they created a spam filter that is too strict because we suddenly found a reason to send emails without a Github issue or some personalized email which we don't want to copy to the list for all 500 recipients.

I understand your point. Perhaps we should pause and rethink this approach. If we send out emails with the subject "[PSL notifications]" and requestors have implemented filters that are case-sensitive and only accept "[PSL Notifications]," they will not receive any emails from us, which would indeed create more problems.

Any method other than a sender domain-based approach (where only emails sent from @example.com and validated by DKIM, SPF, etc. are considered authentic) - such as requiring specific strings in the subject line or specific URL patterns in the email body - has room for error and, as you said, could prevent people from receiving legitimate emails from us.

Second, yes we should not suggest people CC the entire psl-discuss mailing list to avoid an overwhelming number of unnecessary emails to everyone on that list. Maybe just having only one or two maintainers in CC is sufficient.

Most likely, it is best to reconsider and not suggest people use any filters at all. Instead, we could simply ask them to be cautious and raise questions in this GitHub repository (by creating an issue, asking in the mailing list, or starting a discussion thread) whenever they are unsure if what they received is legitimate.

So, as for the initial concern about spam issues (receiving too much spam due to publicly listed email addresses, leading to fatigue and missed important emails in the inbox), I am afraid there is no reliable way to prevent that without using filters. However, if we do ask/recommend people to use a filter for allowlisting emails, perhaps the only reliable method with a minimal margin of error would be domain-based email filtering (where only valid emails from @publicsuffix.org are accepted).

[wdhdev]

Honestly, this whole fiasco seems to be getting more complicated by the day.

I think it would be less effort in the end to just issue @publicsuffix.org email addresses, and then end-users can simply filter by the publicsuffix.org domain name. It would also help volunteers such as @groundcat and I help prove that we are actually associated with the PSL, as using our personal email addresses likely seems fairly unprofessional and untrustworthy to some registries.

Let me know if I'm missing something though.

[groundcat]

Yes, what you mentioned is another valid reason. Sending emails from the project's domain is the ideal approach, as it provides credible and verifiable proof that the email comes from someone associated with this project. From my experience volunteering for this project, sending emails from my university email address receives a much higher response rate compared to using a random personal email address.

[mozfreddyb]

I want to empathize with you folks that it's frustrating to be met with skepticism and disbelief when doing cold-calls to ccTLDs and other entry holders :-) At the same time, I believe that we also want to uphold the great idea of the internet that "random internet people" can step in and contribute to impactful projects to the PSL. I'd rather the internet be full of people called @groundcat than everyone being firstname.surname@organization where the organization has to be something reputable (Sorry to pick on you! :)).

At the same time, I want to say that doing email hosting from a mozilla-owned domain comes with a lot of (imho annoying) admin stuff that involves IT and legal and would require you to sign documents and what not. If eveyone here strongly agrees, I can look into what it means, but I don't think this would reasonably qualify as what @wdhdev had in mind when he suggested we "just" issue email addresses. (Sorry!)

In the end, the exciting and impactful things are never purely of technical nature. I personally think that an email policy that allows cross-referencing work with an official website as well as e.g., GitHub issues is good for transparency and more reasonable to get done.

[wdhdev]

That is understandable, especially regarding issuing email addresses under a Mozilla domain name to non-Mozilla employees.

If it isn't too complicated @mozfreddyb, do you think you could look into what we would actually have to do in order to have @publicsuffix.org emails? It would help us receive a higher response rate from registries for sure.

@groundcat It's quite interesting what you say about being more likely to receive a response when using your university email. I guess emailing from some form of known uni/org would signify more trust than a personal email address.

[groundcat]

Thanks @mozfreddyb for the insights. Indeed... running an email server and issuing addresses hosted by Mozilla would involve much more complexity than initially anticipated - from GDPR compliance to other regulations, not to mention corporate procedures. I resonate with your point about "random internet people" being able to contribute - whether groundcat is a 😺 or 🦊, that's the beauty of open source projects and technological neutrality (in the ideal world).

Your suggestion about "cross-referencing work with an official website" seems like a practical solution. I've added language in the checkbox about reporting suspicious emails that deviate from PSL guidelines (using guidelines as source of truth rather than GitHub issues, since anyone can create an issue. This also allows for necessary communications like removal inquiries that may not have an associated issue yet).

I've created #2305 to track this and included the checkbox text: "If you receive any suspicious emails related to the PSL that deviate from PSL guidelines, please notify the PSL maintainers immediately."

[groundcat]

It seems that the PSL project previously maintained its own mail server with the address [email protected], as documented in this comment and publicsuffix/publicsuffix.org#23 However, this was later deprecated and it's unclear whether reestablishing it would be feasible?

[dnsguru]

Two comments.

First is ... because we are dealing with the issue of contactability over in ICANN-land, where whois gets harvested and email addresses get misused. Due to this, often a url of a form that allows contact to the registrant is acceptible substitute for an email address (and, a darn helpful bozo-filter against UCE/spam).

We might want to consider also accepting a contact form URL in pull requests to remain contemporary.

Yes, it means 400/500 error checks.

The second point could be that there be such a form on publicsuffix.org that reflects to our teammates. It might be a way to solve for "trust this" and doing so out from under the "kafka" overhead of @mozilla.org email that Freddy identified.

We had an incedent recently where some rando started emailing the contacts in the list as if they were part of the maintainers.

Someone with a listing, if contacted has no idea if our outreach is legit or not. With the ccTLDs/gTLDs, many will recognize me from all of the presentations and discussions in person I have done related to the PSL, but that doesn't aid the good work of groundcat or william or simon etc other volunteers.

As an example, I didn't recognize groundcat's "civilian" email when I first saw it in the fwd on the cctld outreach.

[mozfreddyb]

A tiny bit off-topic but if groundcat and william got triage permission, they would also show up under https://github.com/orgs/publicsuffix/people ;-)

[wdhdev]

Specifically, we would have to be added as org members, but that would definitely help improve responses from registries.

[wdhdev]

Was this meant to be closed?

[simon-friedberger]

It seems, it got auto-closed when I merged the PR.

[simon-friedberger]

@groundcat Would you please update this so we can complete it?

I am fine with stating that we will use a certain subject line, because that is easy to do and if people really want to filter they can.

We can also just close this, because generally people who run services on the internet are expected to be able to deal with spam. There are plenty of email addresses like abuse@, security@, postmaster@ which are suggested by https://www.rfc-editor.org/rfc/rfc2142 that need to be handled anyway.

[groundcat]

I am fine with stating that we will use a certain subject line, because that is easy to do and if people really want to filter they can.

Agreed!

Updated to:

We tend to use the subject line tag "[PSL notification]" in all Public Suffix List communications. For effective spam filtering, you can create a case-insensitive filter to allow only emails with exact "[PSL notification]" in the subject line. If you choose to set up such a filter in your email application, please verify the filter is implemented correctly and test it thoroughly to ensure you don't accidentally miss important communications from us.