Mail-Notifications not working

[ehj-52n]

When testing the notification settings, I receive an error message:

Could not send the message to user@example.com -- Error: Failed to connect to ssl://mail.example.com:587 [SMTP: Failed to connect socket: fsockopen(): unable to connect to ssl://mail.example.com:587 (Unknown error) (code: -1, response: )]

According mailserver log:

Nov  8 11:12:31 mail postfix/submission/smtpd[9371]: connect from unknown[fw-WAN-IP]
Nov  8 11:12:31 mail postfix/submission/smtpd[9371]: lost connection after UNKNOWN from unknown[fw-WAN-IP]
Nov  8 11:12:31 mail postfix/submission/smtpd[9371]: disconnect from unknown[fw-WAN-IP] unknown=0/1 commands=0/1

I used the following settings:

• Mail-Server: mail.example.com
• Port: 587
• Connection timeout: default
• Secure Connection: [X]
• Validate SSL: [X]
• From: root@example.com
• To: ehj-52n@example.com
• User: valid-smtp-username
• Password: **********
• Auth Mechanism: PLAIN|LOGIN (← both result in the same error!)

Testing the connection between pfsense and the mailserver using Test Port returns the following message:

220 mail.example.com ESMTP Postfix (Debian/GNU)

What should I do to get mail notifications working?

[viragomann]

@ehj-52n
I assume, you should uncheck "Secure SMTP Connection". The server will use STARTTLS, so there is no need for that option.

[ehj-52n]

@viragomann Thank you very much for your fast response, but I did not solve my problem.

The resulting error message is:

Could not send the message to ehj-52n@example.com -- Error: Failed to set sender: root@example.com
[SMTP: Invalid response code received from server (code: 530, response: 5.7.0 Must issue a STARTTLS 
command first. For assistance, mail to it-support@example.com Please provide the following information
in your problem report: time (Nov 08 12:17:06), client (my.ip.example.com:44089) and server (mail.example.com).)]

[viragomann]

@ehj-52n
"Validate SSL/TLS" is still checked?

[ehj-52n]

@viragomann yes

[viragomann]

@ehj-52n
So don't know, what the server error message want to tell us.
pfSense sends a STARTTLS command automatically, when the server provides this option. But there is no way to force STARTTLS in the settings.
Hence I suspect the server doesn't offer it.
You may check that using Telnet or something similar.

Maybe the server provides an additional SSL protocol on another port?

[ehj-52n]

@viragomann

When telnetting to the server, after EHLO the following options are provided:

250-PIPELINING
250-SIZE 50000000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING

[viragomann]

@ehj-52n
So STARTTLS is offered by the server.

The only reason I can think of, for not sending STARTTLS command in this relation, is that pfSense cannot verify the servers TLS cert for any reason.

Is this an updated version of pfSense?

[ehj-52n]

@viragomann

I have two versions of pfsense avialable, that are tested:

• Software firewall: 2.5.2-RELEASE
• Hardware firewall: 2.4.5-RELEASE-p1

[Gertjan]

@ehj-52n said in Mail-Notifications not working:

Secure Connection: [X]

In that case, it isn't (shouldn't) be port 587 - but port 465.

If you have access to the mail server, you should have port 587 which start 'in clear', and after a STARTTLS is issued from the client, the connections switches over to TLS (SSL).

Port 465 is like 587 (called submission), asks for authentication etc but everything from bit 0 will by TLS encrypted.

This is a classic 'gmail' setup :

(but, be careful, it might be possible that gmail won't accept connection from an 'unknown' device - mail client like 'pfsense'. See your gmail / Google security settings)

You could even consider abbandning port 587 usage, because you control your won devcies, right ? Make them use port 465 (SSL only) and stop having port 587 being used = open to the internet. It's just 'one risk less' to handle.
Delivering mails from a client to a mail server is all 'port 465' these days. Nothings goes (shouldn't) out in the open any more.
Very comparable to what happened to 'http' : it's game over. It's https now.

: be careful with this one.

The certificate the (your !) mail server is using should be recognized as valid, like a Letsenscrypt certificate. A self signed cert will fail.
I'm using Letenscrypt certs for my Debian + postfix mail server, works great.