Shared Mailboxes in Outlook Extension

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • TMAG_mbohlender
    Junior Member
    • May 2026
    • 8

    #1

    Shared Mailboxes in Outlook Extension

    Hi Community,

    there are already a few threads about this topic but none of them really meets what I wanted to discuss with you as the possible solution for the full fledged use of Shared Mailboxes. We already can use Shared Mailboxes from M365 as INBOXES without any problems, so first of all thanks for an excellent extension.

    When it comes to SENDING mails using a shared mailbox we run into severe limitations with the known workaround of sending with the personal mail or temporarily licencing the shared mailbox as a user. I investigated escpecially into the latter and it pointed me to the right direction as I think. Here is what I found when using Graph API for sending mails, SMTP is restricted too narrow here for me:

    The Microsoft GRAPH API has TWO endpoints for sending mail with fully different behaviour. The URI

    Code:
    POST /me/sendMail
    is strictly limited to the use for personal (and thus LICENCED !!!) mailboxes. This was the hint that I was missing. The second URI

    Code:
    POST /users/{id | userPrincipalName}/sendMail
    is for use with shared mailboxes where the placeholder ist then replaced with the mailadress of the Shared Mailbox, e.g. /users/forum@espocrm.com/sendMail.

    Unfortunately in one of the base configuration / properties file of the extension - do not remember exactly which one and cannot check while writing this ... - there is the FIRST Url hard coded as the base URL for the complete extension.

    I did not dive too deep into the code of the module but is there any way of "easily" implementing this logic:
    • if mail account is "Personal Mail Account" then use /me/SendMail as the baseURL
    • if mail account is "Group Mail Account" then use /users/{id | userPrincipalName}/sendMail as baseURL
    This would probably eliminate every problem we have with this. As far as I can see from here: user: sendMail - Microsoft Graph v1.0 | Microsoft Learn the headers and body payload are the same, so main point to take care of will be the construction of the URL

    What do you think, Yuri?

    Regards
    Michael
  • yuri
    EspoCRM product developer
    • Mar 2014
    • 10034

    #2
    Hi Miachael,

    Is not `/me/sendMail` the same as `/users/name@domain/sendMail` if the group email account is connected under the 'name@domain' user? If you connect to group email accounts under 'name@domain' it will achieve the same result as if we changed the endpoint I believe.

    Comment

    • macistda
      Senior Member
      • Jul 2022
      • 118

      #3
      It is also a problem where the sent E-Mails arrive in "Sent Items". For a SharedMailbox MSFT says that the way not to save the E-Mail at the licenced Mailbox is together with Outlook via a registry reg add "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\1 6.0\ Outlook\Preferences" /v DelegateSentItemsStyle /d 1 /t REG_DWORD /f
      for deleted items also: reg add "HKEY_CURRENT_USER\Software\Microsoft\Office\1 6.0\ Outlook\Options\General" /v DelegateWastebasketStyle /t REG_DWORD /d 4 /f

      If you don't implement it that way, maybe the E-Mails are stored twice, in in the SharedMailbox AND the User (Licenced) Mailbox:
      Powershell helps solving that problem.

      Set-Mailbox <SharedMailboxName> -MessageCopyForSentAsEnabled $true
      Set-Mailbox <SharedMailboxName> -MessageCopyForSendOnBehalfEnabled $true
      Activate if "SendAs" is used or "On behalf of".

      Comment

      • TMAG_mbohlender
        Junior Member
        • May 2026
        • 8

        #4
        Hi Yuri,

        Originally posted by yuri
        Hi Miachael,

        Is not `/me/sendMail` the same as `/users/name@domain/sendMail` if the group email account is connected under the 'name@domain' user? If you connect to group email accounts under 'name@domain' it will achieve the same result as if we changed the endpoint I believe.
        just returned from vacation ... sorry for the late reply. Yes it is (technically) the same but it is in contrast to the purpose of a shared mailbox. Let's take this setup:

        Personal account: person@domain ---> full licensed M365 user
        Shared Mailbox: shared@domain --> NOT a user (even technically ...)

        The way to go in M365 is to grant person@domain the necessary permissions on shared@domain via the Exchange Admin Center. By this you can "Read", "Send on Behalf" or "Send as" when using shared. However shared@domain is not a user, does not take a licence and cannot sign in. As such, you cannot use shared@domain to connect EspoCRM to M365 with this account and you cannot use shared@domain to directly connect to the GraphAPI Endpoints. For this you must use person@domain.

        I know the comparison is totally wrong, but you can think of a shared mailbox as a "public folder" in the elder onPrem Exchange environments.

        And this is, where the two endpoints come into the game:

        /me/SendMail takes its belonging user context ALWAYS from the logged in user and is by design hard coded to the personal mailbox of this user. A user always has only ONE personal mailbox in M365 no matter what you try. So this is perfectly 1:1

        Without the second endpoint it would be simply impossible to make use of the shared mailbox with GraphAPI as you cannot login as "shared@domain" and as such /me/Sendmail" cannot bind to anything. The second endpoint takes this binding from the user princial that is contained in the URL of the endpoint and compares this to the logged in user (the one that you use to connect to M365 from Espo) to check for persmissions etc.

        As far as I see from the documentation: from this point on, the GraphAPI behaves exactly the same as if you were using the shared mailbox in a second browser tab in parallel to your personal mailbox in the first tab. That means: sent mails are stored in the mailbox that you have OPEN in the browser.

        macistda : I know these "hacks" but Outlook Classic is not a good way to effectively work with shared mailboxes in M365 and it often hides the "right way" from the user. Storing emails when sending is such a thing. Outlook Classic still thinks of your personal mailbox as the "primary mailbox". This however is an old and odd way for this, as is fully undermines the concept of the shared mailboxes. And even if you select the right "FROM" address Outlook still thinks it has to store the Mail in "personal/sent".

        Conclusion: when converting a shared mailbox to a licenced user, the two endpoints become the same. But this is not the way it is meant to be used

        Regards
        Michael

        Comment

        • macistda
          Senior Member
          • Jul 2022
          • 118

          #5
          TMAG_mbohlender I know, the case is that users want to use Classic Outlook. Furthermore, Classic offers several additional features not found in the "New" Outlook. Many things are missing there. Far too few features in the new Outlook for power users.Things get really bad when people have to work with shared mailboxes and have all of them linked, for example, info@, which is also fully licensed. Especially when sending emails.

          Comment

          • TMAG_mbohlender
            Junior Member
            • May 2026
            • 8

            #6
            macistda: I am with you on this ... the current situtation with NEW and CLASSIC outlook is a mess. While I think that for 90-95% of Outlook users the feature set of the new (and WEB) outlook would be sufficient, Microsoft is very successful in hiding this fact behind an "made for idiots" simplified UI. I absolutely hate the new compact view of the icon bar that both new Outlook and OWA start with when opened for the first time. It makes both apps look like a "hobby made email client"

            And for the remaining 5% of users that I would see as the real power users the new apps will probably never reach the full feature set of classic outlook by design and decision it seems. Sad, but most likely it will end like this.

            In the meantime I had the time to check for the original problem and it is, as I expected. For testing purpose I made a hardcoded change in the outlook.php file in the CLIENST folder and forced my system to use /user/{email}/sendmail and it works as expected. I am still facing a permission problem inside our M365 tenant for the app registration but this is something my M365 admin has so sort out

            Comment

            Working...