Summary. Platforms that let users self-register mail addresses or aliases often have no blocklist of reserved names, so anyone can claim support@, security@, info@ or no-reply@ on the domain. That makes low-noise phishing easy and opens a quiet data-exposure path, as users who report bugs or request password resets may send sensitive details straight to whoever claimed the alias. Reserving the organisationally significant names before offering open mail hosting closes the gap.
Background
Many companies and public authorities offer their own mail hosting or at least address forwarding for interested users, which is a reasonable feature on its own. The problem is that, in most setups I've seen, there is no blocklist of reserved aliases. Anyone can register helpdesk@, support@, security@, contact@, info@, or no-reply@ on a domain that allows self-service addresses.
That makes targeted, low-noise phishing considerably easier: a message from support@yourcompany.com reads as legitimate to most recipients. It also creates a quieter data-exposure path: a user who spots a bug on the platform and emails info@ or kontakt@ to report it may be sending sensitive details straight to whoever happened to claim that alias. A user who forgets their password and emails a plausible-looking contact@ address could receive a convincing reply with a link to a lookalike password-reset page, handing their new password to an attacker in plain text before it's ever relayed to the real service.
Recommendation
Block the aliases listed in RFC 2142 and any other organizationally significant name (admin, helpdesk, support, security, and so on) from self-registration before offering open mail hosting or aliasing to users.