Open groundcat opened 1 month ago
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.
@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.
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.
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.
- 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.
- 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.
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:
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:
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
jane.doe@example.com
.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.