> On 26 May 2025, at 1:55 AM, brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > 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. Fair, I was thinking proprietary protocols might not be accepted upstream. I think its best to use an SMTP bridge, or use the sendmail-cmd like capabilities of send-email.
