Automatic Email Processor - Frequently Asked Questions (FAQ)

This page answers frequently asked questions about Automatic Email Processor. For detailed step-by-step instructions on the program features, please see the online help.

Affected messages in the error log:

• "The encrypted message cannot be decrypted. The matching certificate with the private key was not found."
• "No matching private key was found in the personal Windows certificate store of the signed-in user."

Cause: To decrypt S/MIME-encrypted emails, Automatic Email Processor requires your personal certificate including its private key. It must be located in the Windows certificate store "Personal" of the user account under which processing runs. The most common cause of the message: the certificate was transferred without its private key (e.g. exported as a .cer file), or it was imported under a different Windows user account.

How to set up the certificate correctly:

1. Export the certificate on the computer where it already works (e.g. where you can read encrypted emails in your email program): press Windows key + R, enter certmgr.msc, right-click the certificate under "Personal > Certificates", then select "All Tasks > Export...".
2. In the export wizard, choose the option "Yes, export the private key" and save the file in PFX format, protected with a password. If the option is grayed out, the certificate was originally installed without an exportable private key; in that case, request the PFX file from the certificate issuer or your IT department.
3. Import the PFX file on the computer running Automatic Email Processor by double-clicking it: store location "Current User", enter the password, certificate store "Personal" (or let Windows select it automatically).
4. If processing runs as a Windows service: perform the import under the Windows user account the service runs as - the certificate store is per user account.
5. Afterwards, process the affected emails again, e.g. via "Catch-up processing...".

Note: A .cer file only contains the public part of the certificate and is not sufficient for decryption - it must be a PFX file including the private key.

Typical signs: The sign-in and the account test succeed, but no emails are ever processed. The folder selection only shows the standard folders (Inbox, Sent Items, etc.) - subfolders you created yourself, which are visible in Outlook, are missing.

Cause: In this case, the email of your domain is not hosted at Microsoft but at a different provider (for example, the web hoster of your company domain). In addition, a second, practically empty mailbox with the same address exists in the Microsoft account - for example, because a Microsoft 365 account was created for the Office applications. The program connects to this empty mailbox when the account is set up as a Microsoft 365 account, while your actual emails and folders are located on the server of your email provider. Automatic Email Processor shows a warning in this constellation, among other places when the account is created and during the account test.

How to connect the correct mailbox:

1. Remove the Microsoft 365 account under "Menu > Options > Email accounts". You can confirm the note that the account is still in use.
2. Create the account again, this time with the account type IMAP. You get the server details (incoming mail server, usually port 993 with SSL) and the credentials from your email provider; they are the same ones other email programs use for this mailbox.
3. After saving, the program offers to transfer the existing profile references to the new account - please confirm this.
4. Then check under "Options > Notifications" and "Options > Report" whether the correct sender account is still selected there.
5. Run "Test account" and check in the folder selection of a profile whether the subfolders now appear.

Note: If the email of your domain is actually hosted at Microsoft (Microsoft 365 or Exchange Online is your email provider), the Microsoft 365 account type is the right choice - in that case, no warning appears either.

Special case email security gateway: In larger organizations, an email security gateway (e.g. Retarus, Mimecast, Proofpoint, or Hornetsecurity) is often placed in front of the Microsoft 365 mailbox. The DNS record of the domain then points to this gateway, which checks incoming email and forwards it to Microsoft 365. In this constellation, the warning may appear even though the mailbox is actually hosted at Microsoft. As long as expected messages arrive in the account, you can ignore the note; the Microsoft 365 account type is then the right choice.

Background: In the profile settings under "Notifications", a custom notification text can be stored that contains the storage folder of the filed documents as a link via the placeholder <StoragePathLink>. However, whether this link is clickable for the recipient is decided by their email program - links into the file system are blocked by many programs for security reasons.

The most important rules:

• Network paths (e.g. \\server\share\invoices) can be clicked directly in Outlook (classic) - in both plain text and HTML emails. This is the recommended approach.
• Local paths (e.g. C:\Archive\...) are always blocked by Outlook; unblocking them would only be possible via policies on the recipient side and is not recommended.
• The new Outlook, Outlook on the web and most webmail services (e.g. Gmail) generally display file system paths as text only - the recipient can then select and copy the path and paste it into the address bar of Windows Explorer.

Recommendation:

1. Use a network path (\\server\share\...) as the storage target of the profile if recipients should be able to jump to the storage folder with one click.
2. Additionally add the placeholder <StoragePath> to the notification text - this way, the path is always included in the email as copyable text.
3. Test the notification with the email program your recipients actually use.

Note: The link is only generated as a clickable HTML link if the notification text contains HTML. In plain text emails, the path is inserted as text - Outlook (classic) also recognizes network paths there and makes them clickable itself.

Background: Your organization is configured in Microsoft 365 in such a way that users are not allowed to grant applications access to their own mailbox themselves. An administrator has to grant consent to the application "Automatic Email Processor" once. A separate app registration in Microsoft Entra ID is not required - the application already comes with its own registration.

How to grant consent:

1. In the account editor, click "Sign in with Microsoft..." again and sign in at the Microsoft sign-in page with an administrator account of your organization.
2. In the consent dialog, select the checkbox "Consent on behalf of your organization" and confirm.
3. Afterwards, click "Remove credentials" in the account editor and repeat the sign-in with the actual account - it now completes without an approval prompt.

Note for administrators:

The application requests delegated permissions only, i.e. access solely in the context of the signed-in user and no tenant-wide application access: Mail.ReadWrite, Mail.ReadWrite.Shared, Mail.Send, Mail.Send.Shared, User.Read, and MailboxSettings.Read. After consent has been granted, the application appears in the Entra admin center under "Enterprise applications", where it can be reviewed or revoked at any time.