Technically:
The major functionality of this feature is based on the principal that there is an email loop between the Office 365 client's tenant and the Letsignit platform.
The implementation of this loop follows the recommendations set out in this documentation provided by Microsoft.
Summary:
The mails whose origin is internal to the organization are redirected to the Letsignit platform
Letsignit processes the messages to add a signature
Letsignit sends the mail back to Office 365
The email is then redirected to the final recipient by Office 365
Step 1:
-Only emails from the organization whose sending domain has been approved by the Office 365 administrator during the authorization phase in the LSI service are redirected to the LSI service.
Only the emails whose sending domain has been approved by the Office 365 administrator during the authorization phase in the LSI service.
SMTP exchanges are made via the STARTTLS mechanism.
Step 2:
-The emails are stored in the time that they are processed and deleted as soon as the return to office is confirmed.
-During the process time, the emails are stored in an Azure Storage to ensure redundancy.
Step 3:
-Emails are only accepted if they are received from a certified connection by domain (defined during the authorization phase in the LSI service) accepted by the Office 365 administrator.
-SMTP exchanges are made via the STARTTLS mechanism.
The SMTP service is based on a cluster of 3 nodes in the Azure architecture. This configuration ensures the high availability of the 3 nodes.
The last architecture adds a Windows service which permits the execution of necessary routines of the creation of the SMTP connector between Letsignit and Office 365.
Important to note: The signatures cannot be seen in the body of your email, it attaches itself to the email once the email has been sent.
⚠️ It will no longer be possible to set up new SMTP accesses on tenants created after February 2023.
#SMTP #Office365 #mobility #technical #work #connector