Cannot send mails using office365 smtp server

[NOYB]

From my little bit of testing here it seems that the "Enable SMTP over SSL/TLS" setting only works with port 465 (SMTPS), and does not work if port 587 is specified.

My mail server has the same SSL/TLS configuration for both port 465 and 587.  But pfSense notification only works with SSL/TLS enabled if port 465 is specified.  And not with port 587.

This will probably limit your ability to use SSL/TLS with smtp.office365.com unless it listens on port 465.
Try port 587 with and without STARTTLS enabled.

[arrmo]

Hi,

Port 587 is the specified port (and I confirmed, port 465 is not available / open). Interesting point about the password - thanks!

I tried different settings (all port 587), here is what I get …

1. Enable SMTP over SSL/TLS -> Error: could not connect to the host "smtp.office365.com": ?? (and fails very quickly)
2. Enable STARTTLS -> Error: 504 5.7.4 Unrecognized authentication type (takes longer to fail)

So the connection seems to be happening, but different failure modes? Thoughts?

Thanks!

[NOYB]

What do you get using port 587 with no encryption?

[NOYB]

Did a little more digging and it seems that the pfSense notification system SSL/TLS setting only supports wrapper mode, with no way to disable it other than using Start TLS.

So if the server, smtp.office365.com, in this case doesn't support ether wrapper mode or Start TLS, then there is no way to use it with encryption.

[arrmo]

Hi,

It's supposed to support Start TLS - at least from the digging I can do. So I admit, still a bit confused why it won't connect … :(.

I have had issues in the past though (with other email servers, like Verizon), needing to use stunnel. Have you seen this before as well? I tried to install Stunnel, but get the error message "ERROR: No digital signature!". Is this something that needs to be updated / added in v2.2?

Thanks!

[NOYB]

From your earlier post it looks like the connection is successful with STARTTLS enabled.  But the authentication is failing.

"2) Enable STARTTLS -> Error: 504 5.7.4 Unrecognized authentication type (takes longer to fail)"

Google that error code and message string and you'll find lots of information that may point you in the right direction.

[arrmo]

Hi,

Yep, looked that error message up, and contacted (Microsoft) Exchange Online support. The one open question they have, that I can't seem to find … is pfSense using TLS v1.1 for the email send? They think that's the problem, but I can't confirm the version.

Does anyone happen to know?

Thanks!

[VoosW]

The problem is not exactly with Office 365 Mail servers - rather with Exchange (and potentially other mailservers as well):

While researching the issue that pfSense won't send using our Exchange 2010 Server I found the underlying cause for it.

pfSense (our version is 2.1.5-RELEASE, but I guess other versions are also affected) seems to support several Authentication mechanisms for SMTP (at least that's what I gathered from the various files), but it ALWAYS uses "PLAIN".
If the E-Mail-Server does not support "PLAIN", E-Mail-Notifications will fail - typically with "Authentication mechanism not supported".
Now - guess what … Exchange does support plaintext-logins when configured correctly, but only using the method "LOGIN" ...

The culprit is in File /etc/inc/notices.inc , Line 324:
    // Use SMTP Auth if fields are filled out
    if($config['notifications']['smtp']['username'] &&
      $config['notifications']['smtp']['password']) {
        $smtp->authentication_mechanism = "PLAIN";
        $smtp->user = $config['notifications']['smtp']['username'];
        $smtp->password = $config['notifications']['smtp']['password'];

if I change this line to
$smtp->authentication_mechanism = "LOGIN";
I can send e-mail-notifications via our  Exchange-Server. But I guess this will break Notifications for other mailservers.

IMHO there are two ways to fix this behaviour (sadly both beyond my pfSense/php-Knowledge):

1. get the list of supported auth-mechanisms from the server (after doing TLS if necessary - some servers offer plaintext-login only after a secue session was established) and "match" with local supported mechanisms (perhaps the smtp-class allows this already)?
2. allow the admin to select the auth-mechanism from a list of mechanisms supported by pfsense

[arrmo]

Hi,

Very cool finding - awesome! I'll give it a try (manual change), but also … why not start with 2), try 1) later? At least 2) would get things up and running.

Thanks!

[Cacique]

I had the same problem Authenticating but with Symantec Messaging Gateway (SMG). Changing PLAIN with LOGIN solve it. Thanks!

@VoosW:

The problem is not exactly with Office 365 Mail servers - rather with Exchange (and potentially other mailservers as well):

While researching the issue that pfSense won't send using our Exchange 2010 Server I found the underlying cause for it.

pfSense (our version is 2.1.5-RELEASE, but I guess other versions are also affected) seems to support several Authentication mechanisms for SMTP (at least that's what I gathered from the various files), but it ALWAYS uses "PLAIN".
If the E-Mail-Server does not support "PLAIN", E-Mail-Notifications will fail - typically with "Authentication mechanism not supported".
Now - guess what … Exchange does support plaintext-logins when configured correctly, but only using the method "LOGIN" ...

The culprit is in File /etc/inc/notices.inc , Line 324:
    // Use SMTP Auth if fields are filled out
    if($config['notifications']['smtp']['username'] &&
      $config['notifications']['smtp']['password']) {
        $smtp->authentication_mechanism = "PLAIN";
        $smtp->user = $config['notifications']['smtp']['username'];
        $smtp->password = $config['notifications']['smtp']['password'];

if I change this line to
$smtp->authentication_mechanism = "LOGIN";
I can send e-mail-notifications via our  Exchange-Server. But I guess this will break Notifications for other mailservers.

IMHO there are two ways to fix this behaviour (sadly both beyond my pfSense/php-Knowledge):

1. get the list of supported auth-mechanisms from the server (after doing TLS if necessary - some servers offer plaintext-login only after a secue session was established) and "match" with local supported mechanisms (perhaps the smtp-class allows this already)?
2. allow the admin to select the auth-mechanism from a list of mechanisms supported by pfsense

[arrmo]

Hi,

If you don't mind me asking - what are the rest of your settings (like port number, SSL/TLS or STARTTLS, etc.)? Still struggling a bit.

Thanks!!!

[arrmo]

Got it working! Issue was STARTTLS (and save before Test).

Thanks!

[andygorze]

This also fixed my issue, many thanks.

[creiglee]

for this issue I added my account via POP3 and SMTP in outlook 2016 it works fine and also I test it via power shell and It works fine too.

[bethelcolonyit]

E-Mail server: smtp.office365.com
SMTP Port of E-Mail server: 587
Connection timeout to E-Mail server: blank
Secure SMTP Connection: unchecked
From e-mail address: user@example.com
Notification E-Mail address: user@example.com
Notification E-Mail auth username (optional): user@example.com
Notification E-Mail auth password: userpassword
Notification E-Mail auth mechanism: Login
Send Test
Save after successful test

[vishal.mhatre2310]

@bethelcolonyit. Helped in big way. Thank you so much for the poast

[SteveITS]

I know this is old but it was a top search result.

The good news, there are 3 methods:
https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365

The bad news: the purple note in section 1 (info on using a login and password) on that page:
"This option is not compatible with Microsoft Security Defaults or multi-factor authentication (MFA). If your environment uses Microsoft Security Defaults or MFA, we recommend using Option 2 or 3 below.

You must also verify that SMTP AUTH is enabled for the mailbox being used. See Enable or disable authenticated client SMTP submission (SMTP AUTH) in Exchange Online for more information."