Subject: Re: [PATCH RFC] send-mail: add support for Microsoft Graph API

From: "brian m. carlson" <[email-masked]>
Date: Sun, 25 May 2025 20:24:57 +0000

On 2025-05-25 at 11:06:32, Aditya Garg wrote:
> Apart from SMTP, Microsoft also provides a REST API, branded as
> Microsoft Graph for sending mails. Upon testing a bit, I have
> found a few benefits over SMTP. Firstly, SMTP servers of Microsoft
> are kinda slow. On an average, initialising the SMTP server even
> on a fast internet connection takes around 8-10 seconds with
> send-email. Once initialised, subsequent messages sometimes also
> face delays, taking around 3-5 seconds per message, and other
> times they are sent almost instantaneously. Secondly, their SMTP
> server does not respect the Message-ID specified by the user and
> replaces it with their own generated string.
> 
> Microsoft Graph API solves both these problems. It is extremely
> fast, taking around 1 second to send a series of 5 patches, and
> also respects the Message-ID specified by the user.

I don't think we should be adding support for proprietary methods of
sending mail.  There are two standard methods, which are SMTP and the
sendmail binary, that are well known, well understood, and widely
deployed.

It is well known that Microsoft has invented a lot of proprietary
Outlook-specific formats for messages, such as TNEF and MAPI, which we
should also not support because they are poorly defined and not
specified in an open standard.  I would also be opposed to sending mail
in formats or using methods that are proprietary to Google, Amazon, or
any other provider, since we already have clear specifications on how
mail is to be sent that precede this project's existence by some time.

I understand that the Outlook servers may be slow and inefficient as
well as modify the Message-ID, but that's ultimately a problem you need
to address with them and get them to fix.  I should note that I don't
have that problem: I run my own Postfix and Dovecot servers which are
very speedy, and I feel confident any other provider could do so as
well.  I also have never had that problem sending mail through Google's
SMTP server at work.

If this REST API approach is well defined by an RFC or some other open
specification process that the public can participate in and deployed
among a large number of providers, including several open source
implementations, then we might consider adopting it.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA