SMTP Stupidity?

Epicor ERP 10
,
1

We recently migrated to Microsoft 365 for our email and I am trying to get it configured properly in Epicor, and I am having one heck of a time getting it to work.

I have tried configuring this any-which-way I can think of, and I always receive an error of some kind. Here is what I have tried, and the error received when I try to have Epicor send an email:

image
image720×306 34.4 KB

When I configure Epicor as shown above, I get the error shown below in the Event Viewer on the server.

“E10Live”: An error occurred trying to run task ID 1358016 for agent “SystemTaskAgent” on the application server (User: “JHecker”, Task Description: “Report-ShipViaAnalysis (ShipViaAnalysis)”).

Error details:

Ice.Common.BusinessObjectException: Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask:

System.Net.Mail.SmtpException: Error in processing. The server response was: Requested action aborted: local error in processing

image
image734×319 34.9 KB

That configuration returns the same error as previously:

“E10Live”: An error occurred trying to run task ID 1358049 for agent “SystemTaskAgent” on the application server (User: “JHecker”, Task Description: “Report-ShipViaAnalysis (ShipViaAnalysis)”).

Error details:

Ice.Common.BusinessObjectException: Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask:
System.Net.Mail.SmtpException: Error in processing. The server response was: Requested action aborted: local error in processing

The previous 2 examples both had SSL disabled. The next 2 examples are exactly the same (port 25 and port 587) but with the “Use SSL” checkbox being checked. The error with Use SSL being checked is:

“E10Live”: An error occurred trying to run task ID 1358085 for agent “SystemTaskAgent” on the application server (User: “JHecker”, Task Description: “Report-ShipViaAnalysis (ShipViaAnalysis)”).

Error details:

Ice.Common.BusinessObjectException: Program Ice.Services.Lib.RunTask raised an unexpected exception with the following message: RunTask:
System.Net.Mail.SmtpException: Server does not support secure connections.

What am I possibly missing? I have tried with and without a Connector in M365 that is tied to my public IP, changed the settings in Epicor countless times, verified the passwords are correct, etc. I am baffled with this one.

2

If you search the list, you’ll find the most popular solution is to have a local SMTP server that gateways to O365.

2 Likes
3

I believe you still need a mail relay for 365 to work. Looking forward to that being fixed. If you’re on prem it’s not very difficult to setup, but I would restrict access to the Epicor App server for relaying.

Same issue with some printers.

1 Like
4

Handled in 2022.2 with O365 compatible auth but look for smtp relay post by @EarlGrei for your current version.,

5

Correct my if I’m wrong, but isn’t Microsoft deprecating basic auth for SMTP on Office 365 soon? I know they wanted to do it October 20 something this year but got a lot of push back for things like multifunction devices that literally cannot generate OAuth tokens to authenticate.
I just had this conversation with a colleague about how I need to migrate some existing client code that utilizes O365 with username/password away to something that allows basic authentication (AWS SES).

1 Like
6
2 Likes
7

They claim SMTP will still suppose to work… Because of many devices like printers cannot do anything more complex than basic SMTP auth.

2 Likes
8

Interesting. Do you know if that is truly the case? I feel like I read somewhere that you still have to enable this setting in the tenant for it to continue to work, but I’m not an expert.

Deprecation of Basic authentication in Exchange Online | Microsoft Learn

9

Not in scope for this disablement (we are not making changes to):

  • SMTP AUTH
3 Likes
10

But then can still disable it randomly :slight_smile: to make our life more interesting…

11

I have some client code that utilizes basic auth for SMTP that I really don’t want to refactor to use another service but perhaps we can just wait and see.

12

This is how ours looks like, with the right SMTP Relay settings of course. We add our Epicor Servers and TA Server to SPF.

Direct Send

image

image

Features of direct send

  • Uses Microsoft 365 or Office 365 to send emails, but does not require a dedicated Microsoft 365 or Office 365 mailbox.
  • Doesn’t require your device or application to have a static IP address. However, it is recommended for your device or application to have a static IP address, if possible.
  • Doesn’t work with a connector; never configure a device to use a connector with direct send because such a configuration can cause problems.
  • Doesn’t require your device to support TLS.

Direct send has higher sending limits than SMTP client submission. Senders are not bound by the limits described in Option 1.

Requirements for direct send

  • Port: Port 25 is required and must be unblocked on your network.
  • Static IP address is recommended: A static IP address is recommended so that an SPF record can be created for your domain. The SPF record helps avoid your messages being flagged as spam.
  • Does not require a Microsoft 365 or Office 365 mailbox with a license.

Limitations of direct send

  • Direct send cannot be used to deliver email to external recipients, for example, recipients with Yahoo or Gmail addresses.
  • Your messages will be subject to antispam checks.
  • Sent mail might be disrupted if your IP addresses are blocked by a spam list.
  • Microsoft 365 and Office 365 use throttling policies to protect the performance of the service.

If you need more flexibility, usually you install your own SMTP Relay on-prem and then have that relay with better AUTH options to O365. You can find plenty of local SMTP Servers that can take a basic SMTP and forward it with more power!

1 Like
13

and what are right SMTP Relay settings?

14

@Aaron_Moreng We are very much using the SMTP relay on site. It authenticates to MS, but is ‘open’ for receiving email. ERP, HCM, ECM, Ricoh copiers, and a handful of other things all go through there because none of them handle O365 directly. But because the SMTP does authenticate, MS will continue to support that - as we understand it.

2 Likes
15

Probably setting up SPF properly to whitelist your Epicor Server. :slight_smile:

1 Like
16

I second that, see O365 Direct Send is limited to internal traffic.

If you need more flexibility, usually you install your own SMTP Relay on-prem and then have that relay with better AUTH options to O365. You can find plenty of local SMTP Servers that can take a basic SMTP and forward it with more power!

1 Like
17

I think we’re just using the MS Server 2019 built in SMTP services actually. (I’d have to ask my engineer to be sure)

And we did have trouble when MS deprecated the BASIC auth and changed TLS and stuff earlier this year. This is how we got around it all.

1 Like
18

It took me a minute, but finally got that dang SMTP Relay going. I fat fingered the TCP port for the outgoing connection so it was failing trying to connect to M365…2 hours later and that problem is fixed and I am now getting the Epicor emails :slight_smile:

Thank you everyone!

1 Like
19

We actually have no issue using Outlook365’s SMTP for any of our customers. Port 587, with TLS, use authentication, and you also need to make sure your FROM address in the email you’re sending is correct (same as the username). You cannot use just any address you want in there. The auth changes that MS pushed affected IMAP, POP3, and Exchange services logins, but not SMTP (I had to modify some services to use MS Graph instead of POP3 to scan incoming emails).

20

And just in case you might be looking for a development solution to just prove the format and output of emails from a dev server then try a tool like Papercut SMTP. GitHub - ChangemakerStudios/Papercut-SMTP: Papercut SMTP -- The Simple Desktop Email Server

There are other tools like this also.