Providing project emails

An over-filled mail box attached to a wall

If your project has a domain, you may accept inbound email. And if you accept inbound email, you may offer email addresses to contributors. And this can get complicated.

In 2026, you are almost certainly not running a full-fledged mail service for your project. By which I mean you don’t provide accounts that can send, receive, and store email from a server that you run. Because we cannot behave ourselves, the email industry has attempted to adopt stronger security practices. The end result of which is that if you’re running your own email server, a lot of the mail you send gets send to the recipient’s spam folder (or worse: dropped by the server). This is 100% not a valuable use of time for an open source project. But just because you’re not running a full email system, that doesn’t mean you can’t give your contributors aliases that point to their real inboxes.

Why would you do this? Well, it can be a (basically) free way to reward regular contributors. Giving them a project email address is a form of recognition. It’s a status symbol that they can take pride in. Plus, it has some practical advantages. They can use it as a filtering tool: mail sent to bcotton@coolfossproject.example.org may end up in the same account as all of my other email, but I can filter anything sent to that address to my “Cool FOSS Project” folder. It’s also a signal to others that I am doing work on behalf of the project.

Unfortunately, the asymmetry of email services makes this (particularly the last time) less effective than it once was. A lot of people, myself included, would use the project email alias in a “send as” setup so that we could not only receive email using the alias, but (appear to) send it, as well. A big chunk of the world uses GMail for email, and GMail will no longer support sending from third-party addresses beginning in January 2027.

So should you still provide project emails? I wouldn’t go out of the way to at this point. But if you have the pieces in place for other reasons, it’s a nice thing to offer your contributors.

This post’s featured photo by Thanhy Nguyen on Unsplash.

Ben is the Open Source Community Lead at Kusari. He formerly led open source messaging at Docker and was the Fedora Program Manager for five years. Ben is the author of Program Management for Open Source Projects. Ben is an OpenSSF Ambassador and frequent conference speaker. His personal website is Funnel Fiasco.

Share

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.