Microsoft Graph mail driver

mschoon85 commented 2 months ago

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

ssddanbrown commented 2 months ago

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.

mschoon85 commented 2 months ago

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

ssddanbrown commented 2 months ago

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 1 month ago

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.

BookStackApp / BookStack