Email Spam Prevention

[groundcat]

This issue is created to follow up the discussion in https://github.com/publicsuffix/list/pull/2182#issuecomment-2359987103

I know this is probably low priority, but I just wanted to document it here for future consideration.

Background:

Based on my experience sending confirmation emails to requestors, a very small portion of requestors respond. One likely cause is that emails listed on the Public Suffix List (PSL) are propagated to various places, leaving them vulnerable to spam. Over time, this can lead requestors to stop monitoring these email addresses, reducing the effectiveness of using them for important communications.

Related issues and case studies:

• Phishing email: #2153
• Spam complaint: https://github.com/publicsuffix/list/pull/2182#issuecomment-2359987103
• Unsolicited email or phishing: #1846
• Unsolicited email or phishing: https://github.com/publicsuffix/list/issues/1849

Proposal:

As both @o3o-ca and @wdhdev suggested in https://github.com/publicsuffix/list/pull/2182#issuecomment-2359987103, the community could possibly mitigate these issues by creating documentation in this repository that includes a list of source emails or email rules, indicating who can contact requestors for PSL matters. This would give requestors the option to apply an email filter or allowlist certain trusted domains and addresses.

Pros:

• Preventing spam could make the practice of listing contact emails more useful.
• Requestors would have the option to allowlist important emails, such as those from maintainers and volunteers, without blocking all other emails.
• This approach places no additional burden on requestors, as they can choose whether to set up the filter.

Cons:

• It could be challenging for maintainers to continuously update and manage the list of trusted email addresses and determine who can be trusted or not. Would there be security implications?
• Requestors may find it impractical to keep their email filters updated, especially if individual email addresses need to be allowlisted instead of entire domains (e.g., allowing all @mozilla.org emails).

Proposed Action:

• Create a file in the PSL repository listing trusted email addresses, domains, or subject-based rules used by maintainers and volunteers for PSL-related communications. This would allow requestors to set up filters and ensure that essential messages reach them without being caught in spam filters.

Example Approaches:

1. Domain-based allowlist: Instead of listing individual email addresses, we could use domain-based allowlists such as *@mozilla.org or *@volunteer.publicsuffix.example, allowing emails from any user at those domains to pass through.

   • Pros: Easier for requestors to manage, as they only need to add one domain to their filter.
   • Cons: This would require setting up and managing a dedicated email hosting service (e.g., @volunteer.publicsuffix.example), which adds complexity and overhead.

2. Individual email addresses: In cases where a dedicated domain is not feasible, we could list individual volunteer email addresses like jane.doe@example.com.

   • Pros: Easier to implement without requiring new infrastructure.
   • Cons: Harder for requestors to maintain since they would need to manually update the list as volunteers change.

3. Subject-based filtering: Instead of filtering based on email addresses or domains, we could ask volunteers and maintainers to include a specific string like "PSL Inquiry" in the subject line of all communications. Requestors could then configure their email systems to allow only messages containing this phrase in the subject and reject all others.

   • Pros: Reduces the need for managing email addresses or domains and works regardless of the sender’s personal email provider.
   • Cons: Relies on consistent implementation by all PSL volunteers and maintainers. If someone forgets to include the required subject string, important emails could still get filtered out.

• Requestors could be encouraged to implement one or more of these strategies to ensure that important PSL communications reach them while filtering out spam.

Looking for feedback from the community on how best to manage this process and whether it would be feasible to implement.

[wdhdev]

I think it could be worth setting up an email server on publicsuffix.org and then allocating email addresses to maintainers & trusted volunteers that require one, or setting up a group email address like publicsuffix@mozilla.org and somehow allocating access to it.

Listing individual email addresses in a single file could be done, however it would replicate the problem that the PSL itself has, which is lag time.

[groundcat]

@wdhdev Yes, it might be a good idea to spin up an email server or set up a group email, so requestors can easily recognize emails coming from volunteers. Also, when volunteers send emails, we could maybe CC a group email or mailing list to keep others in the loop.

That said, I am not too sure about volunteers using @publicsuffix.org or @mozilla.org addresses, since it could make it tricky for maintainers to know who to trust. To be honest, objectively speaking I would not fully trust my own GitHub account, which does not share much personal info besides a cat avatar 🤷‍♂️As a volunteer, I always try to identify myself as such when sending emails, so there is no confusion about whether I am a maintainer or a Mozilla employee. So, using @mozilla.org addresses might not be the best option? What do you think @simon-friedberger @dnsguru

One possible approach could be registering an alternative domain like publicsuffix[.]net dedicated for community volunteers to create email addresses for active volunteers, like name@volunteer.publicsuffix[.]net, for you and myself and those who regularly send emails to requestors but are not Moz maintainers.

Lastly, we could think about updating the readme.md to mention that emails from the maintainers and the community tend to come from @mozilla.org, @mozilla.com, or @volunteer.publicsuffix[.]net addresses. Hopefully this could help people who are suffering from spams to spot legit emails and cut down on spam issues with a filter if they want to.

https://github.com/publicsuffix/list/blob/36aa83b613f5de60c590e4d0b3119a1b6d099bd7/README.md?plain=1#L20-L22

Currently, these emails to requestors are being sent in very low volume, so this is probably not a priority issue. However, with the domain expiry being over two years and _psl TXT rules now required and enforceable, it is expected that the community may need to send more reminder emails for this in the future.

[wdhdev]

We could just use a subdomain on the already existing publicsuffix.org.

[simon-friedberger]

1. We can say that we will always be sending from certain domains and people can aggressively filter.
   • How do we make sure people can send those mails? Maintaining accounts for volunteers seems like too much manual work.
2. We can say we will always send mails with a specific subject like "[PSL notification] ...", that would allow filtering generic spam and might be enough.
3. We can say we will always send mails which include a GitHub issue or PR link, that should also allow filtering and would probably be a good idea anyway because we don't generally want people to reply by email.

Maybe we could do a combination of 1. and 3. by setting up a GitHub action which sends notifications for an issue or PR based on some kind of request.

[wdhdev]

Yeah those last 2 could work.

[groundcat]

1. We can say that we will always be sending from certain domains and people can aggressively filter.

   • How do we make sure people can send those mails? Maintaining accounts for volunteers seems like too much manual work.
2. We can say we will always send mails with a specific subject like "[PSL notification] ...", that would allow filtering generic spam and might be enough.
3. We can say we will always send mails which include a GitHub issue or PR link, that should also allow filtering and would probably be a good idea anyway because we don't generally want people to reply by email.

Maybe we could do a combination of 1. and 3. by setting up a GitHub action which sends notifications for an issue or PR based on some kind of request.

Yes, I agree with points 2 and 3, which can easily be implemented by adding them to the readme.md file. Using a subject line convention as a filter should be effective enough to block all spam and phishing emails that are not specifically designed to target the PSL requestors maliciously. Point 1 seems to require ongoing maintenance and might only be necessary if points 2 and 3 fail.