I have a real tricky issue which we cant get to the bottom of-
We are using Advanced Print Routing which when a report style is used it will email the report to our customers. Some work, and then at times some are failing - the System Monitor shows that the report failed to send with the error “Authentication failed because the remote party has closed the transport stream”
We use these setting in epicor - which havent changed…
Sounds more of an Office 365 issue than Epicor. From what I could find online, looks like it may be related to the TLS protocol - you may need to enable TLS 1.2
Search google for “office 365 smtp” followed by your error message there.
I don’t think it has anything to do with Epicor. This would be more for a network admin or something. But I would make sure it is the source of the issue first. If you enable TLS 1.2 on your server(s) it might affect other things as well.
Dragos
So we were advised by Epicor to apply the basic authentication like you describe above.
I gave this several days and can confirm this DOES NOT FIX the issue. Neither is it a workaround.
Can I ask what version you guys are running that are experiencing the same email error? we are on 10.1.400.32
In keen to know if this is also affecting later versions of epicor?
FYI we have created a workaround ourselves as our Epicor support has failed us - we are using a virtual smpt server on the epicor server, then change the company maintennance to direct all emails to the server- the virtual smpt server then sends on in TLS1.2 and Microsoft accepts the emails.
Epicor sends as TLS 1.0 which is what we believe the issue is now.
Same here. The issue seems to be that as of Oct 1, Microsoft stopped allowing Basic Authentication. We had to pivot away from our smtp.office365.com server for Epicor system emailing to an existing internal smtp server. We’ve lost some ease of monitoring sent status, bounces and auto-replies using a shared web O365 login, but the up side is what I really wanted to let folks know about.
!!!
Our successful invoicing batches using an email/print breaking and routing report style went from 50 or so invoice batches using O365 to up to 200 plus invoice batches so far with the internal smtp server and is seems Epicor’s actual capability will be the limiting factor going forward.
Win!
I am wondering what version of TLS Epicor’s 10.1.600.xx uses by default for System.Net.Mail.SmtpClient and at what layer of the OS does it ask for TLS services, System Default, IIS, .Net framework?
Each can apparenty access the TLS protocol suite independently as controlled by keys in the registry)
By using an internal relay or SMTP server configured as needed to work with your Epicor version’s Authentication capabilities, it will authenticate and store and relay (with separate TLS negotiation with O365) or actually do the customer MX record lookup and blast out emails at great rates compared to Office365’s sending limits referenced by Olga (many thanks for your great support here!).
Our Finance dept is very happy with the improved performance given that we’re processing WAY more invoices at a time now.
Last thing is, If possible within your environment, you can now turn off TLS 1.0,1.1 and any other earlier protocol versions for better security!
we had the same success Henry. And I am not proficient on SMTP server troubleshooting, but I would think you could troubleshoot bounces and what not on that server.
We are using a relay server and we get bounce backs when it is undeliverable.
We, too, have also had instances of emails randomly not sending from Epicor, and also from SSRS, to Office 365. The exception message has always been - “Authentication failed because the remote party has closed the transport stream exception” (this was for a ERP 10.1.600 installation). The following link seemed to explain the randomness of the issue New opt-in endpoint available for SMTP AUTH clients still needing legacy TLS.
The most interesting bit being -
With this in mind, starting in September 2021, we will reject a small percentage of connections that use TLS1.0 for SMTP AUTH. Clients should retry as with any other temporary errors that can occur during submission. Over time we will increase the percentage of rejected connections, causing delays in sending that more and more customers should notice.
The solution in the above link is not a fix, and will allow you extend the use TLS1.0 for the interim and you should look to upgrade as soon as possible.
The bounces and auto replies do end up coming back to the O365 mailbox so that is monitored by key individuals in Finance mostly, via the web interface. Previously though, the Finance staff could easily and quickly also confirm the emails were sent or not via the sent folder in webmail because the end was processes by Office365. Now it is our internal exchange server acting as an smtp sender but it has no mailboxes (some restriction or something with O365 licensing) so sent mail doesn’t show up in a mailbox ‘Sent’ folder on O365. We can find info buried down in some logging once it is turned on. Performance is rocking it so overall, everyone is happy.
My next research task is determining if we can set the TLS defaults within the registry in each Hive and Key to effectively have TLS1.2 be used everywhere when called anywhere… first on the DEV environment with key bakups and vm snaps . It would be nice to know exactly what entity is making the invocation to TLS - whether IIS, .NET framework, or to the system default (is this represented by the SCHANNEL keys?)
Thank you Olga!
Am I safe in assuming that Epicor does code in this manner and that if we change the TLS references for default or disable deprecated versions (TLS 1.1 and SSL 3.0 and earlier), and the system remains working, that we have improved our TLS security surface to that extent?
. It would be nice to know exactly what entity is making the invocation to TLS - whether IIS, .NET framework, or to the system default (is this represented by the SCHANNEL keys?)