Email Security policies

[dotBATmanNO]

What: js.org and (many of) its subdomains fail to restrict attackers from sending fraudulent e-mails.

Why: The main js.org domain has a DMARC policy of "none" Subdomains, such as npm.js.org, fail to specify both SPF and DMARC

Impact Fraudulent e-mails can have an impact on

• Integrity; The attackers can exploit the trust js.org (and subdomains) holds with all of the contributors, this trust could deteriorate.
• Availability; Sites that have been abused for spam or phishing will be blocked in spam filters, this could trigger the domains to be blocked by firewalls as "malicious".

More information: A lot of resources offer strong advice on e-mail security policies, One such service is https://internet.nl

• Tests: https://internet.nl/mail/js.org/1609358/, https://internet.nl/mail/npm.js.org/1609360/
• Knowledge base: https://internet.nl/faqs/mailauth/

[MattIPv4]

👀 I don't believe we allow any MX records, and therefore any mail, on JS.org subdomains. I wonder if we should add a wildcard record for SPF/DMARC to indicate as such, @indus?

[indus]

@MattIPv4 you are correct - there are only a very small number of adresses to receive email but not to send.

I have just added those two records to JS.ORGs zonefile:

Type	Name	Value
TXT	@	v=spf1 -all
TXT	_dmarc	v=DMARC1; p=reject; pct=100; rua=mailto:re+···········@dmarc.postmarkapp.com; sp=reject; aspf=s;

I confirmed that [email protected] still receives emails, but I’m not entirely sure how to verify that this change fully resolves the security issue. Since I don’t have deep knowledge of the subject (and honestly don’t want to go through all the reference material), I’ll have to rely on AI—or your judgment, @dotBATmanNO.

[dotBATmanNO]

Thanks for a very fast response to this Issue, apologies for the late reply.

First:

• You are stepping up DMARC to a very strong level, this will impact outgoing email - hopefully only spoofed email. This should not be a problem if you do not send emails from here.
• DMARC is setup to allow hardening over time, a recommended approach is to go from p=none through p=quarantine before you end up at p=reject.
• Also, the best practice is to step up the pct from 0 to 100 in increments as long as the DMARC reports are not indicating any legitimate emails being rejected.

With that said, if you are not worried about blocking any outbound emails, I want to note that the new TXT record for _dmarc is enveloped in curly brackets { }, this unfortunately invalidates the record. If you remove those you should have a much stronger set of email policies in place.

Please let me know if I can assist in any other way. And thanks again for your prompt response!

[indus]

@dotBATmanNO Thanks for your help with this. Regarding your first points - there are no outbound emails at all. So to my understanding going to the strictest settings directly shoudl be fine.

I can't really explain why you have seen curly brackets. But I just noticed that I had two _dmarc records in the zonefile - maybe thats the reason. I've now changed that and regarding this tool it should be fine: https://mxtoolbox.com/SuperTool.aspx?action=dmarc%3ajs.org&run=toolpage

Thanks for pointing me to this issue.

[dotBATmanNO]

I see the policies in place and working now. Super! (The "curly brackets" I mentioned was my script returning an array of two _DMARC records which, as you noticed, is not supported.)

With your new DMARC policy in place I would recommend looking at the Cloudflare DMARC console if there are any reported issues.

You should see reports of anyone trying to send emails from js . org.

• Visibility into abuse: The DMARC console will let you know if someone is trying to spoof your domain.
• Feedback loop: If legitimate services accidentally send email using your domain (e.g., misconfigured third-party tools), you will be alerted and can correct the issue

[indus]

@dotBATmanNO informed me via email that the new setup is still insufficent when it comes to subdomains:

Problem

• Stronger email security policies for js.org don’t apply to subdomains → open to abuse.
• Cloudflare DMARC management only supports apex domains.
• SPF records aren’t inherited → must be set per subdomain.

Proposal

• Keep DMARC on apex.
• Remove inherited subdomain policy.
• Add SPF + DMARC individually per subdomain

As this would require an automatic process to keep the overhead reasonable I put this on hold for now.