Good morning,
I have a stable low-volume Postfix setup on a 10-year-history IP address. In
mid-2025 we need to relocate interstate. The mail MX is going to be offline for
a few days for the relocation and have possible further outage time through new
location setup. The new location will als
On 2024-12-17 Tobi via Postfix-users wrote:
> I'm looking for a way to achieve the following: if postfix smtp client
> cannot establish a TLS connection to MX host then we want to change
> nexthop **and** add a suffix to the subject. The goal is to route back
> the mail to the handing-over server (
Hi there
I guess the answer will be "not possible" but maybe (hopefully) I'm
wrong :-) I'm looking for a way to achieve the following: if postfix
smtp client cannot establish a TLS connection to MX host then we want
to change nexthop **and** add a suffix to the subject. The goal is to
route back t
Good morning,
Am 17.12.2024 um 06:41 schrieb Michael Tokarev via Postfix-users:
...
capabilities of the service which aren't needed. Obviously, postfix
does not need an ability to reboot a system (does it not? How about
sending a special email which will trigger a reboot?) or to do many
My s
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
Hi Postfix list,
I have a stable low-volume Postfix setup on a 10-year-history IP address. In
mid-2025 we need to relocate interstate. The mail MX is going to be offline for
a few days for the relocation and have possible further outage time through new
location setup. The new location will als
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
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 instance
only), but it's bett
I saw that when messages sent to duck.com for forwarding, duck.com will
remove the original DKIM info from headers, to protect the sender privacy.
I am just curious how to remove that DKIM in postfix?
That is something that can be done in milters. Most likely a custom solution
they built.
I d
Hello
I saw that when messages sent to duck.com for forwarding, duck.com will
remove the original DKIM info from headers, to protect the sender
privacy.
I am just curious how to remove that DKIM in postfix?
Thank you.
___
Postfix-users mailing list
On Mon, Dec 16, 2024 at 16:32:27 +0100, Matus UHLAR - fantomas via
Postfix-users wrote:
> RH does not usually upgrade major versions of libraries, what's happened?
RHEL 9.4 actually rebased OpenSSL 3.0.7 => 3.2.2.
(which is not unusual in dot releases)
But Postfix was rebuilt as well, at least
What about openssl, which is current version in RHEL9?
It's Oracle's repo for RHEL9.
Name : openssl
Epoch: 1
Version : 3.2.2
Release : 6.0.1.el9_5
Architecture : x86_64
Size : 1.5 M
Source : openssl-3.2.2-6.0.1.el9_5.src.rpm
Repository :
On Mon, Dec 16, 2024 at 07:32:15AM -0500, postfix--- via Postfix-users wrote:
> This is what the packages were built with. Is this right/wrong? Do I have
> options that don't involve building from source? Do I need to wait until the
> package maintainers build against a newer SSL?
The warnings ar
On 2024-12-16 15:59, Michael Tokarev via Postfix-users wrote:
>
>> All of the chroot features, fine grained, and even more are now much
>> easier to set up with namespaces, syscomp filters, BPFs, CGroups,
>> capabilities etc. This is not SELinux madness with unauditable rules...
> All this stuff h
But you did not also upgrade Postfix, which was built with OpenSSL 3.0.0.
Installed Packages
Name : postfix
Epoch: 2
Version : 3.5.25
Release : 1.el9
Architecture : x86_64
Size : 4.4 M
Source : postfix-3.5.25-1.el9.src.rpm
Repository : @System
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 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 _
On 2024-12-16 15:38, Michael Tokarev via Postfix-users wrote:
>
> With this, no /etc/localtime is considered. Or TZ can point to a file, like
> TZ=:Pacific/Auckland - in which case the value is read from
> /usr/share/zoneinfo/Pacific/Auckland file, which is checked in chroot too.
I mean that as
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 _worth_ any trouble.
It should have been used when it
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 ca
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 cached values back to defaults if it doesn't find
>
On 2024-12-16 10:18, Michael Tokarev via Postfix-users wrote:
>
> service or to the service which did the submission. Neither of the two
> is right or wrong in all cases, though I'd say the initial submission
> belongs more to the submitting service than to the accepting service, -
> at least tha
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: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 clarify. I've been thin
Michael Tokarev:
> 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?
My servers use none of tha
esd via Postfix-users:
> I found a problem during testing. Version postfix 3.9.0.
> When using dovecot sasl for verification, if dovecot dies or the
> network connecting to dovecot fails, smtpd will not be able to
> return 220. Mail cannot be received.
You enabled SASL AUTH on the PORT 25 servic
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
On 2024-12-16 04:05, Wietse Venema via Postfix-users wrote:
>>
>> # journalctl -o json-pretty --since -2m
>
> This assues that one already knows when some event of interest
> happened.
I'm not sure what do you mean - I gave you examples for querying
journal, you don't have to use any of these sel
Michael Tokarev via Postfix-users:
> 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
But you did not also upgrade Postfix, which was built with OpenSSL 3.0.0.
Installed Packages
Name : postfix
Epoch: 2
Version : 3.5.25
Release : 1.el9
Architecture : x86_64
Size : 4.4 M
Source : postfix-3.5.25-1.el9.src.rpm
Repository :
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, and separat
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, and separate .so files are provided for compatibility only.
But su
I found a problem during testing. Version postfix 3.9.0. When using
dovecot sasl for verification, if dovecot dies or the network connecting to
dovecot fails, smtpd will not be able to return 220. Mail cannot be received. I
used net socket to connect to dovecot. Is it possible to judge the con
On Mon, Dec 16, 2024 at 04:06:10AM -0500, postfix--- via Postfix-users wrote:
> Just to double check this isn't a configuration library issue on my end?
> Someone is messing around? I have dozens of these repeated in the logs.
You've recently installed an updated OpenSSL package on your system.
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
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
Just to double check this isn't a configuration library issue on my end?
Someone is messing around? I have dozens of these repeated in the logs.
Dec 15 23:07:50 host postfix/smtpd[3181]: warning: run-time library vs.
compile-time header version mismatch: OpenSSL 3.2.0 may not be compatible
w
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 trying to
38 matches
Mail list logo
