The pfSense Store

Author Topic: 2.4.0-RELEASE: eMail Notifications Do Not Work  (Read 1299 times)

0 Members and 1 Guest are viewing this topic.

Offline Fesoj

  • Full Member
  • ***
  • Posts: 254
  • Karma: +6/-1
    • View Profile
Re: 2.4.0-RELEASE: eMail Notifications Do Not Work
« Reply #15 on: December 29, 2017, 03:05:36 am »
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.

Offline Gertjan

  • Hero Member
  • *****
  • Posts: 2307
  • Karma: +174/-9
    • View Profile
Re: 2.4.0-RELEASE: eMail Notifications Do Not Work
« Reply #16 on: December 29, 2017, 04:30:25 am »
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 ?)

Offline Fesoj

  • Full Member
  • ***
  • Posts: 254
  • Karma: +6/-1
    • View Profile
Re: 2.4.0-RELEASE: eMail Notifications Do Not Work
« Reply #17 on: December 29, 2017, 05:09:38 am »
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: [Select]
'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.

Offline Grimson

  • Full Member
  • ***
  • Posts: 260
  • Karma: +36/-2
    • View Profile
Re: 2.4.0-RELEASE: eMail Notifications Do Not Work
« Reply #18 on: December 29, 2017, 05:35:08 am »
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.

Well, that's what host overrides are for.

Offline Fesoj

  • Full Member
  • ***
  • Posts: 254
  • Karma: +6/-1
    • View Profile
Re: 2.4.0-RELEASE: eMail Notifications Do Not Work
« Reply #19 on: December 29, 2017, 06:42:40 am »
Quote
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!

Offline robi

  • Hero Member
  • *****
  • Posts: 998
  • Karma: +77/-2
    • View Profile
Re: 2.4.0-RELEASE: eMail Notifications Do Not Work
« Reply #20 on: December 30, 2017, 08:36:19 am »
...
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.