IMAP Journal Connection Failed

Microsoft 365 (i.e. Office 365) IMAP plaintext auth disabled

As of 1 October 2022, Microsoft deprecated plaintext IMAP authentication on the Microsoft 365 platform. Thus, to continue to use IMAP to retrieve journaling traffic, it is necessary to setup OAUTH authentication in MailArchiva by upgrading MailArchiva to V8.11.13 or higher and referring to these additional steps.  In particular, steps A, B, C1, D1 and E1 under the heading MailArchiva On-Premise Setup.   

IMAP OAuth AUTHENTICATE failed

IMAP OAuth requires steps A, B, C1, D1 and E1 to be completed as indicated in the Microsoft 365 MailArchiva On-Premise Setup

 In Step D1, note where it explicitly states "Open Enterprise Applications (not App registration!).". A common mistake is to use the Object Id from the Azure application registration screen. This is wrong! The Object Id must be taken from the application in the Azure Enterprise Applications section (different from Azure App Registration!). To correct, delete the service principal and create it with the correct object ID.

Connection <token> is either not enabled or no longer exists

Ensure the Microsoft 365 (i.e. Office 365) connection (selected as the token) is enabled.

Microsoft IMAP service not started

On the MailArchiva box, drop to the command prompt and type:

If no response, it could mean that IMAP service is not started.

Resolution: Start the Microsoft IMAP Service from the Windows Services applet. To accomplish this, on the Exchange server, click Windows Start menu, Run, type "services.msc". Locate and start the Microsoft IMAP Service.

Firewall / networking issue

There is a firewall or networking issue blocking the communications between MailArchiva and Exchange on port 143.

On the MailArchiva box, drop to the command prompt and type:

If there is no response, it could mean there is a networking issue or firewall blocking the communications.

Resolution: Check the firewall settings to ensure that communication on port 143 is allowed.

No such login method

When testing the Journal Account Connection, the error "No Such Login Method" is outputted.

Resolution: Configure the Microsoft Exchange IMAP server to accept the integrated authentication method. In Exchange 2007, the IMAP server settings are accessible from the Exchange Management Console in Server Configuration > Client Access > IMAP4 > Properties -> Authenticaton tab.

See here for instructions on how to configure IMAP on Exchange 2007: http://www.msexchange.org/articles_tutorials/exchange-server-2007/mobility-client-access/using-pop3-imap4-access-exchange-2007-part1.html

Journal account problems

In Active Directory, ensure that the journal user account is:

• Not disabled
• Password has not expired
• Force password change is off

Journal Account Full (>20,000 emails)

 If there are too many messages (>20,000) in the journal account, Exchange may not be able to cope with the load and may be unable to respond to MailArchiva's IMAP client. The only solution here is to create and configure a new journal account. Use MailArchiva's import feature to import mail from the old journal account.

Connection mode incorrect

Ensure that MailArchiva is configured to connect to the Microsoft IMAP Service using a supported connection mode (e.g. plaintext, TLS, no TLS). The connection modes must match on both sides.

PKIX path building failed

The error: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

This error means MailArchiva cannot build a complete certificate chain from the server certificate to a trusted root. The steps below show how to identify which certificate is missing and how to resolve it.

This is not a MailArchiva defect, but a trust issue—most commonly caused by a missing intermediate certificate. 

Understanding the certificate chain

Certificates are validated through a chain:

Server certificate (presented by the remote system)
Intermediate certificate(s) (linking trust)
Root certificate (trusted authority)

Each certificate is signed by the next one in the chain. MailArchiva verifies this by matching:

Issuer DN → Subject DN

For example:

Server (Issuer = B) → Intermediate (Subject = B, Issuer = C) → Root (Subject = C, Issuer = C)

If any link in this chain is missing, the validation fails.

Why the error occurs

This error typically means:

• A required intermediate certificate is missing (most common)
• The root certificate is not trusted
• The server is not presenting a complete chain
• The wrong certificate has been imported

How to identify the missing certificate

Go to Configuration → Certificates and examine the certificates present.

Start with the server certificate:

• Subject DN = A
• Issuer DN = B

This tells you that the next certificate in the chain must have:

• Subject DN = B

Now check the trusted certificates in MailArchiva:

• If no certificate has Subject DN = B, the intermediate certificate is missing

If you do find it, continue:

• Subject DN = B
• Issuer DN = C

Now look for:

• Subject DN = C

Repeat this process until you reach a root certificate, where:

• Subject DN = Issuer DN

At any step, if a matching Subject DN cannot be found, that certificate is the missing link in the chain.

Fixing the issue in MailArchiva

Once the missing certificate is identified:

• Obtain it from the certificate authority (CA). In many cases, the intermediate certificate must be downloaded separately
• Go to Configuration → Certificates
• Click “Import CA certificate”
• Import the missing certificate/s (start with the root first, and then the intermediate certificate/s (moving up the chain)

Retry the connection after importing.

Common pitfalls

• Assuming the certificate authority sent the complete chain (many do not). You may need to go hunting for the missing CA certificates.
• Missing multiple intermediate certificates
• Having the root and server certificates but not the intermediate

Summary

This error means MailArchiva cannot complete the trust chain:
 

Server → Intermediate → Root

To resolve it, follow the chain by matching Issuer DN to Subject DN step-by-step, identify where it breaks, and import the missing certificate using MailArchiva’s certificate configuration.

In most cases, the fix is simply to add the missing intermediate certificate.
 

Easy way to extract the full certificate chain from an IMAP server

Use OpenSSL utility (available on Linux) to retrieve the certificates presented by the server.

For IMAP over TLS (port 993):

openssl s_client -connect hostname:993 -showcerts </dev/null 2>/dev/null | awk '/BEGIN CERTIFICATE/{n++}{print > "cert" n ".pem"}'

For STARTTLS (port 143):

openssl s_client -connect hostname:143 -starttls imap -showcerts </dev/null 2>/dev/null | awk '/BEGIN CERTIFICATE/{n++}{print > "cert" n ".pem"}'

What you get:

• cert1.pem → server certificate
• cert2.pem → intermediate (if present)
• cert3.pem → next intermediate

Go to Configuration→Certificates. Starting from the ROOT certificate: 1. click on Import CA cert 2. Click Browse to select a certificate file 3. Enter a storage alias (e.g. root). Click Import. Repeat for the remaining certificates.