github.com will be retiring its Email Services by the end of 2018. Open source projects need to have a solid reliable solution for receiving real-time full diff emails. github.com is not interested in providing this service, despite many attempts in the past to convince them to do so. They now provide a webhooks service that triggers an event on each commit, but it's up to us to turn it into a functional service. One project at a time.
I have found a mostly sufficient, almost free 5-component solution:
I use a free smtp relay which only allows 100 emails a day. What happens if the project gets more emails? Some of the overflow can be attempted to be re-sent the next day, but the queue will only be able to catch up if the number of commits goes down.
As it can be seen from the diagram there are several points of failure, in particular once the email is sent out it goes through at least 2 servers, each may decide to filter/drop some emails. One mail server would have been ideal.
It requires a 24/7 server (not free).
It's relatively complicated to setup (but doable), unless you're a sysadmin.
My two main questions:
Do you have any suggestions for an open-source project-friendly:
free reliable smtp relay that will allow more than 100 diff emails daily?
free full diff email service that could do all of the above and just requiring the github webhook configured to point to its servers?
This SO post from 2010 discusses some of these implementation details, but doesn't go into the bigger scope of the problem.
Another similar setup which requires no webhooks, but which is not real-time (crontab-polling) is gitolite.
p.s. if this question better belongs to another SE site please let me know, it has been deemed off-topic on stackoverflow, so softwarerecs seems to be the closest match.