Request for Chaos Monkey-like Feature in Mailpit

[endelwar]

I recently migrated from MailHog to Mailpit and I've been missing a particular feature called "Jim the Chaos Monkey" that is available in MailHog. Jim allows for the testing of unexpected behaviors in applications by randomly triggering various actions within defined parameters. I believe implementing a similar Chaos Monkey-like feature in Mailpit would greatly enhance its testing capabilities.

Feature Request Details:
Jim the Chaos Monkey performs the following actions randomly, but within specified parameters:

• Reject connections
• Rate limit connections
• Reject authentication
• Reject senders
• Reject recipients

These actions are valuable for testing the resilience and fault tolerance of applications. By simulating unexpected scenarios, developers can proactively identify and address potential issues before they cause problems in production.

I kindly request the implementation of a Chaos Monkey-like feature in Mailpit with similar functionalities to Jim. This addition would significantly improve the testing capabilities of the application and allow for more robust and reliable email delivery.

Thank you for considering this feature request. Please let me know if you require any additional information or clarification.

Link to the original MailHog's Jim documentation: Jim the Chaos Monkey

[axllent]

This has been discussed in #110 with a proposed alternative approach, however I did not get any response to my technical questions so the issue became stale and got automatically closed. The problem here is that I believe there is only a very small number of users who want/use this solution, it requires a lot of work to implement, and if it got implemented it wouldn't do everything on your list. Mailhog uses a complete custom implementation of the SMTP "server" which gives it much more control over things like rate limiting as well as rejection, but this also makes Mailhog's SMTP much slower, and (I don't believe) entirely compliant. I chose not to reinvent the wheel and use an existing SMTP solution, and speed.

My proposal in #110 was the ability to manually turn on/off some forms of rejection (though not everything you listed) instead of randomly. It is still complicated though, so very low on my priority list. Please have a look at the previous issue I mentioned, and let me know what you think?

[github-actions]

This issue is stale because it has been open for 21 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 7 days since being marked as stale.