- Flexera Community
- App Broker
- App Broker Forum
- Incoming Email Services Configuration
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Printer Friendly Page
Incoming Email Services Configuration
We consistently see App Portal not able to login to the IMAP server. We reset the password, change the password in the configuration settings and it seems to work for awhile then stops again with LOGIN failed message.
The same password is used for the service account on the ESD service and the application pools so I'm at a loss of why the email settings continue to have trouble. Yesterday I changed the service account password again and it has not resolved the issue in email. The MailParser_Error.log shows the following:
Unexpected error while connecting to imap server : LOGIN failed. at MailKit.Net.Imap.ImapClient.<AuthenticateAsync>d__83.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at MailKit.Net.Imap.ImapClient.Authenticate(Encoding encoding, ICredentials credentials, CancellationToken cancellationToken)
at MailKit.MailService.Authenticate(Encoding encoding, String userName, String password, CancellationToken cancellationToken)
at AppPortal.Infrastructure.Services.MailParserService.ConnectToIMAPServer(MailParserConfiguration configuration, String& errormessage)
This thread has been automatically locked due to inactivity.
To continue the discussion, please start a new thread.
I tried restarting the ESD service and that didn't fix it. I've involved the network folks here and they said it there is a user password brute force attempt showing. Can you tell me how the connection to IMAP works from the ESD service and what triggers the calls or what call is being made?
There is nothing in the network logs showing an anomaly.
I'm probably not much help on determining root cause of the brute force attack. However, would an alternative be to see if your SMTP team would allow anonymous relay on a point to point connection from your App Broker server's IP address? Then you wouldn't need to specify credentials at all (nothing to get locked out), and it would still be fairly secure, since it would be limited to the one IP address.
There's obviously more to it than this, but the following API documentation shows the basic calls that App Broker is making to connect to the IMAP server..
Perhaps your network team is aware of some type of limitation with regards to MimeKit?