I hope not as we use gateways for everything to control where it goes and by each domain.

I have been able to verify that the autoresponder does appear to be skipping the gateway setting and sending directly from the primary server.  This has been added to our bugs list and is currently being worked on.

Thanks Robert!

This should be fixed in the next BETA release.

Hello,

In addition to the issue with gateway and autoresponders, I have discovered today that it also doesn't use the gateway for automatic forwarding:

A global gateway is active on our host (on build 7398) but for forwards SM contact directly the MX for the destination domain:

SRS mode is activated, I have not tried without SRS, but my guess would be it's the same.

[2020.04.05] 10:30:23.168 [80787] Delivery for sr@source.ch to madjik@dest.com has completed (Forwarded Delivered) Filter: None
[2020.04.05] 10:30:23.168 [80787] End delivery to madjik@dest.com (MessageID: <emefe9bf39-cc76-4a83-b3c9-631ce36beb56@lovemachine>)
[2020.04.05] 10:30:23.168 [80787] Removed from LocalDeliveryQueue (0 queued or processing)
[2020.04.05] 10:30:53.262 [80787] Added to RemoteDeliveryQueue (1 queued; 0/100 processing)
[2020.04.05] 10:30:53.262 [80787] [RemoteDeliveryQueue] Begin Processing.
[2020.04.05] 10:30:53.262 [80787] Sending remote mail for sr@source.ch
[2020.04.05] 10:30:53.262 [80787] Spam check results: 
[2020.04.05] 10:30:53.262 [80787] MxRecord count: '5' for domain 'gmail.com'
[2020.04.05] 10:30:53.262 [80787] Attempting MxRecord Host Name: 'gmail-smtp-in.l.google.com', preference '5', Ip Count: '1'
[2020.04.05] 10:30:53.262 [80787] Attempting to send to MxRecord 'gmail-smtp-in.l.google.com' ip: '173.194.79.27'
[2020.04.05] 10:30:53.262 [80787] Sending remote mail to: forward_dest@gmail.com

Please also make sure using the gateway for forwards alors use the gateway when it's not set as global but specific gateway for the domain :)

EDIT: on our production rig (pre-BETA) it also doesn't use the gateway for forwards when it is set at domain level. However when gateway is globally activated it seems to use it.

(That would explain some issues we have/had with forwards)

Thanks !

Hello,

While we're talking about gateway things, I had noticed long time ago that when you set a gateway to use no encryption, it still uses TLS if announced by the server.

[2020.04.05] 10:45:42.122 [80796] Connection to 94.x.x.140:25 from 192.168.60.102:52173 succeeded (Id: 1)
[2020.04.05] 10:45:42.200 [80796] RSP: 220 mta-gw.coolgateway.net ESMTP Haraka/2.8.25 ready
[2020.04.05] 10:45:42.200 [80796] CMD: EHLO mail03.coolhoster.com
[2020.04.05] 10:45:42.247 [80796] RSP: 250-mta-gw.coolgateway.net Hello mail03.coolhoster.com [94.x.x.141] Haraka is at your service.
[2020.04.05] 10:45:42.247 [80796] RSP: 250-PIPELINING
[2020.04.05] 10:45:42.247 [80796] RSP: 250-8BITMIME
[2020.04.05] 10:45:42.247 [80796] RSP: 250-SMTPUTF8
[2020.04.05] 10:45:42.247 [80796] RSP: 250-SIZE 0
[2020.04.05] 10:45:42.247 [80796] RSP: 250 STARTTLS
[2020.04.05] 10:45:42.247 [80796] CMD: STARTTLS
[2020.04.05] 10:45:42.278 [80796] RSP: 220 Go ahead.
[2020.04.05] 10:45:42.278 [80796] Certificate name mismatch.

As the gateway is on the same VLAN segment we usually disable TLS between the hosts, but it still tries to use it and sometimes it makes trouble, like when certificate on the gw is expired or has never been configured correctly.

It looks like the "encryption" setting of the gateway has no effect, or at least not when set to None.

I would suggest to make the "None" option having an effect, or remove it/ or rename "None" to "Auto" (based on STARTTLS announce or not by the gateway, like it seems to be at the moment)

Kind regards

Soo .. does anyone from you have any response from ST about this? I'm getting support tickets from my customers because their messages are not being forwarded because primary server is connecting to remote MX servers directly and gets disconnected because primary server is not present in SPF configuration (outgoing gateways of course are there).

