Hi @davidhuser, thanks for mxmap — the domain resolution across ~2,100 municipalities is impressive and reusable beyond mail.
Proposal (an idea, not a commitment to build it): would you be open to adding a security.txt (RFC 9116) signal — whether each municipality's domain publishes a /.well-known/security.txt advertising a vulnerability-disclosure contact?
It fits mxmap's posture angle, and reuses assets you already have (the per-BFS domain in data.json and your concurrent-probe architecture), so the marginal cost looks small.
Rough shape, fully open to your preference: a probe checking canonical /.well-known/security.txt over HTTPS with a legacy /security.txt fallback, recording a status like absent | present | valid | expired (optionally parsed Contact / Expires), surfaced as a securitytxt field in data.json and an optional frontend toggle recolouring the choropleth.
A few questions before any code: is this in scope, or would you rather stay mail-focused? Extra field in data.json or a separate file? Same map with a toggle, or a separate layer?
For context, I'm exploring a security.txt map of Swiss municipalities for my site (dcod.ch), so I'd likely build such a probe anyway and would rather contribute upstream than fork.
To be clear, this is a suggestion rather than a promise to deliver it — but I'd gladly help scope it or contribute a PR if there's interest. Thanks!
Have a nice evening, Marc
Hi @davidhuser, thanks for mxmap — the domain resolution across ~2,100 municipalities is impressive and reusable beyond mail.
Proposal (an idea, not a commitment to build it): would you be open to adding a
security.txt(RFC 9116) signal — whether each municipality's domain publishes a/.well-known/security.txtadvertising a vulnerability-disclosure contact?It fits mxmap's posture angle, and reuses assets you already have (the per-BFS
domainindata.jsonand your concurrent-probe architecture), so the marginal cost looks small.Rough shape, fully open to your preference: a probe checking canonical
/.well-known/security.txtover HTTPS with a legacy/security.txtfallback, recording a status likeabsent | present | valid | expired(optionally parsedContact/Expires), surfaced as asecuritytxtfield indata.jsonand an optional frontend toggle recolouring the choropleth.A few questions before any code: is this in scope, or would you rather stay mail-focused? Extra field in
data.jsonor a separate file? Same map with a toggle, or a separate layer?For context, I'm exploring a security.txt map of Swiss municipalities for my site (dcod.ch), so I'd likely build such a probe anyway and would rather contribute upstream than fork.
To be clear, this is a suggestion rather than a promise to deliver it — but I'd gladly help scope it or contribute a PR if there's interest. Thanks!
Have a nice evening, Marc