Email Spam Prevention

[groundcat]

This issue is created to follow up the discussion in #2182 (comment)

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: People sending emails to listed email addresses #2153
• Spam complaint: Update prvcy.page contact email #2182 (comment)
• Unsolicited email or phishing: "Public Suffix List Compliance Action Needed: Missing _psl TXT Record" with no pull request #1846
• Unsolicited email or phishing: scooper6@my.ccri.edu is not with PSL and "Compliance" emails are not being sent from this project #1849

Proposal:

As both @o3o-ca and @wdhdev suggested in #2182 (comment), 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.

list/README.md

Lines 20 to 22 in 36aa83b

	2024-07-26 : We are sending e-mail asking for confirmation if certain entries are still required
	Currently, this process is purely manual and extremely low volume but if you do get an e-mail, please respond.

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.

[wdhdev]

@simon-friedberger Email accounts for volunteers would likely be the best fit, as then people could simply filter emails from @publicsuffix.org and be done with it. Your second point could work, however there is nothing stopping spammers from just adding that to the subject line, rendering filtering useless.

Adding GitHub issue/PR links could also work, but there is always the possibility of someone using hyperlinks in scam emails and redirecting people elsewhere.

Does Mozilla run any email servers that publicsuffix.org could use, without too much hassle? It would require maintainence however it would be the safest bet in the long run.

We could also setup a no-reply email with a simple dashboard which requires OAuth with GitHub to restrict it to volunteers or users on a certain team, which would require little effort to maintain, other than the mail server.

[simon-friedberger]

I'm not sold on email addresses. That means they are somehow in contact with one specific volunteer and if that volunteer is unavailable they do not get a response. What we would want is some kind of CRM but that sounds like even more work.

And since most spammers won't bother to customize their spam for the PSL (presumably, none will) it's also not necessary. At least that was my reasoning for (2.) and (3.).

[wdhdev]

We could have a shared mailbox possibly, in that case.

Spammers are exclusively using emails on the PSL, so I doubt it would be difficult for them to update their subject.

[simon-friedberger]

Oh, how do you know? I assumed they just crawl the web including Github.

[wdhdev]

Well, I'm not completely sure, however it seems fairly obvious. I mean the PSL is basically a huge datamine of email addresses. I've had this exact issue with another service I run, they aren't scanning for random email addresses, they were reading from specific services that publicise email addresses.

Some may just crawl GitHub, however that's extremely inefficient and prone to rate limiting, when they could just pull once from https://publicsuffix.org/list/public_suffix_list.dat and scan the entire file for email addresses.

[groundcat]

I think regardless of how spammers collect email addresses, whether by crawling all over GitHub or specifically using the PSL as one of their sources, it seems that the spam emails the requestors received so far are generic fraudulent messages rather than targeted attacks aimed at misleading PSL requestors to make changes to the PSL blocks. This suggests that they are unlikely to change the email subjects to specifically target people listed in the PSL. So, I would still say that implementing (2) and (3) should be sufficient for now, as they are more practical to put in place. We can always reconsider email address-based filtering or an email server solution if both (2) and (3) fail to work.

[simon-friedberger]

Tangentially related: In the future, when we reach out to people, it would be good to CC the psl-discuss mailing list so we can have the discussions in the open and have something to reference.

cc @groundcat @wdhdev @mozfreddyb

[simon-friedberger]

@dnsguru I know you have a lot of personal contacts so the previous suggestion might not always apply but I think it would be good to try.