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 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.
Ensure the Microsoft 365 (i.e. Office 365) connection (selected as the token) is enabled.
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.
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
In Active Directory, ensure that the journal user account is:
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.
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.
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.
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.
This error typically means:
Go to Configuration → Certificates and examine the certificates present.
Start with the server certificate:
This tells you that the next certificate in the chain must have:
Now check the trusted certificates in MailArchiva:
If you do find it, continue:
Now look for:
Repeat this process until you reach a root certificate, where:
At any step, if a matching Subject DN cannot be found, that certificate is the missing link in the chain.
Once the missing certificate is identified:
Retry the connection after importing.
Common pitfalls
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.
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:
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.