The discussion revolves around the possibility of sending emails via API instead of SMTP in Discourse, prompted by issues with Microsoft Outlook/Hotmail users receiving emails as spam. itsbhanusharma reports that emails sent through SMTP relays (e.g., Mailgun, ElasticEmail) are often flagged as spam by Microsoft’s filtering system, while using Mailgun’s API resolves the issue. codinghorror dismisses the idea, arguing that email delivery is unaffected by the method used. mpalmer criticizes Mailgun’s explanation, noting that the originating IP can be stripped regardless of SMTP or API use and that relying on such headers is unreliable. itsbhanusharma confirms the API workaround works but remains skeptical of Microsoft’s spam filtering, noting the issue persists across different SMTP providers and that self-hosting SMTP is not ideal. The thread highlights a real-world email delivery problem and the debate over whether Discourse should support API-based email sending.
One of my discoure install has particular majority of users using Microsoft outlook/hotmail email accounts and the microsoft spam rejection system does some weird filtering and puts almost every email sent via relay smtp (e.g. services like mailgun, elasticemail etc.) This had been creating a lot of trouble lately. I’ve spent days talking to mailgun support and after all the logs and tests, their final word was to try sending mails via their API instead of SMTP credentials.
I believe this may be an issue with the server’s originating IP. When sending via SMTP, the server that creates the message has its IP added as the “originating IP” into the headers. If the IP is not properly configured for SMTP, the recipient’s filters may flag the messages as Spam. I would recommend sending via our API instead. Messages sent through our API will use the sending IP assigned by Mailgun as the Originating IP, instead of the IP for your server.
as most reputable email services support API, can discourse support emails via their API instead of SMTP?
Mailgun support are talking out their rear end. They could just as easily strip this purported “originating IP” information from the headers when relaying via SMTP as via API, and nobody with two braincells to rub together trusts any information added by relaying systems, because (a) it’s all so trivial to forge, and (b) the WHOLE POINT of relaying through a service like mailgun is because the originating system isn’t properly configured for SMTP.
I also didn’t get their point but actually, using their API actually causes the mails to deliver as normal and otherwise the mails end up in spam of specifically one service provider i.e. microsoft.
I don’t really trust microsoft when it comes to reliable spam protection but when there is a majority of users using their service, I thought that maybe it’s worth investing upon some solution to figure this out.
also, the same happens even if the SMTP provider is changed. I’ve replicated this same behaviour with mailgun & elasticemail as senders. Hosting my own SMTP doesn’t seems like a Good idea either.
I’m still waiting for them to diagnose the mail headers and come up with some findings.