-
Notifications
You must be signed in to change notification settings - Fork 578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSL/TLS connection #142
Comments
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.
|
@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 |
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 |
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. |
It would be great if secure connections could also be tested.
The text was updated successfully, but these errors were encountered: