I’m a bit nervous about it because everytime I tried Postfix at home, I couldn’t get it to work for one reason or another. Sendmail is ugly but it has always worked for me.

I replied:

That’s bizarre. For me, Postfix has always “just worked”, while I’ve *never* been able to get Sendmail to do anything useful, despite many hours of study of the Necronomicon (aka “Bat Book”). Maybe I wasn’t pronouncing the arcane incantations correctly. I’m probably lucky that I didn’t accidentally summon a demon (when what I wanted was a daemon).

I tried setting up Sendmail when I was first building my own mail server back in 1995. I fought it for weeks. I finally got sick of the frustration and found Qmail, which has worked pretty well for me. The only thing that was wrong with Qmail at the time was the stupid license.
However, in the last few years I’ve become dissatisfied because the author no longer maintains Qmail. Other people publish patches, but because of the stupid license it isn’t possible to distribute binaries of the patched versions.

On the other hand, Postfix does almost everything I need, has plugins fo the few things I want to add (like greylisting), and has a reasonable license. I’ve switched some of my email processing from Qmail to Postfix, and expect to complete the transition within the next few months. The only reason that I wasn’t able to do the transition quickly is that I’d become somewhat dependent on unusual features of Qmail relating to local delivery control.

Currently I have to turn SELinux “enforcing” off on my server machine in order to allow Postfix to hand off email to Mailman. I hope to find a solution to this soon.

When I first noticed that the mailing lists had stopped working, it took me a while to track it down to a problem with SELinux security contexts. I’m running with the Fedora “targeted” policy. What I eventually discovered was that all of the files in /usr/lib/mailman had somehow gotten the wrong context. They must have had the right context at one time, since the lists worked for a while, and I’m not sure what might have changed them. The /sbin/restorecon program makes it easy to fix this sort of problem. After I did that, I sent out a test message, which I received back from the list, so I thought everything was copacetic.

Today I noticed that it wasn’t working right again. After a bit more time grovelling through log messages and such, I found several problems.

The security context for the postfix-to-mailman-2.1.py script, which I’d installed in /usr/lib/mailman/bin, was system_u:object_r:bin_t, but from the audit log it appears that the Postfix pipe transport program runs as system_u:system_r:postfix_pipe_t, and was failing to invoke the program. I tried to do a “chcon -r
system_r -t postfix_pipe_t postfix-to-mailman-2.1.py” as root, but it reports “permission denied”.

I eventually figured out that the chcon would succeed if I turned off enforcing, did the chcon, then turned it back on.

Unfortunately even after doing that, the Postfix pipe transport program is still not allowed to execute the script. I’m not sure what’s going on, so I’ll have to ask on the Fedora SELinux mailing list.

More surprising is that due to the different recipient_delimiter value, the script was failing for any of the mailing lists that have a hypen in their name, because the line in /etc/master.cf that defines the mailman transport was only passing in the {user} variable, which has anything that looks like a suffix stripped off. I changed the mailman transport line to also pass in {extension}, and changed the script to accept that and if non-null append it (with a hyphen) to the user.
Now it all seems to be working except that I have to run it with enforcing off until I find out how to set the right security context for the script.