As with most vulnerabilities, there is no universal solution to prevent SMTP injection. This is especially true in this case because there are many situations and environments where SMTP injection can occur. However, there are strategies that we can broadly apply to help prevent SMTP injection:

• The best way to avoid a vulnerability is to avoid creating conditions where the vulnerability can occur in the first place. This isn’t always possible or practical, but it’s very effective when it is. For example, a website might opt to provide an email address for feedback but not a built-in form, requiring users to use their own email to send feedback.
• If you have to create SMTP requests based on the user’s input, there are steps we can take to reduce the risk of injection. Firstly, you should research the best practices for sending emails in your programming language. It would help if you also researched what solutions are available for your environment and language, ideally choosing open-source, actively maintained, and secure.
• You should add an additional layer of security by sanitizing the user’s input used to generate the SMTP requests. Input Sanitization ensures that no dangerous characters are present in the input provided by the user (this is easy to get wrong in practice). The general best practice is to use a list of allowed characters rather than a list that should not be allowed. Inputs that contain characters not present in the allowed list can be rejected or modified by having the offending characters removed or escaped. Input sanitization should always be done server-side and not client-side.
• We can use firewalls to provide yet another layer to our defense, such as blocking SMTP requests from our server that are sent to servers outside the organization’s network. This shouldn’t be the only line of defense, but it’s one more layer of security you can add on top of other solutions.