so it was a lot of individual typos, not a single big one, but they are appearantly pretty common.
up until now the domain management was outsourced to some commercial company from netherland, which tried to alert US DOD to the problem.
but in near future it is expected the control of the domain to be transferred under the control of local military junta, which can lead to these mails being stored and sold to higher bidder, or some similar fun stuff.
no kidding, that’s the kind of thing that after the first few times it happens, someone from product should flag this and build in a system with redundant checks if you want to send mail to .ml, like:
The user has to have permission to send to .ml in the first place
Any individual .ml address they want to send to has to be whitelisted in a separate UI from email compose (possibly excluding replies)
Any time they send to .ml (or any external domain), the recipient box turns a different color, and there’s a notice, CURRENTLY SENDING TO AN EXTERNAL DOMAIN
with a list of all external domains included eg you could also be sending to a contractor
and a count of the domains
Any .ml sent mail is auto delayed by a couple minutes and requires you to confirm you wanted to send it (again possibly excluding replies)
I would hope there’s also some flags emails can have for whatever sensitive info levels, these should also come with automatic client-side and server-side validation that you’re not sending them to someone who you shouldn’t.
top level domains .mil vs .ml
so it was a lot of individual typos, not a single big one, but they are appearantly pretty common.
up until now the domain management was outsourced to some commercial company from netherland, which tried to alert US DOD to the problem.
but in near future it is expected the control of the domain to be transferred under the control of local military junta, which can lead to these mails being stored and sold to higher bidder, or some similar fun stuff.
it’s wild to me that .ml isn’t a blocked domain by default for most military contractors and employees
no kidding, that’s the kind of thing that after the first few times it happens, someone from product should flag this and build in a system with redundant checks if you want to send mail to .ml, like:
The user has to have permission to send to .ml in the first place
Any individual .ml address they want to send to has to be whitelisted in a separate UI from email compose (possibly excluding replies)
Any time they send to .ml (or any external domain), the recipient box turns a different color, and there’s a notice, CURRENTLY SENDING TO AN EXTERNAL DOMAIN
Any .ml sent mail is auto delayed by a couple minutes and requires you to confirm you wanted to send it (again possibly excluding replies)
I would hope there’s also some flags emails can have for whatever sensitive info levels, these should also come with automatic client-side and server-side validation that you’re not sending them to someone who you shouldn’t.
Sounds like a .us tld would’ve saved them some headache.
not sure about that… 😂