Microsoft Graph mail driver #4942

New Issue

OVERLORD · 2026-02-05T09:28:12+03:00

OVERLORD commented

2026-02-05 09:28:12 +03:00

Originally created by @mschoon85 on GitHub (Sep 6, 2024).

Attempted Debugging

I have read the debugging page

Searched GitHub Issues

I have searched GitHub for the issue.

Describe the Scenario

Hi @ssddanbrown,

In a previous ticket, it was mentioned that Windows Server with Apache may not be suitable for production. Consequently, I began setting up an Ubuntu server with Docker. Currently, I encounter issues when saving a new page or editing an existing one. The log files indicate SMTP connection errors, which makes sense as the new server lacks access to our internal SMTP server. In attempting to resolve this, I'm considering the possibility of using MS Graph for mailing. Could this be configured with the settings in the .env file, as shown below?

MAIL_DRIVER=msgraph
MAIL_MS_GRAPH_CLIENT_ID=your-application-client-id
MAIL_MS_GRAPH_TENANT_ID=your-tenant-id
MAIL_MS_GRAPH_CLIENT_SECRET=your-client-secret
MAIL_MS_GRAPH_FROM_ADDRESS=your-email@example.com
MAIL_MS_GRAPH_FROM_NAME=BookStack

Kind regards,

Michel

Exact BookStack Version

24.05.3

Log Content

