-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Email Spam Prevention #2184
Comments
I think it could be worth setting up an email server on 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. |
@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 One possible approach could be registering an alternative domain like Lastly, we could think about updating the readme.md to mention that emails from the maintainers and the community tend to come from Lines 20 to 22 in 36aa83b
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. |
We could just use a subdomain on the already existing publicsuffix.org. |
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. |
Yeah those last 2 could work. |
Yes, I agree with points 2 and 3, which can easily be implemented by adding them to the |
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:
prvcy.page
contact email #2182 (comment)[email protected]
is not with PSL and "Compliance" emails are not being sent from this project #1849Proposal:
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:
Cons:
@mozilla.org
emails).Proposed Action:
Example Approaches:
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.@volunteer.publicsuffix.example
), which adds complexity and overhead.Individual email addresses: In cases where a dedicated domain is not feasible, we could list individual volunteer email addresses like
[email protected]
.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.
Looking for feedback from the community on how best to manage this process and whether it would be feasible to implement.
The text was updated successfully, but these errors were encountered: