cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

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)

(4) Replies
CharlesW
By Level 12 Flexeran
Level 12 Flexeran
About all I can suggest would be to restart the ESD Service after changing the credentials.. It may be that the ESD Service is holding on to the old credentials you had specified for the incoming email settings.

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.

Anything expressed here is my own view and not necessarily that of my employer, Flexera. If my reply answers a question you have raised, please click "ACCEPT AS SOLUTION".

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..

http://www.mimekit.net/docs/html/P_MailKit_Net_Imap_ImapClient_Inbox.htm

Perhaps your network team is aware of some type of limitation with regards to MimeKit?