Forum Discussion

huzer1's avatar
huzer1
Icon for Nimbostratus rankNimbostratus
Jan 13, 2022

SMTP 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.

4 Replies

  • 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's avatar
    huzer1
    Icon for Nimbostratus rankNimbostratus

    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

    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: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
  • The 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,

    O365CloudExperts.