Back in the days when spam was not a thing, and the internet was simpler, if
you wanted to give users an email address under your domain, you’d just add
a forward to your mail server configuration. That took care of the receiving
side, and sending could usually be done with whatever mail server people
already had. Nobody bothered checking the envelope sender or
anyway, and mail servers would happily accept mail from everyone and everywhere
as long as it seemed that it had ended up in the right place. And it was good.
And then along came spam.
SPF and DKIM? You need to run your own SMTP.
Now, of course, this is not a theoretical example. MacPorts has
always provided its project members with an email alias under
However, to fight spam, smart people came up with a multitude of ways to figure
out whether mail received by a mail server was actually sent by who the
envelope claimed to have sent it. There are currently two major mechanisms for
this purpose: Sender Policy Framework (SPF) and
DomainKeys Identified Mail (DKIM).
SPF allows administrators to publish a list of servers that are permitted to
send mail on behalf of a specific domain. Of course, since MacPorts did not
actually provide an SMTP server and expected our developers to use their own
ones, we had no way of gathering such a list and would thus allow the entire
internet to send mail on behalf of
@macports.org, something more and more
mail providers are nowadays treating as an indicator for spam.
DKIM, on the other hand, adds a cryptographic signature to certain selected
fields of an email when it passes through the outgoing server, to be verified
against a public key published in DNS on the receiving end. But again, since
there was no single central SMTP serving
@macports.org, we could not ensure
that all mails had such a signature, and thus could not enable DKIM – which
providers are also using as an indication for spam.
We did know for a while that we would eventually have to setup email submission, but have been delaying the actual setup, since we needed a way to configure the passwords that should be used for SMTP. Since MacPorts' migration to GitHub in October 2016, we only use GitHub’s OAuth2 for authentication. And while mail clients are slowly implementing support for that in SMTP and IMAP, it is not yet widespread enough to be usable in our case.
So, my todo list came down to
- Write a web application that uses GitHub OAuth2 to authenticate users
- Allow setting the SMTP password in a database from that web application. I figured a database would be a good idea, since it’s the most convenient resource to access from different unix users, unlike files and/or sockets where I would have had to configure groups.
- Configure SMTP authentication against the passwords in the database into Postfix.
Sounds simple enough. Boy, was I wrong…