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
Attachment:
signature.asc
Description: PGP signature
