Rejuvenate the Postfix package
a project by varkoly
Updated 9 days ago. 1 hackers ♥️. 2 followers.

Description

The setup script of postfix /usr/sbin/config.postfix is very old and very often causes problems. We need to discuss whether we need such a script at all. Postfix is extremely complex. Configuring everything via scripts and sysconfig variables is impossible and ultimately does not make things any easier. It is difficult to decide what should be configurable in this way and what should not. Since openSUSE/SLES 16.0, there is no longer a graphical tool that would really simplify configuration. Furthermore, the basic configuration of Postfix is a one-time task that requires a great deal of expertise. During operation, only the postmaps need to be maintained.

Goals

The main goal is to deliver a robust postfix package which works out of the box and the updates can not break the configuration.

Resources

I am looking for openSUSE/SLES users who use Postfix intensively and have clear expectations regarding Postfix maintenance. The only resource I need is ideas.

Join this project

Looking for hackers with the skills:

postfix configs setup

This project is part of:

Hack Week 25

Activity

  • 6 days ago: mwilck liked this project.
  • 8 days ago: adkorte joined this project.
  • 9 days ago: varkoly added keyword "postfix" to this project.
  • 9 days ago: varkoly added keyword "configs" to this project.
  • 9 days ago: varkoly added keyword "setup" to this project.
  • 9 days ago: varkoly started this project.
  • 9 days ago: varkoly originated this project.


    • Comments

    • varkoly
      6 days ago by varkoly | Reply

      There are also modules for the automatic configuration of postfix:

      SaltStack:

      Ansible:

      It therefore makes more sense to use these modules instead of creating your own configuration scripts.

    • varkoly
      3 days ago by varkoly | Reply

      You can follow my work in my home project

    • varkoly
      1 day ago by varkoly | Reply

      The actual version will be with the original main.cf and master.cf I've made following changes:

      • Removed all patches and scripts which has modified the original main.cf and master.cf
      • Removed all stuff corresponding the file list and permissions of postfix files
      • Removed ExecStartPre from postfix.service:
      • /usr/lib/postfix/systemd/config_postfix
      • /usr/lib/postfix/systemd/update_chroot
      • /usr/lib/postfix/systemd/update_postmaps
      • /usr/lib/postfix/systemd/cond_slp register
      • Removed ExecStopPost from postfix.service:
      • /usr/lib/postfix/systemd/cond_slp deregister
      • Add ExecStartPre into postfix.service:
      • /usr/sbin/postfix set-permissions
      • /sbin/postalias /etc/aliases

      Now we can provide a postfix package which is delivered as designed by the developer. With this service file it can start out-of-the-box. If someone need some start scripts like the /usr/lib/postfix/systemd/update_chroot this can be provieded easyly:

      • Create a directory: mkdir -p /usr/lib/systemd/system/postfix.service.d
      • Create a file: /usr/lib/systemd/system/postfix.service.d/10-adapt-service.conf

      It is also possible to create additional packages which contains only the additional service configurations file and the neccessary scripts. For example postfix-create-chroot.

    Similar Projects

    Help Create A Chat Control Resistant Turnkey Chatmail/Deltachat Relay Stack - Rootless Podman Compose, OpenSUSE BCI, Hardened, & SELinux by 3nd5h1771fy

    Description

    The Mission: Decentralized & Sovereign Messaging

    FYI: If you have never heard of "Chatmail", you can visit their site here, but simply put it can be thought of as the underlying protocol/platform decentralized messengers like DeltaChat use for their communications. Do not confuse it with the honeypot looking non-opensource paid for prodect with better seo that directs you to chatmailsecure(dot)com

    In an era of increasing centralized surveillance by unaccountable bad actors (aka BigTech), "Chat Control," and the erosion of digital privacy, the need for sovereign communication infrastructure is critical. Chatmail is a pioneering initiative that bridges the gap between classic email and modern instant messaging, offering metadata-minimized, end-to-end encrypted (E2EE) communication that is interoperable and open.

    However, unless you are a seasoned sysadmin, the current recommended deployment method of a Chatmail relay is rigid, fragile, difficult to properly secure, and effectively takes over the entire host the "relay" is deployed on.

    Why This Matters

    A simple, host agnostic, reproducible deployment lowers the entry cost for anyone wanting to run a privacy‑preserving, decentralized messaging relay. In an era of perpetually resurrected chat‑control legislation threats, EU digital‑sovereignty drives, and many dangers of using big‑tech messaging platforms (Apple iMessage, WhatsApp, FB Messenger, Instagram, SMS, Google Messages, etc...) for any type of communication, providing an easy‑to‑use alternative empowers:

    • Censorship resistance - No single entity controls the relay; operators can spin up new nodes quickly.
    • Surveillance mitigation - End‑to‑end OpenPGP encryption ensures relay operators never see plaintext.
    • Digital sovereignty - Communities can host their own infrastructure under local jurisdiction, aligning with national data‑policy goals.

    By turning the Chatmail relay into a plug‑and‑play container stack, we enable broader adoption, foster a resilient messaging fabric, and give developers, activists, and hobbyists a concrete tool to defend privacy online.

    Goals

    As I indicated earlier, this project aims to drastically simplify the deployment of Chatmail relay. By converting this architecture into a portable, containerized stack using Podman and OpenSUSE base container images, we can allow anyone to deploy their own censorship-resistant, privacy-preserving communications node in minutes.

    Our goal for Hack Week: package every component into containers built on openSUSE/MicroOS base images, initially orchestrated with a single container-compose.yml (podman-compose compatible). The stack will:

    • Run on any host that supports Podman (including optimizations and enhancements for SELinux‑enabled systems).
    • Allow network decoupling by refactoring configurations to move from file-system constrained Unix sockets to internal TCP networking, allowing containers achieve stricter isolation.
    • Utilize Enhanced Security with SELinux by using purpose built utilities such as udica we can quickly generate custom SELinux policies for the container stack, ensuring strict confinement superior to standard/typical Docker deployments.
    • Allow the use of bind or remote mounted volumes for shared data (/var/vmail, DKIM keys, TLS certs, etc.).
    • Replace the local DNS server requirement with a remote DNS‑provider API for DKIM/TXT record publishing.

    By delivering a turnkey, host agnostic, reproducible deployment, we lower the barrier for individuals and small communities to launch their own chatmail relays, fostering a decentralized, censorship‑resistant messaging ecosystem that can serve DeltaChat users and/or future services adopting this protocol

    Resources