Agreed, this is going on the list.

+1 would love to see this.

+1 would be very useful!

+1 Yes, this would be very helpful.

👍

I'm not sure if I understand.
Consider a case:

1. Someone sniffing SSL connection. HTTP content is encrypted so he see nothing.
2. However he has access to TCP/IP so he can get address and port of the packet destination
3. he go this address and this port and get all data which was hidden by SSL
   So isn't SSL pointless in mailcatcher?

@dominh Mostly. It would be a little more difficult for the man-in-the-middle if he had to guess the right hostname, in case of a SNI configuration.

This feature makes sense in combination with an additional (basic) auth protection. That could be implemented in mailcatcher as well.

But why not just run a reverse proxy (e.g. nginx) in front of it? That can be configured to do both the SSL termination and basic auth.

This is not for HTTP, but for SMTP over TLS and STARTTLS, for testing your mail settings and libraries.

I agree that reverse proxying from nginx is better for HTTPS, and I wouldn't recommend exposing mailcatcher itself outside a development environment without something else acting as a proxy with authentication. :-)

@dominh: TLS for MailCatcher is about testing only, in ones' dev env, not about real usage (to me at least).

In a prod env, TLS is required. And then it's good to be able to test, in one's dev/test env, that one's app server does work with TLS. For example, with Apache Commons Email, there're config values related to TLS, STARTTLS and SSL and port numbers, and nice to be able to verify that one's config is correct — e.g. by connecting to MailCatcher over TLS.

Hello all,

I have added a new PR #386 tonight using the MidiSmtpServer gem. It will work as expected and allows STARTTLS as well as AUTH on SMTP. All checks have been passed.

Maybe you find this helpful.

Cheers
Tom

Hi,

So isn't this issue a duplicate of #386?

Hi @tfactor2

It is not a duplicate because Samuel @sj26 won't accept the PR #386 from my side (check comment: #386 (comment))

So the issue for mailcatcher is stil open even when the PR had solved that and some other issues as well.

Nothing to wonder about - I am a bit sad about that - but it's Samuels project.

Cheers
Tom

Clear, thanks @TomFreudenberg,

BTW1: We decided to keep using mailcatcher despite the fact that on prod we are using TLS. To really test communication the mail server used for testing should be the same as the prod one. Out of TLS itself, there could be other things that may break, e.g. mismatch of TLS versions/ciphers. So, overcomplicating development configuration is kind of useless.

BTW2: For docker environments, I'd rather go towards standard linux smtp servers (e.g. exim4) and integrate simple webmail, see https://github.com/hauptmedia/docker-mailcatcher. It's quite trivial to add TLS there. IMHO and with all respect to the author of the project as without docker the sj26/mailcatcher it's indeed a very useful tool.