Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Email listener authentication fails sporadically



Issue with running email listener in Production environment. Listener authentication configuration is correct and it is connected to email server by using test connection button.
However listener sometimes (sporadic, once in every 3-4 hours) fails whithin authentication phase.
After authenticaiton fails, listener becomes stopped and stops listening mailbox.

When DEBUG logging is enabled, no more authentication problems occur; instead, the system sporadically reports network timeouts on the connection to the email server.

Error Messages

Not applicable

Steps to Reproduce

Not applicable

Root Cause

The the authentication problems with the Mail Box server do show up only sporadically without any configuration was changed is an indicator that the Mail Box server is the culprit.
This is fortified by the observation of network timeouts with active DEBUG logging: the excessive logging changes the timing in the network communication with the Mail Box server, so other error conditions are met.

Mail Box servers do behave in a sometimes "weird" way when they suffer from very high load; in fact, their behaviour is not really weird, but as the different products and even different versions behave slightly different, we get different error messages.

Basically, a Mail Box server under high load refuses to accept further connections until the load decreases.
But this refusal may done in several ways - in this case, the server just ignores the connection request, this results in a network timeout; when this happens during authentication, the published exception is an authentication failure.

Other servers would respond with a login error message when they do not want to accept new connections, or will send back a NAK signal.
Email Clients like Thunderbird, Outlook, or Apple Mail will encounter the same issues, but different from a PRPC email listener, they can afford to repeat the connection attempt indefinitely (or until the user stops them). The design decision was to abort the EmailListener in cases like the described ones, to give the admins the chance to recognise that there is a problem.


Reduce the load on the Mail Box server, or use a dedicated Mail Box server only for the automated services.

Published August 26, 2017 - Updated October 8, 2020

Was this useful?

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us