[2024-09-06 12:05:32] production.ERROR: Connection could not be established with host "xxx:25": stream_socket_client(): php_network_getaddresses: getaddrinfo for smtp.xxx failed: Name does not resolve {"userId":54,"exception":"[object] (Symfony\Component\Mailer\Exception\TransportException(code: 0): Connection could not be established with host "smtp.xxx:25": stream_socket_client(): php_network_getaddresses: getaddrinfo for smtp.xxx failed: Name does not resolve at /app/www/vendor/ssddanbrown/symfony-mailer/Transport/Smtp/Stream/SocketStream.php:154)

Hosting Environment

Ubuntu 24.04 with docker

Originally created by @mschoon85 on GitHub (Sep 6, 2024). ### Attempted Debugging - [X] I have read the debugging page ### Searched GitHub Issues - [X] I have searched GitHub for the issue. ### Describe the Scenario Hi @ssddanbrown, In a previous ticket, it was mentioned that Windows Server with Apache may not be suitable for production. Consequently, I began setting up an Ubuntu server with Docker. Currently, I encounter issues when saving a new page or editing an existing one. The log files indicate SMTP connection errors, which makes sense as the new server lacks access to our internal SMTP server. In attempting to resolve this, I'm considering the possibility of using MS Graph for mailing. Could this be configured with the settings in the .env file, as shown below? MAIL_DRIVER=msgraph MAIL_MS_GRAPH_CLIENT_ID=your-application-client-id MAIL_MS_GRAPH_TENANT_ID=your-tenant-id MAIL_MS_GRAPH_CLIENT_SECRET=your-client-secret MAIL_MS_GRAPH_FROM_ADDRESS=your-email@example.com MAIL_MS_GRAPH_FROM_NAME=BookStack Kind regards, Michel ### Exact BookStack Version 24.05.3 ### Log Content [2024-09-06 12:05:32] production.ERROR: Connection could not be established with host "xxx:25": stream_socket_client(): php_network_getaddresses: getaddrinfo for smtp.xxx failed: Name does not resolve {"userId":54,"exception":"[object] (Symfony\\Component\\Mailer\\Exception\\TransportException(code: 0): Connection could not be established with host \"smtp.xxx:25\": stream_socket_client(): php_network_getaddresses: getaddrinfo for smtp.xxx failed: Name does not resolve at /app/www/vendor/ssddanbrown/symfony-mailer/Transport/Smtp/Stream/SocketStream.php:154) ### Hosting Environment Ubuntu 24.04 with docker

OVERLORD added the 🐕 Support label 2026-02-05 09:28:12 +03:00

OVERLORD closed this issue

2026-02-05 09:28:14 +03:00

OVERLORD commented

2026-02-05 09:28:15 +03:00

@ssddanbrown commented on GitHub (Sep 7, 2024):

Hi @mschoon85,
I'm not keen on supporting vendor-specific drivers/options for mailing, as I'd prefer to keep to open standards where possible to avoid the maintenance burden of supporting/documenting/maintaining vendor specific options.

@ssddanbrown commented on GitHub (Sep 7, 2024): Hi @mschoon85, I'm not keen on supporting vendor-specific drivers/options for mailing, as I'd prefer to keep to open standards where possible to avoid the maintenance burden of supporting/documenting/maintaining vendor specific options.

OVERLORD commented

2026-02-05 09:28:18 +03:00

@mschoon85 commented on GitHub (Sep 10, 2024):

Hi @ssddanbrown,

Thank you for your quick response. I completely understand your perspective on avoiding vendor-specific solutions and adhering to open standards to reduce maintenance and dependencies. However, given the upcoming changes regarding Basic Authentication (Basic Auth), I’d like to explain why I’m considering using MS Graph with OAuth2.

Difference between Basic Auth and OAuth:

1. Basic Authentication (Basic Auth):

How it works: A username and password are sent directly to the server in plain text (though encrypted via SSL/TLS).
Risks: Vulnerable to phishing, man-in-the-middle attacks, and brute-force attempts because credentials are exchanged directly.

Example in my current setup:

MAIL_HOST=smtp.myserver.lan
MAIL_PORT=25
MAIL_VERIFY_SSL=false

2. OAuth (Open Authorization):

How it works: OAuth uses access tokens instead of login credentials. These tokens expire after a set time and have limited permissions.
Benefits: Much more secure than Basic Auth. Less vulnerable to credential theft since no login credentials are directly exchanged.
Application to my scenario: Migrating to Exchange Online would require OAuth configuration keys like Client ID, Client Secret, and tokens.

Microsoft’s Phase-out of Basic Auth:

Microsoft has announced that Basic Authentication for SMTP will be completely phased out by September 2025. After this point, only OAuth will be supported for SMTP AUTH in Exchange Online. This change is essential for reducing security risks. For more details, please refer to: https://ourcloudnetwork.com/prepare-for-exchange-online-basic-auth-permanent-retirement and https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-retire-basic-auth-for-client-submission-smtp/ba-p/4114750

Proposal:

While I understand the desire to avoid vendor-specific solutions, I believe that supporting OAuth2 would be a broadly applicable and future-proof solution. OAuth2 is widely used by many cloud providers and offers a modern, secure method for authentication.

I’m open to your suggestions on how we can address these challenges while staying aligned with open standards.

Best regards,
Michel

@mschoon85 commented on GitHub (Sep 10, 2024): Hi @ssddanbrown, Thank you for your quick response. I completely understand your perspective on avoiding vendor-specific solutions and adhering to open standards to reduce maintenance and dependencies. However, given the upcoming changes regarding **Basic Authentication** (Basic Auth), I’d like to explain why I’m considering using **MS Graph with OAuth2**. ### Difference between Basic Auth and OAuth: **1. Basic Authentication (Basic Auth)**: - **How it works**: A username and password are sent directly to the server in plain text (though encrypted via SSL/TLS). - **Risks**: Vulnerable to phishing, man-in-the-middle attacks, and brute-force attempts because credentials are exchanged directly. - **Example in my current setup**: ```bash MAIL_HOST=smtp.myserver.lan MAIL_PORT=25 MAIL_VERIFY_SSL=false ``` **2. OAuth (Open Authorization)**: - **How it works**: OAuth uses access tokens instead of login credentials. These tokens expire after a set time and have limited permissions. - **Benefits**: Much more secure than Basic Auth. Less vulnerable to credential theft since no login credentials are directly exchanged. - **Application to my scenario**: Migrating to Exchange Online would require OAuth configuration keys like **Client ID**, **Client Secret**, and tokens. ### Microsoft’s Phase-out of Basic Auth: Microsoft has announced that **Basic Authentication for SMTP** will be completely phased out by **September 2025**. After this point, only **OAuth** will be supported for SMTP AUTH in Exchange Online. This change is essential for reducing security risks. For more details, please refer to: https://ourcloudnetwork.com/prepare-for-exchange-online-basic-auth-permanent-retirement and https://techcommunity.microsoft.com/t5/exchange-team-blog/exchange-online-to-retire-basic-auth-for-client-submission-smtp/ba-p/4114750 ### Proposal: While I understand the desire to avoid vendor-specific solutions, I believe that supporting **OAuth2** would be a broadly applicable and future-proof solution. OAuth2 is widely used by many cloud providers and offers a modern, secure method for authentication. I’m open to your suggestions on how we can address these challenges while staying aligned with open standards. Best regards, Michel

OVERLORD commented

2026-02-05 09:28:20 +03:00

@ssddanbrown commented on GitHub (Sep 10, 2024):

Microsoft has announced that Basic Authentication for SMTP will be completely phased out by September 2025. [...] This change is essential for reducing security risks.

But they will still provide other mail-specific services that will support standard SMTP auth.

While I understand the desire to avoid vendor-specific solutions, I believe that supporting OAuth2 would be a broadly applicable and future-proof solution. OAuth2 is widely used by many cloud providers and offers a modern, secure method for authentication.

But OAuth2, from what I've seen so far, has vendor specific quirks that often require vendor specific implementation, maintenance and testing. If multiple vendors have jumped into a strong non-service-specific implementation (like OIDC is to OAuth for authentication) I'd be happy to get into that.
Otherwise, it's kinda frustrating to have to bend to the will of a massive entity like Microsoft at our cost, instead of working to vendor agnostic standards.

@ssddanbrown commented on GitHub (Sep 10, 2024): > Microsoft has announced that Basic Authentication for SMTP will be completely phased out by September 2025. [...] This change is essential for reducing security risks. But they will still provide other mail-specific services that will support standard SMTP auth. > While I understand the desire to avoid vendor-specific solutions, I believe that supporting OAuth2 would be a broadly applicable and future-proof solution. OAuth2 is widely used by many cloud providers and offers a modern, secure method for authentication. But OAuth2, from what I've seen so far, has vendor specific quirks that often require vendor specific implementation, maintenance and testing. If multiple vendors have jumped into a strong non-service-specific implementation (like OIDC is to OAuth for authentication) I'd be happy to get into that. Otherwise, it's kinda frustrating to have to bend to the will of a massive entity like Microsoft at our cost, instead of working to vendor agnostic standards.

OVERLORD commented

2026-02-05 09:28:22 +03:00

@ssddanbrown commented on GitHub (Oct 3, 2024):

Since there's been no discussion on this I'll go ahead and close it off.

If there's a way to support mail OAuth in a reasonably standard and vendor abstract way, which does not have to be built/tested specifically for each provider, I'd be happy to hear about that and potentially build accordingly.

@ssddanbrown commented on GitHub (Oct 3, 2024): Since there's been no discussion on this I'll go ahead and close it off. If there's a way to support mail OAuth in a reasonably standard and vendor abstract way, which does not have to be built/tested specifically for each provider, I'd be happy to hear about that and potentially build accordingly.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#4942