Unable to send invoices directly to AR Customers through client machine

Hi All,

One of our customers is trying to send invoices directly through Sage 300 to its customers. While customer tries to send emails through Remote Desktop Connection, it goes through. However, when they try to send invoices through the client machine, the invoices do not go through.

 I dialed in on the client machine and tried to send test email through Common Services > Company Profile. When I put and external email (My email address) it does not go through. However, when I enter an internal email address(email address of someone in customers organization), the test email goes through.

The customer wants to send email to everyone through the client machine as providing Remote Desktop Connection to its users is against the customer IT Policy. The client uses Basic Authentication SMTP.

Has anyone faced any such issue? what could be some of the steps taken to make this work on Client machine?

Product: Sage 300 2023 PU5.

Parents
  • Hi  this is a common issue caused by the Authentication rules in either the M365 Mail Flow Connector or the on-prem Exchange Receive Connector.  The usual problem is the IP range of the servers is whitelisted in the connector but the IP range of the workstations isn't.  To resolve it, ensure the IP addresses of your workstations are whitelisted.  I always recommend creating a custom Mail Flow or Receive connector for specifically handling Sage 300 SMTP Authentication so the permissions can be handled in one place.

    Alternatively, if its too hard to whitelist all the workstations, you will have to authenticate them by entering an actual 365 or domain account with mailbox, email address, account and password into the Common Services SMTP settings with TLS enabled.  The problem with this is every time the password expires you will have to update the inserted account settings, and MFA can prevent it working.  Further on a lot of M365 tenancies, there are restrictions on Basic Auth.

    As a second alternative, I personally have added a free/inexpensive dedicated SMTP service to my domain which is designed to handle SMTP relay and does not suffer all the frustrating authentication, relay and rate restrictions that the Microsoft services do.  If your client sends a lot of emails - i.e. thousands a month, I strongly recommend using a proper SMTP service - in my case I use MailJet https://www.mailjet.com/products/email-api/smtp-relay/

    Finally if you have to stick with Microsoft and have a client with a high volume site and SMTP Auth is too complicated to manage, consider switching over to Microsoft Graph API for email as a more technologically robust solution than SMTP.  How to setup Microsoft Graph for send mail with Office365 

    Good luck!

Reply
  • Hi  this is a common issue caused by the Authentication rules in either the M365 Mail Flow Connector or the on-prem Exchange Receive Connector.  The usual problem is the IP range of the servers is whitelisted in the connector but the IP range of the workstations isn't.  To resolve it, ensure the IP addresses of your workstations are whitelisted.  I always recommend creating a custom Mail Flow or Receive connector for specifically handling Sage 300 SMTP Authentication so the permissions can be handled in one place.

    Alternatively, if its too hard to whitelist all the workstations, you will have to authenticate them by entering an actual 365 or domain account with mailbox, email address, account and password into the Common Services SMTP settings with TLS enabled.  The problem with this is every time the password expires you will have to update the inserted account settings, and MFA can prevent it working.  Further on a lot of M365 tenancies, there are restrictions on Basic Auth.

    As a second alternative, I personally have added a free/inexpensive dedicated SMTP service to my domain which is designed to handle SMTP relay and does not suffer all the frustrating authentication, relay and rate restrictions that the Microsoft services do.  If your client sends a lot of emails - i.e. thousands a month, I strongly recommend using a proper SMTP service - in my case I use MailJet https://www.mailjet.com/products/email-api/smtp-relay/

    Finally if you have to stick with Microsoft and have a client with a high volume site and SMTP Auth is too complicated to manage, consider switching over to Microsoft Graph API for email as a more technologically robust solution than SMTP.  How to setup Microsoft Graph for send mail with Office365 

    Good luck!

Children
No Data