Forum Discussion
huzer1
Nimbostratus
NimbostratusSMTP Proxy to Office 365
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.
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.
huzer1Hello 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 $credIf 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
I 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:587The 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
rachelgomez23The configuration you have provided seems to be a virtual server configuration for SMTP proxying to smtp.office365.com. However, it appears that you are encountering an issue with STARTTLS not being supported by the server.
To enable STARTTLS for your SMTP proxy, you may need to add a configuration to negotiate TLS encryption with the destination server. Here's an updated configuration snippet that includes the STARTTLS option:
perl
Copy code
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 {
context serverside
}
tcp {
context serverside
}
starttls {
context serverside
}
}
serverssl-use-sni disabled
source 0.0.0.0/0
source-address-translation {
type automap
}
translate-address enabled
translate-port enabled
vs-index 12
}
By adding the starttls profile under profiles, the SMTP proxy will attempt to negotiate a TLS connection using STARTTLS with the destination server.Note: Ensure that you have the necessary SSL certificate configurations in place and that your proxy server is capable of handling the TLS negotiation and encryption process.
Please note that this is a simplified example, and you may need to further customize the configuration based on your specific environment and requirements.
Regards,
