contentACCESS documentation – version 7.0

The SMTP mappings page can be found under System -> Services section in Central Administration. On this page the user can define new SMTP mappings, edit the existing ones (the listening address cannot be changed) and/or delete them using their context menu. Upon adding a new mapping, editing or deleting an existing one, the new list of the mappings is synchronized to the SMTP servers immediately.

The columns in the grid are the following:
Email address: the address the SMTP server listening on for incoming emails
Folder name: the name of the folder in the target mailbox, to which the emails archived by the SMTP server will be saved
Model name: the name of the model, where the selected target entity lives (the Email archive model enabled for SMTP based archiving)
Entity name: name of the target entity – the email address of the target mailbox

To add a new SMTP mapping, click on the + new smtp mapping and specify the following first:
Email address: the address that the SMTP server is listening on for incoming emails. The domain part is a dropdown list and contains the domains specified in the SMTP domains section in the SMTP Servers page
Folder name: the name of the folder in the target mailbox, to which the emails archived by the SMTP server will be saved
Model name: the name of the model, where the selected target entity lives (the Email archive model enabled for SMTP based archiving)
Entity name: name of the target entity – the email address of the target mailbox. For a mailbox to show up here, it must have an archive database and an index zone assigned.

Next, configure the security settings to align with your specific requirements. Why is configuring these options important?
In multi-tenant environments and cloud-based systems like Microsoft 365, it is important to protect email archives from unauthorized access. The main issue is that the SMTP server is publicly accessible. If someone knows the SMTP-mapped email address, they can easily inject unauthorized emails into the archive, which poses a serious security risk. In on-premises systems, administrators can limit IP addresses (e.g., by allowing only Exchange server IPs), but this method does not work well in multi-tenant environments. Additionally, M365’s large Exchange Online IP range allows emails to originate from other M365 tenants as well.
To address this issue, we have added multiple security layers to the SMTP server, which can be configured at the SMTP mapping level. These layers help ensure that only trusted emails are accepted into the archive. The key components include:

• Allow Only Journal Report Emails: This option ensures that only journal report emails are accepted into the archive. It can be easily enabled or disabled with a checkbox.
• Allowed Senders: This is especially important for M365 journaling, where the sender’s name remains the same, but the domain changes from tenant to tenant. This setting ensures that emails come only from trusted senders.
• Transport Header Rules: With this rule, you can define that specific headers (HEADERNAME:VALUE) must match particular values. If they do not match, the email will be rejected.
• Allow HELO/EHLO Verification: This check examines the hostname provided by the sending server at the beginning of the SMTP connection. We verify that this hostname exists and points to a valid IP address.
• Allow Sender Policy Framework (SPF) Verification: SPF verification checks if the email is sent from an IP address authorized by the sender’s domain. This involves looking up the sender domain’s SPF record in DNS.
• Allow DomainKeys Identified Mail (DKIM) Verification: DKIM ensures that the email was sent from an authenticated server and has not been altered during transit. We check the DKIM signature in the email headers and verify it using the public key from the sender domain’s DNS.
• Allow Domain-based Message Authentication, Reporting, and Conformance (DMARC) Verification: DMARC adds an extra layer of protection on top of SPF and DKIM. We check the DMARC policy of the sender’s domain and verify whether the email complies with these rules.

With these security measures, we can significantly reduce the risk of unauthorized emails being injected into the archive, providing reliable protection in both on-premises and multi-tenant environments.


Note: If the email address is not specified in any of the mappings, it cannot be processed by the SMTP server.
Important: One Email address can be associated only with one Entity! However, one Entity can be associated with multiple Email addresses.