Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
---|---|---|---|---|---|---|
03_ldap3_by_default.diff | Set default LDAP protocol version to 3 | LaMont Jones <lamont@debian.org> | not-needed | |||
10_openssl_version_check.diff | Disable openssl version check=================================================================== | LaMont Jones <lamont@debian.org> | not-needed | |||
40_chroot_by_default.diff | Set chroot to default enabled=================================================================== | LaMont Jones <lamont@debian.org> | not-needed | |||
41_rmail.diff | Use sendmail's rmail=================================================================== | LaMont Jones <lamont@debian.org> | not-needed | |||
50_LANG.diff | Set LANG=C for HTML documentation build=================================================================== | LaMont Jones <lamont@debian.org> | not-needed | |||
71_debianize_collate.pl.diff | Debianize collate.pl so we can ship it in the package=================================================================== | Scott Kitterman <scott@kitterman.com> | not-needed | 2022-01-04 | ||
Disable-LD_LIBRARY_PATH-check.patch | Disable LD_LIBRARY_PATH check Conflicts with building with eatmydata (e.g. in salsa-ci). |
=?utf-8?q?Christian_G=C3=B6ttsche?= <cgzones@googlemail.com> | not-needed | 2022-10-09 | ||
reproducible | Reproducible Need to sort auxlibs for reproducible. Missed part of upstreaming in 3.9.0. =================================================================== |
Scott Kitterman <scott@kitterman.com> | yes | 2024-07-21 | ||
debian-defaults.patch | Debian-specific defaults for main.cf and master.cf Change a few parameters to match Debian defaults. diff --git a/conf/main.cf b/conf/main.cf |
Michael Tokarev <mjt@tls.msk.ru> | not-needed | 2024-12-19 | ||
debian-run-configure-instance-from-create-missing.patch | run debian-specific configure-instance script from post-install create-missingTue, 17 Dec 2024 09:48:32 +0300 Run debian-provided (mostly chroot setup) script from `post-install create-missing`, which is run when starting a postfix instance. diff --git a/conf/post-install b/conf/post-install |
Michael Tokarev <mjt@tls.msk.ru | not-needed | |||
debian-re-run-startup-through-systemd.patch | re-run postfix start through systemd When `postfix start' (or `postmulti start') command is run from command line, postfix instance is started outside a session manager such as systemd. This is fine for traditional init-based systems, but systemd has a notion of a service which it tracks. Postfix instance started this way line becomes "orphaned", run within user session which started it, confuses session manager and other tools which expects mail service to be running. Systemd exports $INVOCATION_ID when it starts a service. This variable can be used as a (weak) indicator that we're running under systemd, so if it is set, just run `master' process the usual way. But if it is not set, and the system is running under systemd (/run/systemd/system is present), instead of running postfix master process directly, we run the systemd service which corresponds to this instance. Which, in turn, should re-run the same `postfix' command and control will come back to this same place, where we now start `master' the usual way. Only the regular `start' command is handled. All other commands, including `start-fg', are not modified. The service being started is either the main/default postfix instance, if config_directory is /etc/postfix. Or, the service is assumed to be a path unit after /etc/postfix-, like config directory being /etc/postfix-foo for postfix@foo.service, or postfix@foo%2dbar-baz for config directory being /etc/postfix-foo-bar/baz (see man:systemd-escape for details on the naming). Other config directories (not prefixed with /etc/postfix-) are not rescheduled through systemd. Currently $MAIL_VERBOSE and $MAIL_DEBUG are not passed through to the master process started through systemd. It can be implemented if needed. diff --git a/src/postfix/postfix.c b/src/postfix/postfix.c |
Michael Tokarev <mjt@tls.msk.ru> | no | 2024-12-13 | ||
debian-systemd-start.patch | add "debian-systemd-start" subcommand to postfix-script In order to have stricter privileges at runtime, there's a need to split postfix startup procedure to "setup" stage and "runtime" stage, because "setup" stage requires more privileges (for example, it does `create-missing`, which needs chown). In Debian, for systemd startup, we run `postfix check` in ExecStartPre with full privs, and `postfix debian-systemd-start` in regular ExecStart, with restricted privileges. diff --git a/conf/postfix-script b/conf/postfix-script |
Michael Tokarev <mjt@tls.msk.ru> | not-needed | 2024-12-24 | ||
debian-postfix-chroot-cmd.patch | implement "postfix chroot" command Implement `postfix chroot' command to assist chrooting and un-chrooting postfix services in master.cf. The command always ignores postfix services which should never be chrooted, and by default (unless -c option is specified) also ignores custom (unknown, unrecognized) services. postfix chroot [-SXc] query|q - print on|off|mixed postfix chroot [-SXc] - the same as query postfix chroot [-nSXc] on|y - set services to run chrooted postfix chroot [-nSXc] off|n - set services to run non-chrooted -n - do not make actual changes, only show what would be done -S - omit known to be simple/safe services (most internal postfix) -X - omit known to be complex/unsafe services -c - also act on unknown/unrecognized services (which are normally skipped) The more complex ones are basically lmtp, smtp, smtpd, which might need TLS certificates, access to additional SASL data and the like. Some "safe" ones might include a few files in chroot, like /etc/hosts, /etc/localtime, etc. diff --git a/conf/postfix-script b/conf/postfix-script |
Michael Tokarev <mjt@tls.msk.ru> | no | 2024-12-20 | ||
debian-fix-manpages-C-font.patch | fix manpages C font Recent *roff comes without C font (https://bugs.debian.org/1043256). However, man macros has .EX/.EE which can be used. diff --git a/mantools/fixman b/mantools/fixman |
Michael Tokarev <mjt@tls.msk.ru> | no | 2025-01-01 | ||
makedefs-fix-RELEASE_MAJOR-expression.patch | makedefs: fix $RELEASE_MAJOR expression There are 2 issues with the way RELEASE_MAJOR is currently computed in ./makedefs. First, it is not set at all when the system name/release are specified on the command line, so this change moves it a few lines down. And second, the usage of "expr" utility is wrong, as it does not work when the system release is 0.something. Consider: expr 0.foo : '\([0-9]*\)' the ":" expression itself will return the first N digits, which is "0" in this case. But the less widely known thing about expr is that it works with numbers, not strings. So this becomes: expr 0 which, in turn, is false. So while expr utility will produce "0" on output, it will ALSO exit with non-zero status. And the next "exit 1" immediately gets in, so whole makedefs terminates. Fix this by using sed instead of expr. Introduced in 3.0.2. |
Michael Tokarev via Postfix-users <postfix-users@postfix.org> | yes | 2024-12-13 | ||
hurd.patch | hurd support v2 diff --git a/makedefs b/makedefs |
Michael Tokarev <mjt@tls.msk.ru> | no | 2024-12-20 | ||
sqlite-open-fix.patch | sqlite: do not create the DB, open it read-only, and give error message Currently, postfix creates (empty, table-less) sqlite database if not exists, which is kinda unexpected provided postfix can not even load data to it. Also, the database is always open in read-write mode, despite postfix only performs queries. Also, when open actually fails, the error message is unhelpful: Unfortunately, sqlite does not give good hint about the reason why the database can't be open, for example: fatal: sqlite:/etc/postfix/db.cf: Can't open database: \ unable to open database file? Obviously this is an sqlite omission/defect, but we can work around it in postfix by also providing the strerror(errno) here. This patch does a few things: 1. It changes sqlite3_open() into sqlite3_open_v2() which accepts 2 more arguments, notable open flags (similar to open(2)) - where we only pass SQLITE_OPEN_READONLY, without SQLITE_OPEN_CREATE. 2. It replaces msg_fatal() call when we weren't able to open the database file into dict_surrogate() like in other places when open error occurs, and continues. 3. It makes the error message much more useful by including the database file name it tried to open, and strerror(errno) (%m), so the error message (when attempting to use the dict_surrogate) becomes: fatal: sqlite:/etc/postfix/db.cf: open database t.dbx: \ unable to open database file: No such file or directory sqlite3_open_v2() is available since sqlite version 3.5.0 (see https://www.sqlite.org/34to35.html), and compatibility wrapper is provided for older releases, exactly like sqlite3_prepare_v2(). |
Michael Tokarev <mjt@tls.msk.ru> | yes | 2025-01-03 |