Before all that, @parisi could use the configuration I posted above from my own pfSense gateway. (o;
I was just able to test thisâŚ
using port 587 and checked Enable SMTP over SSL/TLS.
Could not send the message to incident3@company.com â Error: Failed to connect to ssl://box.company.net:587 [SMTP: Failed to connect socket: stream_socket_client(): unable to connect to ssl://box.company.net:587 (Unknown error) (code: -1, response: )]
As an FYI we are using
2.4.4-RELEASE-p3 (arm)
built on Thu May 16 06:01:19 EDT 2019
FreeBSD 11.2-RELEASE-p10
The pfSense has its egress on a Comcast provided IP address. These seem to be intrinsically blocked some of the blacklists utilized by MIAB. So, this should be able to be controlled by telling MIAB to not use blacklists for a little while. I am having the same issue via FiOS at another site.
It appears that I am able to get pfSense to send email via MIAB by unchecking both
Secure SMTP Connection
Validate SSL/TLS
and using port 587 and LOGIN
1 Like
Okay, so you were checking boxes I did not state should not be checked. It is the Secure SMTP Connection that was causing your failure.
I tired your settings and they did not work.
I had to uncheck both Validate and SSL
I would think that both should be reasonable to use. I am confused as to why either pfSense or MIAB would have allow these issues to exist.
The MiaB server is not configured to support Secure SMTP connection (it uses STARTTLS for SMTP).
If you are unable to validate the SSL/TLS certificate, then there is an issue with your certificate or, for some reason, pfSense is unable to validate the certificate. If other mail clients connecting to the server do not require certificate validation, then it may be this is the first time you are being made aware of the problem.
1 Like
Ok - regarding this statement âThe MiaB server is not configured to support Secure SMTP connection (it uses STARTTLS for SMTP).â does that mean I have misconfigured it?
Do you mean MiaB is misconfigured? No, MiaB is automatically configured, and that configuration does not include Secure SMPT connection, which someone else would have to explain because I donât know why.
Or do you mean pfSense is misconfigured? pfSense is misconfigured if you have checked the option, only because MiaB does not support that option.
Yes - I meant - did I misconfigure MiaB - which I see you mentioned I did not. So, my question shifts to why doesnât MiaB support Secure SMTP?
So basically, we have two great open source projects that are talking past each other. I am trying to get these both sort of synced up - why wouldnât each have support for what the other things is standard?
I am also going to ask pfSense why they donât work with the MiaB defaults. Right now, I have to turn off all email security in pf to get it working with MiaB.
Projects rarely work âtogetherâ, other than to operate on known standards, such as the IETF provided RFCs. Both pfSense and MiaB are working according to the variously applicable RFCs, so neither of the projects are doing anything wrong.
It is also not clear that MiaB is operating insecurely, as port 587 can still be STARTTLS.
If anything, I believe pfSense has added more security options for email than MiaB.
From the MiaB instructions page in the admin area âŚ
| SMTP Port | 587 |
|---|---|
| SMTP Security | STARTTLS (âalwaysâ or ârequiredâ, if prompted) |
It seems that MiaB REQUIRES STARTTLS, so it is not an option to not use it.
Iâm not sure thatâs what that means. If it is referring to a requirement option on the sending server, then it prevents downgrade attacks, which I think is not the same as MiaB requiring STARTTLS as a receiving server.
I think we need to clarify.
- The difference between SSL/TLS and StartTLS
- The requirements of MIAB
SSL/TLS requires a dedicated port for connections as the client negotiates encryption with the server from the outset. Originally when SSL/TLS was suggested POP3S was given port 995 IMAPS port 993 and SMTPS port 465,
However use of port 465 SMTPS was actually deprecated by the IETF back in 1998. Although many email providers do still use it. Itâs not an RFC approved setup. Instead email submission was to be done over StartTLS on port 587 as opposed to email delivery which was handled on Port 25
StartTLS begins with an insecure connection on a regular port and if the server sends back StartTLS in itâs list of capabilities, the client then sends a StartTLS command indicating that it wants to negotiate SSL/TLS encryption.
Once SSL/TLS negotiation is complete the send continues encrypted.
Why MIAB requires StartTLS to have been negotiated before authentication
MIAB uses Auth Plain or Auth Login to authenticate prior to continuing with the email send. Although the authentication occurs using Base64 - the text is in reality plain text, it takes 2 seconds to convert base64 back to itâs original form as itâs an encoding not an encryption mechanism.
The mail RFCâs are quite specific that plain text username and passwords MUST NOT be sent on an unencrypted channel, therefore if the client attempts to authenticate prior to upgrading the connection then the server sends back an error must use StartTLS
This is different to port 25 email delivery where some receiving servers still arenât configured to use StartTLS so when delivering mail, MIAB will use StartTLS if itâs offered but otherwise will deliver mail to the mail exchanger without encryption.
This has been a helpful discussion and process. Let me make a point I think may need to be made.
I go buy a device (a switch, a network device, a printer, a pfSense, etc.) that has the ability to send email when certain events occur. I think it would be reasonable to expect that those devices should be able to send mail as a client (MUA) in any of the generally accepted ways to send email via a mail server (MSA). Those methods for message submission are (I have excluded open relays):
- Send email via SMTP using Port 25, not TLS, with Authentication
- Send email via SMTP using Port 25, with TLS, with Authentication
- Send email via SMTP using Port 587, not TLS, with Authentication
- Send email via SMTP using Port 587, with TLS, with Authentication
I agree that using port 465 is deprecated but in reality many systems still implement this. Most email sending configuration UIâs have five parameters. Here is an example from The Google:
- Server
- Username
- Password
- Port 25, 465 or 587
- TLS or SSL
I believe that TLS implies STARTTLS.
Thoughts?
For some older dialogs TLS was indeed mislabelled - Indeed Outlook did the same thing up until Outlook 2016
In the above dialog
SSL = SSL/TLS
TLS = StartTLS
However the important thing to realise is that when using port 465, TLS is regarded as implicit in that the server requires that the client negotiates encryption details before it will send any data.
Connections through port 587 (or even 25) are use Explicit TLS in that situation the server announces that it suports StartTLS and then the client explicitly sends the StartTLS command to which the server sends OK and then waits for the client to negotiate the encryption details.
1 Like