pfSense cannot send email using MIAB

This is where email server admins need to stop and pause. It’s one thing to have an “easy to run” email server, and kudos to Josh for all his hard work. BTW but understanding email concepts is important.

Email servers shouldn’t be run for example on IP address ranges that are allocated by DHCP - this is because even if they don’t change very often (and I’ve had my current Virgin Media cable IP for over a year now), they MAY change.

To that end email reaching Mail exchangers SHOULD NEVER come from one of these IP addresses.

This has prompted the creation of a number of Policy Blacklists which include as many known DHCP allocated IP ranges as possible. Two of the most well known are:

Spamhaus PBL
SORBS DUHL

Note that if you are on the PBL you will also be included in Spamhaus’ Zen blacklist which is a master list of all the different zones that they have, this enables mail exchanger admins to make one single query that covers all Spamhaus’ blacklists.

Email programs aren’t affected as most mail clients talk to dedicated email servers that authenticate the connection via different means before accepting the email.

Edit - Indeed even MIAB treats mail coming on on port 25 differently to mail coming in on port 587 for precisely this reason, in the former it’s acting as a mail exchanger, in the latter it’s acting as a submission server.

You did see the part where the OP stated the MiaB is on Linode, and the offending IP address is the one assigned to the pfSense gateway network device?

I am actually confused about what email address pfSense is using to send email, because the IP address of a MUA (which is effectively what pfSense uses), should not impact mail, and the Spamhaus page seems to communicate that mail has to be proxied through Comcast. I’ve got an information gap some place.

1 Like

I had been using a Gmail account for sending messages from my pfSense gateway, so after reading this post I decided to use an MiaB address.

Here are the key settings I have configured for this to work:

SMTP Port of E-Mail server: 587
Validate SSL/TLS: check
Notification of E-Mail auth mechanism: LOGIN (also works with PLAIN)

Be sure to save before clicking Test SMTP Settings.

Although Spectum is far superior to Comcast because it does not put my IP address on any blacklists, pfSense is only behaving as a MUA, so MiaB should not be concerned about blacklisted IP address access for clients.

I missed this part although if you look at my post it does explain the reason. When did MIAB start using Spamhaus BTW?

It you have a look at this part of what I posted it explains why he’s being blacklisted.

First thing @parisi could do is have a look at Pfsense to see if there’s any updates to allow it to send using Port 587. Alternatively there are two possibilites I could think of.

  1. Configure postfix to accept mail on port 465 SSL/TLS
  2. Set up Stunnel on the server to tunnel connections from port 465 SSL/TLS to port 587 StartTLS.

Tim

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):

  1. Send email via SMTP using Port 25, not TLS, with Authentication
  2. Send email via SMTP using Port 25, with TLS, with Authentication
  3. Send email via SMTP using Port 587, not TLS, with Authentication
  4. 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