30.11.2024 19:32, Scott Kitterman via Postfix-users wrote:
For those of you who care about Debian (and to some extent its derivatives),
I'm passing maintainership of the Debian Postfix package to Michael Tokarev.
He's been a long term participant in both Debian and the Postfix community.
Thank y
Hi!
For a long time I thought this problem is due to limitation of mailx email
submission program - when our users submit email message using mailx, their
From: header (which is filled using getpwnam(), with proper First.M.Last)
is not encoded properly but is left as plain 8-bit.
But today I fou
02.12.2024 02:04, Wietse Venema via Postfix-users :
Wietse Venema via Postfix-users:
The cleanup_out_header() function autodetects that a header needs
SMTPUTF8, including headers added with a header_checks PREPEND
action, but that function is not called for headers that are generated
by Postfix
01.12.2024 19:40, Viktor Dukhovni via Postfix-users wrote:
On Sun, Dec 01, 2024 at 07:21:13PM +0300, Michael Tokarev via Postfix-users
wrote:
On the other hand, it shouldn't be a very difficult task to implement this
for local submission given postfix has all the infrastructure available
01.12.2024 19:07, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
Dec 01 18:42:57 isrv postfix/smtp[3009]: < mailly.debian.org[82.195.75.114]:25:
250-SMTPUTF8
Dec 01 18:42:57 isrv postfix/smtp[3009]: > mailly.debian.org[82.195.75.114]:25: MAIL
FROM: SIZE=58
01.12.2024 17:26, Matthias Andree via Postfix-users wrote:
Am 01.12.24 um 14:34 schrieb Michael Tokarev via Postfix-users:
From: Михаил Токарев
Shouldn't postfix at least try to generate valid email message in
such case?
How exactly does that mail that you claim Postfix trans
01.12.2024 18:19, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
And while it's definitely true there's no encoding specified for the
GECOS field in /etc/passwd, the common practice over last couple decades
is to use utf8 in there. Also we've $LAN
08.12.2024 19:59, Viktor Dukhovni via Postfix-users wrote:
https://bugs.debian.org/882141 -- this is what we have in debian, and
the current solution:
ln -s "$SERVICEFILE" "$WANTDIR/postfix@-.service"
for DIR in $(postconf -h multi_instance_directories); do
ln -s "$SERVICEFILE" "$WANTDIR/p
09.12.2024 00:56, Wietse Venema via Postfix-users пишет:
Michael Tokarev via Postfix-users:
Just to demonstrate what's in debian about the matter, which I basically
just removed a few days ago:
https://salsa.debian.org/postfix-team/postfix-dev/-/commit/60a176aeee7dc0397037bc7980d5f3f265b
Hi!
Yesterday I mentioned a way how multiple postfix instances are managed
in Debian. And I'm trying to find out what's the right way to do this,
if at all.
As far as I can see, the only thing needed to manage a custom instance
is to have a custom config with main.cf and master.cf in there, whi
Hi!
It's been a very long story with debian installing postfix chrooted by default.
For about 25 years there were multiple, endless bug reports here on postfix-
users, in debian bug tracker, in ubuntu bug tracker and elsewhere, all kinds
of issues and workarounds has been faced. #151692 is one of
Hi!
I'm revisiting debian packaging of postfix, and noticed that a lot of stuff is
done
in quite sophisticated, twisty, or outright wrong way due to a simple issue:
many
postfix utilities require certain parameters to be set.
One example is `newaliases' run at the end of the startup procedure
08.12.2024 18:12, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
One example is `newaliases' run at the end of the startup procedure in debian,
- it
has numerous rather complex workarounds, and yet there are open bug reports
still,
for many years. The s
08.12.2024 19:10, Viktor Dukhovni via Postfix-users пишет:
On Sun, Dec 08, 2024 at 05:43:38PM +0300, Michael Tokarev via Postfix-users
wrote:
But a package might be installed from another system for example
(bootstrapping) where host name is not required to be set, or during
regular system
08.12.2024 19:10, Viktor Dukhovni via Postfix-users wrote:
DO NOT attempt to build database tables, except just-in-time, shortly
before Postfix is ready to be started. Otherwise, you cannot know the
desired value of various supporting parameters, that may depend on the
system environment:
Noticed a small error in postfix-script. The change is
in sed expression - 's/,/ /' vs 'y/,/ /'. This isn't
really important (it only suppresses extra check of
a few dirs which are normally done for default instance
only), but it's better to fix it.
Signed-off-by: Michael Tokarev
diff --git a
09.12.2024 21:52, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
Noticed a small error in postfix-script. The change is
in sed expression - 's/,/ /' vs 'y/,/ /'. This isn't
really important (it only suppresses extra check of
a few dirs wh
10.12.2024 00:22, Wietse Venema via Postfix-users wrote:
On my FreeBSSD system, Postfix has only one startup dependency,
and that is "LOGIN". If the system isn't ready for users then
it should not be running Postfix.
Would that be possible with systemd? Or is that too simple.
We're comparing ap
09.12.2024 17:17, Wietse Venema via Postfix-users wrote:
Turning on chroot is possible for most master.cf entries except
those that use proxymap, postlogd, pipe, local, spawn (I may be
missing one). You can use "postconf -F "*/*/command" to find these,
and "postconf -F xxx/yyy/chroot=y" to turn
10.12.2024 00:46, Wietse Venema via Postfix-users wrote:
The prob here is that it isn't trivial at all to set up the
chroot environment, despite all the efforts to solve this so
far. Many things can be simplified greatly by using proxy
maps for example, and that probably will be the way I'll
re
Hi!
After some experiments with postconf -F yesterday I noticed an
interesting outcome of it. I'm editing diff a bit, to omit the
unimportant details.
# cp -p master.cf master.cf.sav
# postconf -F '*/*/chroot=n'
# diff -u master.cf master.cf.sav
--- master.c
+++ master.cf.sav
@@ -12,6 +12,7 @@
28.12.2024 13:40, Tommy Berglund via Postfix-users wrote:
I am using Postfix 3.7.11 on Debian 12
How can I disable chroot in Postfix?
postconf -F '*/*/chroot=n'
Is it just changing the 5th column in master.cf from y to n or is there
more to do, before restarting postfix?
No.
/mjt
28.12.2024 18:19, Tommy Berglund via Postfix-users wrote:
Postfix works flawlessly without any errors.
Is it now safe to delete /var/spool
You most likely can remove /var/spool/postfix/etc /var/spool/postfix/lib
/var/spool/postfix/var /var/spool/postfix/usr - PROVIDED you don't have
actual co
10.12.2024 02:02, Wietse Venema via Postfix-users пишет:
Michael Tokarev via Postfix-users:
10.12.2024 00:46, Wietse Venema via Postfix-users wrote:
The prob here is that it isn't trivial at all to set up the
chroot environment, despite all the efforts to solve this so
far. Many thing
10.12.2024 02:16, Jaroslaw Rafa via Postfix-users wrote:
Dnia 10.12.2024 o godz. 01:58:58 Michael Tokarev via Postfix-users pisze:
Hm... read-only /etc? How do you reconfigure anything then?
Remount-rw, configure, remount-ro. There's no need to configure
anything during regular s
10.12.2024 01:16, Kenneth Porter via Postfix-users wrote:
I have a systemd unit on another distro that submits mail with /bin/mail (part of mailx) at boot and shutdown. What dependencies are needed to make
that work here? (This notifies me when a remote system comes up that it was gracefully shu
10.12.2024 01:31, Jaroslaw Rafa via Postfix-users wrote:
Dnia 10.12.2024 o godz. 01:21:51 Michael Tokarev via Postfix-users pisze:
It redirected a few (maybe just one) runtime-info file from
/etc to /run - this way, /etc can be read-only (I used RO
/etc for years before systemd).
Hm... read
16.12.2024 06:05, Wietse Venema via Postfix-users wrote:
Tomasz Pala via Postfix-users:
Again, what about the logging from NON-DAEMON Postfix processes
such as sendmail, postdrop, postqueue, and so on?
They belong to their calling service. Therefore if I run sendmail from
the shell, it belongs
Dunno if this is a known fact or not, but for me it was interesting news.
Calling tzset() before chroot() is not useful in glibc. Because while glibc
caches the /etc/localtime values to avoid the need to re-read it on each
use, it also *resets* the cached values back to defaults if it doesn't fi
15.12.2024 14:33, Viktor Dukhovni via Postfix-users wrote:
On Sun, Dec 15, 2024 at 11:34:54AM +0100, Tomasz Pala via Postfix-users wrote:
System-wide "defaults to 1 messages in 30s" and "is applied per-
service", so this can be easily resolved by providing postfix.service
with:
LogRateLimi
14.12.2024 17:32, Wietse Venema via Postfix-users wrote:
..
Suggesting that these programs are running continuously is not fair.
Instead, they sleep. If the file system activity bothers you then
somene could add a few stat() calls and skip directories that have
no recently modified time stamp.
15.12.2024 03:07, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
...
Today systemd plays major role in linux, and linux plays major role in the
IT world. And while some its ideas are questionable or may look weird, some
are interesting. And logging is one of them
09.12.2024 17:17, Wietse Venema via Postfix-users wrote:
...
Setting up the necessary helper files under /var/spool/postfix
(nsswitch.conf, TLS, resolv.conf, services) remains platform-specific.
I was under impression postfix does not need nsswitch.conf in the chroot.
But I was wrong.
smtp_hos
16.12.2024 17:02, Michael Tokarev via Postfix-users wrote:
16.12.2024 15:45, Wietse Venema via Postfix-users wrote:
So chroot is 'nice to have' but not for LINUX.
I've been in this boat for 25 years myself, 120% agree with that.
I want to understand the details.
To clar
16.12.2024 15:45, Wietse Venema via Postfix-users wrote:
On LINUX systems, chroot is for people who want to suffer pain.
On my FreeBSD server, Postfix chroot is painles.
Does Cyrus SASL work on your FreeBSD with less pain than on Linux?
I'd love to know the details :)
Other than nsswitch lazi
16.12.2024 17:18, Michael Tokarev wrote:
That's basically it. Where the difference in pain level between FreeBSD
and Linux come from?
Heck. I just come across examples/chroot-setup/FreeBSD2.
My Postfix setup on Linux is exactly the same. Everything is chrooted
(besides obvious local, proxy
16.12.2024 17:41, Tomasz Pala via Postfix-users wrote:
On 2024-12-16 13:22, Michael Tokarev via Postfix-users wrote:
This is exactly why I started this whole thread: is chroot in postfix worth
the efforts these days or not, from the upstream PoV? And the very first
Linux chroot() was never
16.12.2024 17:56, Tomasz Pala via Postfix-users wrote:
I mean that as /etc/localtime is frequently stat()ed for changes and
must exist in chroot, the predefined TZ don't need to, so maybe set
before chroot() won't require any files. Dunno, guessing.
It's the case, yes. But.. Just cp /etc/local
16.12.2024 14:52, Viktor Dukhovni via Postfix-users wrote:
On Mon, Dec 16, 2024 at 12:03:52PM +0300, Michael Tokarev via Postfix-users
wrote:
The good news though is that all libnss_*.so which comes with glibc
are not needed in chroot at all, they're built-in to the libc.so
proper
16.12.2024 17:28, Tomasz Pala via Postfix-users wrote:
On 2024-12-16 10:36, Michael Tokarev via Postfix-users wrote:
Calling tzset() before chroot() is not useful in glibc. Because while glibc
caches the /etc/localtime values to avoid the need to re-read it on each
use, it also *resets* the
16.12.2024 01:16, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
09.12.2024 17:17, Wietse Venema via Postfix-users wrote:
..
Does nsswitch use lazy initialization or greedy initialization?
It's as lazy as possible, as it turns out, at least in glibc.
I'm
09.12.2024 20:15, Michael Tokarev via Postfix-users wrote:
Noticed a small error in postfix-script. The change is
in sed expression - 's/,/ /' vs 'y/,/ /'. This isn't
really important (it only suppresses extra check of
a few dirs which are normally done for default
So, after the discussion about chroot, and - as it turns out - some
people objecting against turning it off, saying it is a useful feature -
and repeated mentions about systemd and "real security", I decided to
make a little experiment: to try the very first step in this direction.
One of the fir
15.12.2024 16:44, Tomasz Pala via Postfix-users wrote:
..
In case of postfix, having magnitude of options, hardened by-default
service, or at least hardening comments ("You might uncomment this if
not using that") would be PITA for sure - but every journey starts from
the first step.
I'd love t
17.12.2024 13:25, Tomasz Pala via Postfix-users wrote:
On 2024-12-17 06:41, Michael Tokarev via Postfix-users wrote:
and repeated mentions about systemd and "real security", I decided to
Well, to be honest, mantra must be repeated - "it's not about security",
like no
On 17.12.2024 18:14, Wietse Venema via Postfix-users wrote:
Did you verify the non-daemon programs, specifically that all
featrues work as promised in sendmail, postdrop, postqueue, postsuper,
postmap, postalias, and postcat? Be sure to also test as a non-root
and non-postfix user.
Did you test
18.12.2024 01:12, Wietse Venema via Postfix-users wrote:
Just for the record, Postfix requires that a system behaves as
defined in POSIX (and ANSI C). That remains the baseline for what
calls are expected to succeed, and for what calls are expected to
fail.
This is one of the possible views on
17.12.2024 13:25, Tomasz Pala via Postfix-users wrote:
Disregarding this (e.g. LMTP, virtual mailboxes only) one could try to
directly start with:
User=postfix
AmbientCapabilities=...
which would make in turn this unnecessary:
setfacl -m user:root:rwx $queue_directory/public
With current
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 s
Hi!
What's the reason for the pickup daemon to be waked up every 60s?
Either on a modern system, or at all?
Why it needs to be awaken in the first place, - does it miss mail
when the system is up and running?
It looks like this wake-up time can be increased way past max_idle
these days, say, to
09.12.2024 22:25, Wietse Venema via Postfix-users wrote:
Steffen Nurpmeso via Postfix-users:
postfix_status() {
# As postfix does not use stdout but console, no
#postfix__init
#${prog} status 2>&1
I think that was fixed in Postfix 3.8.
20230308
Cleanup: t
14.12.2024 15:52, Wietse Venema via Postfix-users пишет:
Michael Tokarev via Postfix-users:
09.12.2024 22:25, Wietse Venema via Postfix-users wrote:
Steffen Nurpmeso via Postfix-users:
postfix_status() {
# As postfix does not use stdout but console, no
#postfix__init
Having written all this, I'd love to note once again: this was just a
small experiment, which has shown it we're to work in this area, it
should be done within postfix, not outside it, and due to its well-
thought architecture, this seems to be doable (keeping the same
well-thought architecture).
Here's a little change for the `postfix' command I'd love to have
in Debian, - to assist its 25 years history of running postfix
chrooted and to have an easier alternative, one way or the other.
It's just a proof of concept, but it is easy enough. Not yet written
in a style of other code in this
20.12.2024 00:22, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
Here's a little change for the `postfix' command I'd love to have
in Debian, - to assist its 25 years history of running postfix
chrooted and to have an easier alternative, one way or t
20.12.2024 03:39, Tomasz Pala via Postfix-users wrote:
On 2024-12-20 01:33, Tomasz Pala via Postfix-users wrote:
This seems wrong:
if [ ! "$set" ]; then
It is not, it tests for emptiness of the value. Not a
difference between y and n, but between empty and non-empty.
...not mentio
20.12.2024 03:33, Tomasz Pala via Postfix-users wrote:
On 2024-12-19 22:46, Michael Tokarev via Postfix-users wrote:
I'm mostly asking about the approach, if it is okay with you if some
distribution is to modify code like this, adding a custom subcommand.
And then you're going to
21.12.2024 16:30, Tomasz Pala via Postfix-users wrote:
The real problem is I can't really confine local, as it's the same
CGroup as the rest of postfix, so the holes punched for example for
postfix-script cannot be sealed and are kept for good.
As I demonstrated before, it's rather trivial to
21.12.2024 18:31, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
It *feels* like postfix needs some separation of this sasl stuff into
its own process somehow, similar to how proxymap is done, so that
eg cyrus sasl code is not linked directly into smtp[d] with all
21.12.2024 20:15, Michael Tokarev via Postfix-users wrote:
plus a few other workarounds for lack of cap-dac-override.
It looks like it's hardly possible to get away from cap_dac_override,
because it is relied on in a number of other places. Currently postfix
happily opens non-root-owned
21.12.2024 20:55, Viktor Dukhovni via Postfix-users wrote:
On Sat, Dec 21, 2024 at 08:35:29PM +0300, Michael Tokarev via Postfix-users
wrote:
21.12.2024 20:15, Michael Tokarev via Postfix-users wrote:
plus a few other workarounds for lack of cap-dac-override.
It looks like it's h
21.12.2024 19:51, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
I still yet to see the reason for this, besides a statement "chroot is
painless for freebsd but for linux is unsupportable", which is nothing
but a big old myth, since the two works the same.
21.12.2024 16:16, Viktor Dukhovni via Postfix-users wrote:
On Sat, Dec 21, 2024 at 01:51:46PM +0300, Michael Tokarev via Postfix-users
wrote:
...
As far as I can see, Cyrus SASL can work with plaintext methods
using saslauthd (which has very simple username,password => ok|bad
protocol),
22.12.2024 11:53, Peter via Postfix-users wrote:
[people treat dovecot sasl as part of dovecot]
I realize that, but it's fairly easy to implement and easy to configure dovecot to only provide the SASL backend plus it does appear to be the most
comprehensive, easiest to implement solution for SA
22.12.2024 11:53, Peter via Postfix-users wrote:
On 22/12/24 19:53, Michael Tokarev via Postfix-users wrote:
However, there are other mechanisms being developed, for example OAUTH2,
which, in terms of Cyrus SASL, does not work with saslauthd at all,
I don't see why it wouldn't.
22.12.2024 01:10, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
21.12.2024 20:55, Viktor Dukhovni via Postfix-users wrote:
It looks like it's hardly possible to get away from cap_dac_override,
because it is relied on in a number of other places. Curr
22.12.2024 13:13, Tomasz Pala via Postfix-users wrote:
Well, Cyrus is also not SASL-only...
https://doc.dovecot.org/2.3/admin_manual/sasl/ is what I mean.
Cyrus SASL is a separate thing in people minds because it is a
separate, independent library/subsystem. You can install a separate
packag
Hi!
It seems that some my statements on this list are difficult to understand
somehow. While I usually mean one context, my statements are being interpreted
in another context.
Postfix documentation has always been an excellent example of clear brevity
to me, a high standard level which is almo
21.12.2024 22:16, Michael Tokarev via Postfix-users wrote:
21.12.2024 20:55, Viktor Dukhovni via Postfix-users wrote:
I suggest you take a break from high-volume extemporising, and come
back with narrow, carefully thought out issues or questions tackled
one at a time to a conclusion, with
22.12.2024 03:39, Peter via Postfix-users wrote:
On 22/12/24 02:54, Michael Tokarev via Postfix-users wrote:
However, there are other mechanisms being developed, for example OAUTH2,
which, in terms of Cyrus SASL, does not work with saslauthd at all,
I don't see why it wouldn't.
21.12.2024 02:37, E R via Postfix-users wrote:
Curious if there are others using the maillog_file setting who have
found that "out of the box" RHEL 8+ or 9+ will not allow Postfix to
start? I worked around the issue by creating a policy module for
testing purposes thanks to the help the SELInux
Hi!
I'm trying to get a "big picture" about how postfix works with
various SASL options. It looks like there's a big overview
missing in the docs somehow.
We've basically two big kinds of SASL mechanisms: plaintext
(which are login and plain) and non-plaintest (everything else).
The "everything
15.03.2025 19:40, Wietse Venema via Postfix-users wrote:
Michael Tokarev via Postfix-users:
I'm sure I've seen this issue before here on postfix-users.
But can't find it.
When main.cf does not have a trailing newline, ,..,,
Well don't do that, then. Use a proper text ed
В Sun, 9 Mar 2025 00:08:38 +0100
Andreas Kuhlen via Postfix-users пишет:
> Hi, so far I am using the postfix package of my distribution, which
> is probably already considered ‘legacy’. For this reason I would like
> to compile the current stable version 3.10.1. Is there any
> documentation/inst
I'm sure I've seen this issue before here on postfix-users.
But can't find it.
When main.cf does not have a trailing newline, using `postconf -e foo=bar'
to add new parameter makes bad main.cf. For example:
$ head -c-1 /etc/postfix/main.cf > main.cf
$ tail -n1 main.cf
default_destination_concur
16.03.2025 06:18, Peter via Postfix-users wrote:
This is a relatively simple patch, for the sake of simplicity it replaces the linefeed at read time, but a slightly more complicated patch that does
it when lines are output to dst might be more appropriate. Note this is untested:
FWIF, I alrea
16.03.2025 07:26, Peter via Postfix-users wrote:
You linked a debian bug, but I could not find a patch in there.
The patch was in the attachment in the same email:
https://marc.info/?l=postfix-users&m=174205748609705&w=2
/mjt
___
Postfix-users maili
77 matches
Mail list logo
