2.4.0-RELEASE: eMail Notifications Do Not Work
-
Hi,
same problem here. Used Gmail, Outlook, and a own email from my domain… same error on all of them
-
gmail : as said above, when setup correctly (as per gmail their instructions) : works.
outlook : dono - depends if they offer standard smtps (port 465) user access, then, yeah, why not.
"own email from my domain" : depends. If YOU setup the mail server then it works when setup correctly - if it is done for you, see their instructions. -
I'm getting a similar issue on my own pfSense box (running 2.4.1-RELEASE on an Atom D2500), with my own mail server. The mail server has STARTTLS enabled on port 587 (but not SSL); if I check "Enable SMTP over SSL/TLS" I get:
Error: Failed to connect to ssl://mail.–---.org:587 [SMTP: Failed to connect socket: fsockopen(): unable to connect to ssl://mail.–---.org:587 (Unknown error) (code: -1, response: )]
If I uncheck it, I get:
Error: Failed to set sender: network@–---.org [SMTP: Invalid response code received from server (code: 530, response: 5.7.0 Must issue a STARTTLS command first)]
I'm not seeing anything helpful in the logs. GMail is capable of sending/receiving from the server just fine on port 587 (because I've set up the setting where I can send as addresses on that host) so AFAIK the mail server configured properly.
I'm having precisely this problem. Looking at a packet capture between the pfSense box and the mail server, I see the mail server issuing what I assume is a request to use STARTTLS ("250-STARTTLS"), but the next response from pfSense starts right in with the "MAIL" command (followed by the from address). The mail server then responds with the error "530 5.7.0 Must issue a STARTTLS command first".
I'll admit to being unfamiliar with precisely how STARTTLS works, but it looks like no attempt is made to negotiate a TLS connection and certificates aren't even coming into play. The mail server also has a valid Let's Encrypt certificate. Am I missing something?
FWIW, I have a couple Synology boxes that have no problem sending mail via this server over port 587 (which should require STARTTLS, as I'm seeing in the exchange with the pfSense box).
Edit: Okay, so I think this is a bug with the test button. If I clear all settings, save, re-enter them, and test, the test email works. If I test again, it fails with the same error as above. It looks like pfSense loses track of the password I entered before hitting the test button the first time (despite filling the field with a generic 8-character password, indicating something is there but wasn't actually provided back to the browser for obvious security reasons). If I save the settings immediately after entering the password but before sending a test email, everything works fine.
-
I agree, entering some values, hit the test button until the test-mail passes, and only then "save" seems more logic.
The text below the test buttonA test notification will be sent even if the service is marked as disabled. The last SAVED values will be used, not necessarily the values entered here.
is quiet clear, though.
-
Hi!
I ran into the same 220 EHLO problem using several mail accounts on serveral servers. I didn't have these problems with pfSense 2.3.x.
The problem looks as if it is related to this: http://php.net/manual/en/migration56.openssl.php with the difference that STARTTLS gets now always used when offered. If one uses an internal MTA then it is unlikely that the certificates, the hostnames, system mail names, and the EHLO names are consistent. In these cases one wouldn't usually need the extra checking.
If my description is accurate, then it could make sense to offer the verify_peer option on the configuration page.
-
Hi!
I ran into the same 220 EHLO problem using several mail accounts on serveral servers. I didn't have these problems with pfSense 2.3.x.
The problem looks as if it is related to this: http://php.net/manual/en/migration56.openssl.php with the difference that STARTTLS gets now always used when offered. If one uses an internal MTA then it is unlikely that the certificates, the hostnames, system mail names, and the EHLO names are consistent. In these cases one wouldn't usually need the extra checking.
You're right.
Back in the past, anyone could use any (mail) server to send a mail to … everyone. No stamps, no delays, the message was delivered without any questions.
However, that 'model' has somewhat changed - some abuse has been detected (a couple of million spams a second these days), rules became more strict.On the other hand, as you already figured out, pfSense uses mail facilities which are are originated form 'PHP' and written so it can be used against any mail server using today's rules, so we, as administrators, actually receive mails from our firewalls.
As you already noticed, the entire Internet switched to "https". For mail transmission - even dropping a mail on a server, ssl is more a must then a maybe. These "certificates, the hostnames, system mail names, and the EHLO names" should be consistent. It's part of our lives now ;)
If my description is accurate, then it could make sense to offer the verify_peer option on the configuration page.
Instead of throwing in an exceptions, isn't it more simple to add a 'valid' certificate and a valid host name ? (better yet : setting up an mail server correctly, even an internal one ?)
-
Well, that's not so easy in many cases.
I have no problems with external MTAs, but I have one setup where the mailserver is used for regular external email (basically port forwarding from pfSense to that box) and for internal email (all kinds of automated messages, like pfSense notifications). The Let's Encrypt certificates work fine from the outside, but locally they don't apply, because the box has a different name. More SAN entries haven't worked for so far, because there is no proper A record to verify the internal address.
From within the LAN, ressources like <external mail="" server="" address="">:25 are not accessible, unless one plays even more with the NAT settings, but that doesn't look very elegant. I haven't figured out yet, whether this is related to my firewall configuation or a problem with the virtual bridges of the hypervisor where all the stuff is running, :-[ ??? …
I have a test script that adds
[code]'socket_options' => array('ssl' => array('verify_peer_name' => false, 'verify_peer' => false)),
to the parameters of the Mail::factory() call, that seems to work. But this is work in progress, so I would not recommend using it.</external> -
From within the LAN, ressources like <external mail="" server="" address="">:25 are not accessible, unless one plays even more with the NAT settings, but that doesn't look very elegant.</external>
Well, that's what host overrides are for.
-
Well, that's what host overrides are for.
So far my attitude was that the resolver is something like a poor man's DNS server, but bingo!
-
…
If the server has an invalid or self-signed certificate, there is not currently a way to trust it for use with notifications. We're working on a fix there but it will not be available for a while yet.any update onto this selgfsigned topic ?
Humm.
Somewhat overlooked that part.
Especially for servers and thus mail server (and pop, imap), there is no need to use non-trusted certs any more. They are there and free these days.
pfSense sends very well mails through my server because I use certs from "Let's Encrypt", which are globally trusted now.I would say :a way to solve the issue is : ditch these self signed certs, and take some "real ones". Certs are not gadgets anymore, they are the bricks that pave the internet-road. Learn how to drive over them.
+1
If you use your own mail server, it's really up to you to use trusted certificates. pfSense can get trusted certificates for free using the Acme package, and it can automatically transfer them to your mail server as soon as the system gets them.
-
Sending notification mail via Amazon AWS SES with the "Enable SMTP over SSL/TLS" set does not work. Clearing this setting does work.
email-smtp.eu-west-1.amazonaws.com port 587
It works but its far from ideal having to turn off TLS.
-
@The:
It works but its far from ideal having to turn off TLS.
It's using StartTLS on port 587 by default, so not an issue.
