testcontainers-dotnet
testcontainers-dotnet copied to clipboard
testcontainers
[Feature]: Module for MailHog container for integration testing SMTP clients
Problem
Most of web applications need somewhat sending emails. MailHog is good choice SMTP for integration testing for sending emails. ( It also has API for checking whether email is sent or not) But it has drawback that it does not support SMTP over TLS under the hood.(Users of MailHog use proxy (e.g. stunnel) for eliminating this issue AFAIK)
Solution
We can create module for MailHog and encapsulate SSL logic inside this module. Users may decide whether they are want to use SSL or not through configuration. I’m planning to contribute this module what do you think about it?
Benefit
Users easily use this module for integration testing for SMTP mail sending
Alternatives
Users can use other docker images rather than MailHog or they may want to configure MailHog container themselves without using module
Would you like to help contributing this enhancement?
Yes
Hi 👋 did you try the existing Papercut (1, 2) module? I think both are very similar, although I do not know if they share/support the same features.
Sorry my bad I didn't see Papercut module but it does not support SSL also if I am correct but I think adding extra SMTP server module while Papercut exists seems redundant. Thank you for your response
A few days ago, I came across stalwartlabs/mail-server or Mailpit, another mail servers that supports various features, which could be alternatives. I think we can offer multiple modules for the same/similar services, as we do with databases. However, I would prefer to consolidate and prioritize support for established providers rather than incorporating all kinds of providers. For simpler modules, developers can always fall back to the generic builder API (MailHog seems quite established, though).
@HofmeisterAn whether or not the repo of the SMTP server is active is important for the priorization process? It seems there is no active development for the mailhog repo (source).
@HofmeisterAn whether or not the repo of the SMTP server is active is important for the priorization process? It seems there is no active development for the mailhog repo (source).
I think that is a good point. I am happy to continue with Mailpit (finalize and merge the PR). I simply wanted to share the PR for transparency, ensuring that developers are not working on similar modules, and making sure we choose an implementation that covers most use cases.