Cloud SDK mail-client send using On Premise SMTP MAIL Destination

[martin-kl]

Hi,

i was super excited to learn about the new Mail Client in Cloud SDK and wanted to include it in our solution but failed. So I went over Ahmet's Blog post and tried it in this simple setup (BAS, new CAP project with the single endpoint, new service instances on my trial account and using "cds bind" to test it from BAS) but I still cannot figure it out.

According to the docs, using an On Premise mail server should be as simple as configuring a destination with proxy type "OnPremise" and Cloud SDK would handle the SOCKS5 proxy. So I configured our CC with a Cloud To On-Premise Mapping of a virtual system "mail.server.com:25" to our internal mail server also running on Port 25 (TCP).

I then created the following destination:

using "mail.smtp.starttls.enable: true" and "mail.transport.protocol: smtp" for the non-readable properties (Mail server accepts un-authenticated, non-TLS requests on port 25 originating from our internal network. I have to set BasicAuthentication since NoAuthentication is rejected by mail-client#buildMailDestination. Using the same parameters without Authentication does in fact work with Java using the template from https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/using-tcp-protocol-for-cloud-applicat...).

However, cloud sdk complains that "The proxy configuration is undefined, which is mandatory for creating a socket connection" (Source of Error).

So I started to debug the destination and stumbled upon the connectivity-service#addProxyConfigurationOnPrem method that seems to provide the expected Socks proxy to the destination, but that method is not invoked. Turns out that destination-service-types#isHttpDestination evaluates to "false" as the MAIL destination has no url and the type is set, which in turn results in destination-from-service#getDestinationFromDestinationService to skip the addition of the proxy setting.

So my question is: am I even correct to use a destination of Type "MAIL" with Proxy Type "OnPremise", setting mail.smtp.host to the virtual host of the CC and mail.smtp.port to the port? Or did I stumble upon an issue with the new mail client and destination service combination?
Since I tried to "fix" the isHttpDestination method to add the proxy on MAIL Destinations as well but still run into an error (namely a ECONNRESET), I'm not sure anymore....

Best
Martin

[ManolV]

Hi martin-kl,

The handling of HTTP and SMTP protocols for cloud to premise connectivity is significantly different. Connectivity service offers native HTTP proxy for handling HTTP traffic, and SOCKS5 proxy for handling any TCP based traffic on the level of TCP (this may include HTTP as well). Therefore, any mixture of settings on the client library would eventually result in errors.

Regarding the 10 seconds issue, kindly inspect if the Cloud Connector is configured with Location ID, and if so, then the client should pass that as part of the SOCKS5 handshake as otherwise it may happen that the client request a connection to one Cloud Connector instance, while the one actually connected to the subaccount is with different settings, practically meaning a different instance.

FYI, all those complex issues with proxying are resolved if one is using the Transparent Proxy software component, as it would do the needful, and it's coming from the BTP Connectivity product: https://blogs.sap.com/2022/11/29/transparent-consumption-of-connectivity/

Regards,
Manol

[martin-kl]

Hi manolvalchev,

thanks for your response. I will check the Cloud Connector but as far as I know that is our only CC installation and it is configured without such an ID.

And about the Transparent Proxy software: that seems quite helpful in a Kyma environment. Since we are developing solely for Cloud Foundry it is my understanding that we don't need the component and Cloud SDK handles the destination retrieval and SOCKS5 proxy on its own, correct?

Best
Martin

[ManolV]

Hi Martin,

If the client and SCC are both configured with same Location ID, then the issue should be somewhere else. You can try using with same setup an HTTP client to pass some dummy traffic for the sake of testing and validating the general setup is working fine. Then get back to the SMTP use case. Inspect the error on the mail client side in deep details to ensure it's not a problem with the client. If needed, consider reporting a support ticket for getting further support.

Correct, Transparent Proxy runs only on Kubernetes environment, incl. Kyma.

Regards,
Manol