Robert says in earlier post in this topic that it would be fixed in a new beta release, so I guess it should be fixed now. I'm going to give it another try on our beta environnement.

No it is not. I've just updated to 7417 just like Kyle suggested to me in his last reply adding that this support ticket is old (last activity 15th of april) and if issue is still there then I should open new ticket. 

So since I had still hot ticket from my customer which reported this problem I've performed mail server update and checked once again. Nothing changed (at least for forwarding messages).

I've sent response to this closed ticket and got auto response:

I'm so pissed right now .. I'm really tired of sending new tickets for new issues on daily basis.

EDIT: Of course I've opened new support ticket because what else I could do

So my test drive:

Automatic forwarding -> still doesn't use the gateway

Autoresponder -> still doesn't use gateway actually seems to use the gateway on latest build

Robert said @ 4/1/2020 at 9:32 PM that it was fixed in next release and there was many of them since then. The issue is not in the known issue neither in the changelog. It looks like it has been forgotten.

EDIT: seems it has been fixed but only for autoresponders not for auto forwardings

These issues themselves are a no go to update our production server to the mapi builds.

I guess other issue I added to this thread aren't adressed yet.

ST, can you please take a look at this ?

Kind regrads.

You tested with the latest build Sebastien?

Hello echoDreamz,

Yes with latest version. But I see now that the autoresponder DOES in fact use the gateway, but not the auto forwarding.

Can you give it a try to confirm this ? (Enable forwarding for one user and check delivery logs if it uses the gateway for sending the forward outside).

Thanks :)

It seems also for custom "Content filter" that users can create, using action "Forward message", it also doesn't use the gateway for the forward.

Additionnaly, the "Forward message" action in the content filter doesn't apply SRS on the sender address (but it does when using the standard Auto forwarding feature).

EDIT: it uses the gateway when using "Reroute message" action instead of "Forward message".

I don't really know what's the difference between "reroute message" and "forward message", but what I can see is that when I use "reroute message" it use the mailbox e-mail address as sender.

