cancel
Showing results for 
Search instead for 
Did you mean: 

SMTP Proxy to Office 365

huzer1
Nimbostratus
Nimbostratus

I'm trying to setup a proxy for SMTP going to smtp.office365.com. I've searched for SMTP documentation, the only one I've come across is quite dated with a version cap of 13.0. But using this as a reference I've come up with a basic config.

 

So far, the only connection I've been able to get to o365 is with a client SSL profile, and the default SMTPS profile. Unfortunately this always ends with the server (o365 smtp) replying back with STARTTLS is required to send mail. Running the same test to smtp.office365.com directly works as it should.

 

ltm virtual smtp.example.com_587 {     creation-time 2022-01-12:11:16:46     destination 10.0.0.12:submission     ip-protocol tcp     last-modified-time 2022-01-13:16:47:35     mask 255.255.255.255     pool smtp.office365.com_587     profiles {         smtp.example.com {             context clientside         }         smtps { }         tcp { }     }     serverssl-use-sni disabled     source 0.0.0.0/0     source-address-translation {         type automap     }     translate-address enabled     translate-port enabled     vs-index 12 }

The pool for this has quite a few members and is a bit long to list here. The members are simply the FQDN of smtp.office365.com

 

 

The reason behind a setup this way is to prevent having an SMTP server locally, but allowing things that don't normally have internet access the ability to send email.

3 REPLIES 3

Just did a test myself, and it seems to work without a client SSL profile and without the default SMTP profile.

 

ltm virtual vs_smtp.office365.com { creation-time 2022-01-14:14:51:58 destination 192.168.178.200:smtp ip-protocol tcp last-modified-time 2022-01-14:14:58:00 mask 255.255.255.255 pool pool_smtp.office365.com profiles { f5-tcp-progressive { } } serverssl-use-sni disabled source 0.0.0.0/0 source-address-translation { type automap } translate-address enabled translate-port enabled vlans { VM_Network } vlans-enabled vs-index 12 }

And here the output of a basic test:

 

$ telnet 192.168.178.200 25 Trying 192.168.178.200... Connected to 192.168.178.200. Escape character is '^]'. 220 AM4PR0501CA0048.outlook.office365.com Microsoft ESMTP MAIL Service ready at Fri, 14 Jan 2022 13:58:47 +0000 ehlo van-sluis.nl 250-AM4PR0501CA0048.outlook.office365.com Hello [82.174.94.206] 250-SIZE 157286400 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-8BITMIME 250-BINARYMIME 250-CHUNKING 250 SMTPUTF8 quit 221 2.0.0 Service closing transmission channel Connection closed by foreign host. $

It seems smtp.office365.com requires STARTTLS, see: https://support.microsoft.com/en-us/office/pop-imap-and-smtp-settings-8361e398-8af4-4e97-b147-6c6c4ac95353. The email client should take care of this itself.

huzer1
Nimbostratus
Nimbostratus

Hello Niels and thanks for your reply. I too am able to get this to connect without using a clientssl profile, however powershell scripts don't like this. When connecting with the following powershell script.

Send-MailMessage -UseSsl –to "user@example.com" –from noreply@example.com –subject "testing456" –body "this is a secure test" –smtpserver "smtp.example.com" -port 587 -Credential $cred

If there's no client ssl profile it will immediately fail with a "Send-MailMessage : The remote certificate is invalid according to the validation procedure." error.

 

So adding a clientssl to the profile and running the script again results in a "Send-MailMessage : Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host." error. A quick wireshark of this shows the f5 sending a reset packet with the reason [F5RST: SSL handshake timeout exceeded]

 

So now, I add in the SMTPS profile, rerun the script and I get an error returned of "Send-MailMessage : Error in processing. The server response was: 5.7.3 STARTTLS is required to send mail [CH0PR13CA0009.namprd13.prod.outlook.com]" Looking at a wireshark of this, it appears the STARTTLS is sent from the client to the f5, but the f5 never actually relays this to the o365 server (packet 17). See the following screen shots

0691T00000F92zFQAR.png0691T00000F9336QAB.pngI think it's also noteworthy that you can't initiate STARTTLS with telnet. I've been using openssl.

openssl s_client -starttls smtp -crlf -quiet -connect smtp.example.com:587

 

The issue is with the certificate. Remove the client certificate from the virtual server. And make sure Send-MailMessage ignores the certificate.

$credential = Get-Credential   [System.Net.ServicePointManager]::ServerCertificateValidationCallback = { return $true }   Send-MailMessage -to *****@hotmail.com -from *****@hotmail.com -subject "test" -body "this is a test" -smtpserver "192.168.178.200" -port 587 -usessl -Credential $credential