NOTE THAT SENDMAIL 126.96.36.199 IS NOT AN OFFICIAL RELEASE. THIS IS A TESTING VERSION AND THE POSTGRESQL DATABASE MAP SUPPORT WAS ADDED BY KALEVI KOLTTONEN <firstname.lastname@example.org>. SO PLEASE DO NOT SEND BUG REPORTS ABOUT THE POSTGRESQL FEATURE TO THE SENDMAIL FOLKS.
I CHOSE SENDMAIL 188.8.131.52 AS A DEVELOPMENT TARGET BECAUSE AS OF THIS WRITING (JANUARY 19TH, 2019), IT IS THE LATEST SNAPSHOT THAT PROOFPOINT HAS RELEASED.
YOU MUST UNDERSTAND THAT THE POSTGRESQL MAP SUPPORT IS NOT GOING TO BE IN THE OFFICIAL SENDMAIL 8.16. THIS PROJECT IS JUST MY PERSONAL EXPERIMENT.
It is now Saturday, January 19th, 2019. Back in 2018 I got the idea of trying to add PostgreSQL database support for Sendmail. A stock Sendmail already supports LDAP, Berkeley DB, socket maps, and so on.
Like many old-school Unix users know, Sendmail is a famous MTA written by Eric Allman. PostgreSQL is a well-known object-relational_database that supports SQL and has features comparable to the Oracle databases. Both Sendmail and PostgreSQL are released under a liberal, open source licensing, so it is possible to study their sources and make changes to them.
Personally, I would prefer to always release my own code under Richard Stallman's GNU General Public License, but in this case I think it is best to make an exception. So the experimental PostgreSQL map code presented here is released under the same license as Sendmail itself. I am not a lawyer, but I guess the Sendmail license is a kind of a BSD license.
When Sendmail does key-value lookups using its pretty weird configuration language, those calls are largely database agnostic. It means that the rulesets refer to the databases using a unique name that is defined using a
K-line directive such as:
The definition above tells Sendmail that there is a Berkeley DB hash type database in the optional file
/etc/mail/access.db and the name of that database map is
The rulesets do not know, or care about, the fact that
access is implemented using a Berkeley DB hash. It could as well be an LDAP-based map and the rulesets would continue to work just the same.
I have added an experimental support for PostgreSQL datamaps maps for the Sendmail testing release 184.108.40.206. You can identify this test version using the following command as root:
Below you can see that it is
Version 220.127.116.11-pgmap and that
PGMAP appears in the
Compiled with: section:
Here are the RPMs for Fedora Linux 29.
If you need just the PostgreSQL map support patch, you can download it here:
To install the binary RPM and tools for creating configurations, you can do:
In case you are not using my RPMs, you could compile Sendmail from the
tar.gz with the following in the
I have told Sendmail that
mailertable are PostgreSQL based database maps:
In addition I have:
/etc/mail/sendmail.cf needs to be rebuilt:
I have hardcoded names
value in the PostgreSQL
SELECT statement in my C code. So you must create a PostgreSQL table having
Here is a sample of my test data in PostgreSQL 10.6 database called
id field having type
INTEGER. The fields
value are of type
TEXT and they are what Sendmail is interested in. If you want to have extra fields (e.g. for including comments, or other metadata for the
key), that is perfectly fine as long as you have
I inserted domain name
/etc/mail/virtuserdomains so that Sendmail will use virtusertable for addresses in that
Finally I tested the PostgreSQL based
virtusertable with the address
As you can see, when using
virtuser map, Sendmail opened the initial connection to PostgreSQL database. The second
mailertable informed us that it is using a cached connection. That is exactly how Sendmail is supposed to work, i.e. it reuses connections whenever possible.
After the database lookups had been done, Sendmail closed the PostgreSQL database connection and marked all maps using it as closed (e.g.
PostgreSQL based database maps seem to work with Sendmail 18.104.22.168. However, I have done only a few tests and cannot claim that the C code is flawless. This is just an experiment, nothing more, nothing less.
Please note that I have not implemented any kind of timeout mechanism for database connections or the queries. Despite that I am pretty happy with the way how this patch turned out to be. Many thanks to Unto Sten for valuable help and advice.
Have fun!Kalevi Kolttonen <email@example.com>