When using "forward message" it uses the  original sender FROM address (but doesn't apply SRS).

Not sure if all this are intended behaviors though.

Sébastien, I have added separate tasks for the autoforwarding and content filter "Forward message" action not using the configured gateway.  I have also added a task for the "Forward message" content filter action not using SRS on the sender address.

Hello Robert,

Thanks a lot for taking a look on this.

Kind regards.

Hi all, 

I wanted to provide a comprehensive update for the issues that have been reported in this thread. 

The original issue reported: "When an autoresponder is sent, it is done so using the SM installation, not our outgoing gateways." 

"In addition to the issue with gateway and autoresponders, I have discovered today that it also doesn't use the gateway for automatic forwarding"

"I had noticed long time ago that when you set a gateway to use no encryption, it still uses TLS if announced by the server."

We unfortunately missed this report earlier this month and a task wasn't created to fix it. We've added a task to look into it. 

"It seems also for custom "Content filter" that users can create, using action "Forward message", it also doesn't use the gateway for the forward."

"Additionnaly, the "Forward message" action in the content filter doesn't apply SRS on the sender address (but it does when using the standard Auto forwarding feature)."

If I missed any, please let me know. As the original issue reported has been resolved, I'll go ahead and mark this thread as Resolved. Sébastien, this thread has been linked to the task to address the gateway encryption issue, so we'll provide an update when it's been addressed. 

Hello Andrea,

Thank you very much for the update on this. On our side, we're going to install the latest build and do some tests to confirm the fixes.

Kind regards.

This one is still okay. Fixed in previous build

This one seems fixed.

Ater another test it seems SRS is still working for this scenario. I don't understand why it wasn't when I did the first test.

This one is _not_ fixed. It still uses the original sender enveloppe address instead of the rewrited SRS enveloppe adress (when enabled).

Thanks a lot for.

Kind regards.

Sébastien,

I cannot replicate the issue where the gateway is ignoring the encryption type specified. In the first snippet below, you can see where STARTTLS is being advertised by the gateway.  I have the gateway configured to use TLS.  The STARTTLS is initiated.

[2020.04.29] 14:21:42.209 [22003] Delivery started for remmett@smartermail.io at 2:21:42 PM
[2020.04.29] 14:21:45.214 [22003] Added to SpamCheckQueue (1 queued; 0/30 processing)
[2020.04.29] 14:21:45.214 [22003] [SpamCheckQueue] Begin Processing.
[2020.04.29] 14:21:45.218 [22003] Starting Spam Checks.
[2020.04.29] 14:21:45.218 [22003] Skipping spam checks: User authenticated
[2020.04.29] 14:21:45.218 [22003] Spam Checks completed.
[2020.04.29] 14:21:45.218 [22003] Removed from SpamCheckQueue (0 queued or processing)
[2020.04.29] 14:21:48.228 [22003] Added to RemoteDeliveryQueue (1 queued; 0/50 processing)
[2020.04.29] 14:21:48.228 [22003] [RemoteDeliveryQueue] Begin Processing.
[2020.04.29] 14:21:48.236 [22003] Sending remote mail for remmett@smartermail.io
[2020.04.29] 14:21:48.239 [22003] MxRecord count: '1' for domain ''
[2020.04.29] 14:21:48.809 [22003] Attempting MxRecord Host Name: 'mail.xxx.com', preference '0', Ip Count: '1'
[2020.04.29] 14:21:48.809 [22003] Attempting to send to MxRecord 'mail.xxx.com' ip: 'xx.xx.xx.xx'
[2020.04.29] 14:21:48.809 [22003] Sending remote mail to: remmett@yyy.com
[2020.04.29] 14:21:48.809 [22003] Initiating connection to xx.xx.xx.xx
[2020.04.29] 14:21:48.809 [22003] Connecting to xx.xx.xx.xx:25 (Id: 1)
[2020.04.29] 14:21:48.848 [22003] Connection to xx.xx.xx.xx:25 from 10.0.0.132:63913 succeeded (Id: 1)
[2020.04.29] 14:21:48.910 [22003] RSP: 220 mail.xxx.com
[2020.04.29] 14:21:48.912 [22003] CMD: EHLO MSI06.st.local
[2020.04.29] 14:21:48.973 [22003] RSP: 250-mail.xxx.com Hello [xx.xx.xx.xx]
[2020.04.29] 14:21:48.973 [22003] RSP: 250-SIZE
[2020.04.29] 14:21:48.973 [22003] RSP: 250-AUTH LOGIN CRAM-MD5
[2020.04.29] 14:21:48.973 [22003] RSP: 250-STARTTLS
[2020.04.29] 14:21:48.973 [22003] RSP: 250-8BITMIME
[2020.04.29] 14:21:48.973 [22003] RSP: 250-DSN
[2020.04.29] 14:21:48.973 [22003] RSP: 250 OK
[2020.04.29] 14:21:48.974 [22003] CMD: STARTTLS
[2020.04.29] 14:21:49.037 [22003] RSP: 220 Start TLS negotiation
[2020.04.29] 14:21:49.132 [22003] CMD: EHLO MSI06.st.local
[2020.04.29] 14:21:49.194 [22003] RSP: 250-mail.smartermonitor.com Hello [xx.xx.xx.xx]
[2020.04.29] 14:21:49.194 [22003] RSP: 250-SIZE
[2020.04.29] 14:21:49.194 [22003] RSP: 250-AUTH LOGIN CRAM-MD5
[2020.04.29] 14:21:49.194 [22003] RSP: 250-8BITMIME
[2020.04.29] 14:21:49.194 [22003] RSP: 250-DSN
[2020.04.29] 14:21:49.194 [22003] RSP: 250 OK
[2020.04.29] 14:21:49.194 [22003] CMD: AUTH CRAM-MD5
[2020.04.29] 14:21:49.256 [22003] RSP: 334 PDY5MzI0NjU5My42MzcyMzc2NjkwOTE4OTMxMzBAbWFpbC5zbWFydGVybW9uaXRvci5jb20+
[2020.04.29] 14:21:49.318 [22003] RSP: 235 Authentication successful
[2020.04.29] 14:21:49.318 [22003] CMD: MAIL FROM:<remmett@smartermail.io> SIZE=979
[2020.04.29] 14:21:49.380 [22003] RSP: 250 OK <remmett@smartermail.io> Sender ok
[2020.04.29] 14:21:49.380 [22003] CMD: RCPT TO:<remmett@yyy.com> NOTIFY=FAILURE
[2020.04.29] 14:21:49.441 [22003] RSP: 250 OK <remmett@yyy.com> Recipient ok
[2020.04.29] 14:21:49.441 [22003] CMD: DATA
[2020.04.29] 14:21:49.503 [22003] RSP: 354 Start mail input; end with <CRLF>.<CRLF>
[2020.04.29] 14:21:49.599 [22003] RSP: 250 OK
[2020.04.29] 14:21:49.599 [22003] CMD: QUIT
[2020.04.29] 14:21:49.662 [22003] RSP: 221 Service closing transmission channel
[2020.04.29] 14:21:49.662 [22003] Attempt to ip, 'xx.xx.xx.xx' success: 'True'
[2020.04.29] 14:21:49.663 [22003] Delivery for remmett@smartermail.io to remmett@yyy.com has completed (Delivered)
[2020.04.29] 14:21:49.663 [22003] Removed from RemoteDeliveryQueue (0 queued or processing)
[2020.04.29] 14:21:51.232 [22003] Removing Spool message: Killed: False, Failed: False, Finished: True
[2020.04.29] 14:21:51.232 [22003] Delivery finished for remmett@smartermail.io at 2:21:51 PM [id:89442422003]

In the second snippet, again you can see that STARTTLS is being advertised, but I have the gateway configured to None for the encryption. It is not initiating the STARTTLS.

[2020.04.29] 14:29:56.401 [66000] Delivery started for remmett@smartermail.io at 2:29:56 PM
[2020.04.29] 14:29:59.421 [66000] Added to SpamCheckQueue (1 queued; 0/30 processing)
[2020.04.29] 14:29:59.427 [66000] [SpamCheckQueue] Begin Processing.
[2020.04.29] 14:29:59.448 [66000] Starting Spam Checks.
[2020.04.29] 14:29:59.449 [66000] Skipping spam checks: User authenticated
[2020.04.29] 14:29:59.449 [66000] Spam Checks completed.
[2020.04.29] 14:29:59.449 [66000] Removed from SpamCheckQueue (0 queued or processing)
[2020.04.29] 14:30:02.448 [66000] Added to RemoteDeliveryQueue (1 queued; 0/50 processing)
[2020.04.29] 14:30:02.448 [66000] [RemoteDeliveryQueue] Begin Processing.
[2020.04.29] 14:30:02.462 [66000] Sending remote mail for remmett@smartermail.io
[2020.04.29] 14:30:02.633 [66000] MxRecord count: '1' for domain ''
[2020.04.29] 14:30:02.679 [66000] Attempting MxRecord Host Name: 'mail.xxx.com', preference '0', Ip Count: '1'
[2020.04.29] 14:30:02.679 [66000] Attempting to send to MxRecord 'mail.xxx.com' ip: 'xx.xx.xx.xx'
[2020.04.29] 14:30:02.681 [66000] Sending remote mail to: remmett@yyy.com
[2020.04.29] 14:30:02.681 [66000] Initiating connection to xx.xx.xx.xx
[2020.04.29] 14:30:02.682 [66000] Connecting to xx.xx.xx.xx:25 (Id: 1)
[2020.04.29] 14:30:02.722 [66000] Connection to xx.xx.xx.xx:25 from 10.0.0.132:65384 succeeded (Id: 1)
[2020.04.29] 14:30:02.786 [66000] RSP: 220 mail.xxx.com
[2020.04.29] 14:30:02.788 [66000] CMD: EHLO MSI06.st.local
[2020.04.29] 14:30:02.851 [66000] RSP: 250-mail.xxx.com Hello [xx.xx.xx.xx]
[2020.04.29] 14:30:02.851 [66000] RSP: 250-SIZE
[2020.04.29] 14:30:02.851 [66000] RSP: 250-AUTH LOGIN CRAM-MD5
[2020.04.29] 14:30:02.851 [66000] RSP: 250-STARTTLS
[2020.04.29] 14:30:02.851 [66000] RSP: 250-8BITMIME
[2020.04.29] 14:30:02.851 [66000] RSP: 250-DSN
[2020.04.29] 14:30:02.851 [66000] RSP: 250 OK
[2020.04.29] 14:30:02.851 [66000] CMD: AUTH CRAM-MD5
[2020.04.29] 14:30:02.913 [66000] RSP: 334 PC03Njk1NjcyMTAuNjM3MjM3Njc0MDI4Mzg3NzUyQG1haWwuc21hcnRlcm1vbml0b3IuY29tPg==
[2020.04.29] 14:30:02.977 [66000] RSP: 235 Authentication successful
[2020.04.29] 14:30:02.977 [66000] CMD: MAIL FROM:<remmett@smartermail.io> SIZE=950
[2020.04.29] 14:30:03.069 [66000] RSP: 250 OK <remmett@smartermail.io> Sender ok
[2020.04.29] 14:30:03.070 [66000] CMD: RCPT TO:<remmett@yyy.com> NOTIFY=FAILURE
[2020.04.29] 14:30:03.163 [66000] RSP: 250 OK <remmett@yyy.com> Recipient ok
[2020.04.29] 14:30:03.163 [66000] CMD: DATA
[2020.04.29] 14:30:03.411 [66000] RSP: 354 Start mail input; end with <CRLF>.<CRLF>
[2020.04.29] 14:30:03.603 [66000] RSP: 250 OK
[2020.04.29] 14:30:03.603 [66000] CMD: QUIT
[2020.04.29] 14:30:03.666 [66000] RSP: 221 Service closing transmission channel
[2020.04.29] 14:30:03.667 [66000] Attempt to ip, 'xx.xx.xx.xx' success: 'True'
[2020.04.29] 14:30:03.680 [66000] Delivery for remmett@smartermail.io to remmett@yyy.com has completed (Delivered)
[2020.04.29] 14:30:03.681 [66000] Removed from RemoteDeliveryQueue (0 queued or processing)
[2020.04.29] 14:30:05.456 [66000] Removing Spool message: Killed: False, Failed: False, Finished: True
[2020.04.29] 14:30:05.458 [66000] Delivery finished for remmett@smartermail.io at 2:30:05 PM [id:95881766000]

If you are not seeing this behavior, can you please open a support ticket so we can look at your setup and get a resolution for this issue?

Thanks, Robert

Hello,

I see you are using authentification with your gateway, and maybe SmarterMail gateway mode ?

On our setup there is no need for authentification (ip checking based and it's not a smartermail gateway so no SmarterMail gateway mode)

Also our gateway isn't announcing any AUTH method has it's only purpose is only to relay mails for different mail servers on our network.

Could one of these differences  be the reason you're not seeing the same behavior ?

Here is a log from attempt I just did:

[2020.04.30] 00:40:48.760 [16456] Delivery started for madjik@somedomain.com at 00:40:48
[2020.04.30] 00:40:51.767 [16456] Added to SpamCheckQueue (1 queued; 0/60 processing)
[2020.04.30] 00:40:51.767 [16456] [SpamCheckQueue] Begin Processing.
[2020.04.30] 00:40:51.767 [16456] Starting Spam Checks.
[2020.04.30] 00:40:51.767 [16456] Skipping spam checks: User authenticated
[2020.04.30] 00:40:51.767 [16456] Spam Checks completed.
[2020.04.30] 00:40:51.767 [16456] Removed from SpamCheckQueue (0 queued or processing)
[2020.04.30] 00:40:54.767 [16456] Added to RemoteDeliveryQueue (1 queued; 0/100 processing)
[2020.04.30] 00:40:54.767 [16456] [RemoteDeliveryQueue] Begin Processing.
[2020.04.30] 00:40:54.767 [16456] Sending remote mail for madjik@somedomain.com
[2020.04.30] 00:40:54.767 [16456] Spam check results: 
[2020.04.30] 00:41:24.896 [16456] MxRecord count: '1' for domain ''
[2020.04.30] 00:41:29.922 [16456] Attempting MxRecord Host Name: 'mta-gw.someisp.net', preference '5', Ip Count: '1'
[2020.04.30] 00:41:29.922 [16456] Attempting to send to MxRecord 'mta-gw.someisp.net' ip: 'xx.xx.96.149'
[2020.04.30] 00:41:29.922 [16456] Sending remote mail to: sr@somerecipient.ch
[2020.04.30] 00:41:29.922 [16456] Initiating connection to xx.xx.96.149
[2020.04.30] 00:41:29.922 [16456] Connecting to xx.xx.96.149:25 (Id: 1)
[2020.04.30] 00:41:29.922 [16456] Binding to local IP 192.168.60.102 (Id: 1)
[2020.04.30] 00:41:29.922 [16456] Connection to xx.xx.96.149:25 from 192.168.60.102:64031 succeeded (Id: 1)
[2020.04.30] 00:41:29.969 [16456] RSP: 220 mta-gw.someisp.net ESMTP Haraka/2.8.25 ready
[2020.04.30] 00:41:29.969 [16456] CMD: EHLO mail03.someisp.com
[2020.04.30] 00:41:30.016 [16456] RSP: 250-mta-gw.someisp.net Hello mail03.someisp.com [xx.xx.96.141]Haraka is at your service.
[2020.04.30] 00:41:30.016 [16456] RSP: 250-PIPELINING
[2020.04.30] 00:41:30.016 [16456] RSP: 250-8BITMIME
[2020.04.30] 00:41:30.016 [16456] RSP: 250-SMTPUTF8
[2020.04.30] 00:41:30.016 [16456] RSP: 250-SIZE 0
[2020.04.30] 00:41:30.016 [16456] RSP: 250 STARTTLS
[2020.04.30] 00:41:30.016 [16456] CMD: STARTTLS
[2020.04.30] 00:41:30.047 [16456] RSP: 220 Go ahead.
[2020.04.30] 00:41:30.047 [16456] CMD: EHLO mail03.someisp.com
[2020.04.30] 00:41:30.094 [16456] RSP: 250-mta-gw.someisp.net Hello mail03.someisp.com [xx.xx.96.141]Haraka is at your service.
[2020.04.30] 00:41:30.094 [16456] RSP: 250-PIPELINING
[2020.04.30] 00:41:30.094 [16456] RSP: 250-8BITMIME
[2020.04.30] 00:41:30.094 [16456] RSP: 250-SMTPUTF8
[2020.04.30] 00:41:30.094 [16456] RSP: 250 SIZE 0
[2020.04.30] 00:41:30.094 [16456] CMD: MAIL FROM:<madjik@somedomain.com> SIZE=823
[2020.04.30] 00:41:30.125 [16456] RSP: 250 sender <madjik@somedomain.com> OK
[2020.04.30] 00:41:30.125 [16456] CMD: RCPT TO:<sr@somerecipient.ch>
[2020.04.30] 00:41:30.156 [16456] RSP: 250 recipient <sr@somerecipient.ch> OK
[2020.04.30] 00:41:30.156 [16456] CMD: DATA
[2020.04.30] 00:41:30.188 [16456] RSP: 354 go ahead, make my day
[2020.04.30] 00:41:30.344 [16456] RSP: 250 Message Queued (6F859284-741E-41AA-8008-BF74CA675EE6.1)
[2020.04.30] 00:41:30.344 [16456] CMD: QUIT
[2020.04.30] 00:41:30.375 [16456] RSP: 221 mta-gw.someisp.net closing connection. Have a jolly good day.
[2020.04.30] 00:41:30.375 [16456] Attempt to ip, 'xx.xx.96.149' success: 'True'
[2020.04.30] 00:41:30.375 [16456] Delivery for madjik@somedomain.com to sr@somerecipient.ch has completed (Delivered)
[2020.04.30] 00:41:30.375 [16456] Removed from RemoteDeliveryQueue (0 queued or processing)
[2020.04.30] 00:41:32.877 [16456] Removing Spool message: Killed: False, Failed: False, Finished: True
[2020.04.30] 00:41:32.877 [16456] Delivery finished for madjik@somedomain.com at 00:41:32	[id:-977681216456]

We can see it's issuing a STARTTLS

But in my gateway settings encryption is set to None

Thank you for your feedback.

ps: Have you seen my test results for the latest build in this post ?

Kind regards,

Sébastien

Sébastien,

I am no using SmarterMail Gateway mode, and in this test I turned off the AUTH requirement (basically set the gateway as an open relay).  You can see that the gateway does still advertise AUTH and STARTTLS, but my main server is not attempting either command.

[2020.04.29] 16:56:05.404 [97002] Delivery started for remmett@smartermail.io at 4:56:05 PM
[2020.04.29] 16:56:08.406 [97002] Added to SpamCheckQueue (1 queued; 0/30 processing)
[2020.04.29] 16:56:08.406 [97002] [SpamCheckQueue] Begin Processing.
[2020.04.29] 16:56:08.412 [97002] Starting Spam Checks.
[2020.04.29] 16:56:08.412 [97002] Skipping spam checks: User authenticated
[2020.04.29] 16:56:08.412 [97002] Spam Checks completed.
[2020.04.29] 16:56:08.412 [97002] Removed from SpamCheckQueue (0 queued or processing)
[2020.04.29] 16:56:11.414 [97002] Added to RemoteDeliveryQueue (1 queued; 0/50 processing)
[2020.04.29] 16:56:11.414 [97002] [RemoteDeliveryQueue] Begin Processing.
[2020.04.29] 16:56:11.419 [97002] Sending remote mail for remmett@smartermail.io
[2020.04.29] 16:56:11.525 [97002] MxRecord count: '1' for domain ''
[2020.04.29] 16:56:11.561 [97002] Attempting MxRecord Host Name: 'mail.smartermonitor.com', preference '0', Ip Count: '1'
[2020.04.29] 16:56:11.561 [97002] Attempting to send to MxRecord 'mail.smartermonitor.com' ip: '66.172.30.49'
[2020.04.29] 16:56:11.561 [97002] Sending remote mail to: remmett@yyy.com
[2020.04.29] 16:56:11.561 [97002] Initiating connection to 66.172.30.49
[2020.04.29] 16:56:11.561 [97002] Connecting to 66.172.30.49:25 (Id: 1)
[2020.04.29] 16:56:11.600 [97002] Connection to 66.172.30.49:25 from 10.0.0.132:55378 succeeded (Id: 1)
[2020.04.29] 16:56:11.662 [97002] RSP: 220 mail.smartermonitor.com
[2020.04.29] 16:56:11.664 [97002] CMD: EHLO MSI06.st.local
[2020.04.29] 16:56:11.727 [97002] RSP: 250-mail.smartermonitor.com Hello [xx.xx.xx.xx]
[2020.04.29] 16:56:11.727 [97002] RSP: 250-SIZE
[2020.04.29] 16:56:11.727 [97002] RSP: 250-AUTH LOGIN CRAM-MD5
[2020.04.29] 16:56:11.727 [97002] RSP: 250-STARTTLS
[2020.04.29] 16:56:11.727 [97002] RSP: 250-8BITMIME
[2020.04.29] 16:56:11.727 [97002] RSP: 250-DSN
[2020.04.29] 16:56:11.727 [97002] RSP: 250 OK
[2020.04.29] 16:56:11.727 [97002] CMD: MAIL FROM:<remmett@smartermail.io> SIZE=952
[2020.04.29] 16:56:11.789 [97002] RSP: 250 OK <remmett@smartermail.io> Sender ok
[2020.04.29] 16:56:11.789 [97002] CMD: RCPT TO:<remmett@yyy.com> NOTIFY=FAILURE
[2020.04.29] 16:56:11.881 [97002] RSP: 250 OK <remmett@yyy.com> Recipient ok
[2020.04.29] 16:56:11.882 [97002] CMD: DATA
[2020.04.29] 16:56:12.099 [97002] RSP: 354 Start mail input; end with <CRLF>.<CRLF>
[2020.04.29] 16:56:12.260 [97002] RSP: 250 OK
[2020.04.29] 16:56:12.260 [97002] CMD: QUIT
[2020.04.29] 16:56:12.322 [97002] RSP: 221 Service closing transmission channel
[2020.04.29] 16:56:12.322 [97002] Attempt to ip, '66.172.30.49' success: 'True'
[2020.04.29] 16:56:12.324 [97002] Delivery for remmett@smartermail.io to remmett@yyy.com has completed (Delivered)
[2020.04.29] 16:56:12.324 [97002] Removed from RemoteDeliveryQueue (0 queued or processing)
[2020.04.29] 16:56:14.416 [97002] Removing Spool message: Killed: False, Failed: False, Finished: True
[2020.04.29] 16:56:14.416 [97002] Delivery finished for remmett@smartermail.io at 4:56:14 PM [id:100486797002]

Hello Robert,

Thank you for doing the test with the same settings as we use.

 Very strange indeed. I then just opened a ticket so you can take a look on the server if you see what could be the source of the issue.

Kind regards.

Just to update the community, if you have the SMTP Out "Enable TLS if supported by the remote server" enabled then the gateway encryption setting was being ignored.  I will remedy this so that gateways will ignore this setting and be based solely on the encryption type specified in the gateway configuration.