[GF-Users] postfix-tlspol v1.9.1 available upstream (1.10.0)

Tue Apr 28 16:13:09 MST 2026

Peter. 

Thanks for taking the time to go through this. I reported a problem upstream last week and v1.10.0 was subsequently released today that also included other fixes. I have a v1.10.0 candidate ready for GF release at the link below:

https://www.integrilog.com/adhj5jkuuk2sfsf0/postfix-tlspol/Custom%201.10.0/0/
(I have this running on production EL 9 & 10 systems.)

URGENT: However, I am embarrassed to report that before this build the spec %build settings were off and ironically the binary inside rpm package has never actually functioned correctly. I am so sorry.
The way I was testing before did not identify the problem. We need to either update all the packages on the website or remove the one's we don't. Tell me how I can help.

FYI, the author clarified my understanding of the intended usage of the socket: " Just as a note: The socket isn't really intended to be an activation trigger, but rather to serve Postfix an always available socket even during restarts of postfix-tlspol (which is, to be honest, a seldom act anyway). Shutting down the daemon between requests would be too costly on system resources, annoyingly slow at least, and also make prefetching useless (prefetching enhances security by buffering short-term failures)."

Based on this new information and our discussions so far, I think the fixes below address all your/concerns preferences.

Mike

FIXES  / CHANGES ******************************************************************************************************

1. Unit files: Not preserve unit files. Agreed. (sorry I did remember we did this before but forgot fedora guidelines reason)

2. Added a custom GUIDE.gf file to help new users

3. New Systemd Socket: Now treating it as "optional". 
User must manually enable/start service, manually enable/start socket if desired. Preserve state on updates. Do not automatically enable/start.
The new custom GUIDE.cf explains service vs socket.

4. DNS IP Address: Leave #127.0.0.53:53 as is. Agreed.  This was commented out upstream several revisions ago but I did not notice the change till now. Anyhow, I should not have assumed 127.0.0.1:53 was a better default.

5. Bugfix: Must include gcc during the golang build so that package resolves postfix lookups correctly.

END FIXES  / CHANGES ******************************************************************************************************

-----Original Message-----
From: users-bounces at lists.ghettoforge.net <users-bounces at lists.ghettoforge.net> On Behalf Of Peter
Sent: Friday, April 24, 2026 10:37 PM
To: users at lists.ghettoforge.net
Subject: Re: [GF-Users] postfix-tlspol v1.9.1 available upstream

Sorry, I haven't had a lot of time for checking email lately...

On 21/04/2026 21:51, Michael Webb wrote:
> Thank you for the feedback and suggestions. Since yesterday, I have tested thoroughly and am comfortable that we can move forward with Option 1. However, a user who blindly updates will get a surprise when find that the service is now only running on demand.

The ability to blindly update is important, imo so the question becomes how much this "surprise" is going to cause problems for people.  Will it break anything or continue to "just work"?  Are there any customizations that you can think of that someone might have done that will break because of this?

> It is unfortunate to discover this way, but I think it is acceptable progress. Thankfully the package has only one task, is simple to test, and is unlikely to break because customization on an EL system is unnecessary.
> 
> Since this package update has big changes, and the previous revision is working well, if you like what I have done below, suggest we wait a few more days to see if there are any bug fixes published to save effort.

Agreed.

> I realized when I was going through this again that our earlier development was just to get something working and rpm building was new to me. I missed some opportunities to make the rpm and spec more user friendly which I have now also addressed below.
> 
> My thoughts/response on the individual changes:
> -----------------------------------------------------
> - Socket: After further reading, I think the change to system socket activation is a good change. In a Postfix MTA that is processing hundreds / thousands of emails a minute, resource optimizations are always welcome. Postfix-tlspol is only used for outgoing mail, so it makes sense to use a socket to "activate" the service only when required.

I would think that would depend on how much outgoing mail one has, but someone with such large volumes can customize it to keep the service running full time.

> - Resolved/Bind: FYI - The upstream source assumes that the native DNS package in the reference install is systemd-resolved (which uses a DNS stub approach and listens on 127.0.0.53:53). From the outset I assumed that EL users would prefer BIND for a Postfix MTA and coded the spec to modify the contents of config.yaml to 127.0.0.1:53 for the install default, but this can be customized by the user after the first install and is preserved thereafter with %config(noreplace).

True, but my point before was that the setting is commented out anyways, and will remain commented out after your change, so your change actually does nothing.  If one wants to uncomment it then they can and probably will change it to whatever address they want at the time and what's there is going to only serve as an example for them.

> - Query.sh: We won't miss this. Not an essential file because " 
> /usr/bin/postfix-tlspol --help" already shows how to construct a test 
> query

Okay.

> - Test.sh: Although today I successfully ran this script for the first 
> time, I still don't really understand the value - possibly the 
> author's way of demonstrating the package code integrity. However, I 
> think it needs to be removed from the install because it can only be 
> run from a git cloned source folder and has no value in our context. I 
> shared the script output in test_sh_output_example.txt at the link 
> below FYI

If it's only useful as you say from a git-cloned repo then I agree that there's no reason to continue to include it in the package, let's remove it.

> - Metrics (Grafana): I missed this feature addition: seems also worth copying the /assets/ json and readme for users that might want to install Grafana in the future, and I have added these to the spec, but can't think of a better place to put them /etc/postfix-tlspol/metrics/?

/etc is for settings files, if they are directly related to settings files in that directory then thyt's okay but otherwise they should probably be in /use/share/doc/postfix-tlspol/

> - The good news is that with no scripts, we also no longer need /usr/local/bin/postfix-tlspol folder if it is empty.

Wait, we had stuff under /usr/local/?  Yeah let's get rid of that, there should never be any packaged files under /usr/local/, imo.

> - Upstream CHANGELOG.md copied with the install

That's fine.

> **** This one might be contentious ****
> - The package works out of the box with the default config, so I hope it is acceptable to enable and start the socket automatically on new installs. It is not otherwise mentioned anywhere to run the following command. After this, all that's left is to manually configure postfix to call the socket.
> systemctl enable --now postfix-tlspol.socket
> 
> - socket is only automatically enabled and started on an upgrade if the service it replaces was already running.

This sounds like what needs to be done for minimal disruption to the change that we're proposing, if we make the change then I'm fine with this.

> - spec file now preserves custom changes to system unit files

I believe we discussed this before, but by convention (and possibly Fedora packaging guidelines) unit files should not be preserved.  If one wishes to make changes to unit files that will be preserved across updates then the proper way to do it is with a `systemctl edit ...` command.

Peter

> I have modified the spec to accommodate the philosophy above tested installs in different scenarios (upgrade and enabled, upgrade and disabled, new install, upgrade with modified unit files), and have the updated build running on an EL10 production server.
> 
> https://www.integrilog.com/adhj5jkuuk2sfsf0/postfix-tlspol/Custom%201.
> 9.1/0/EL10/x86_64/
> 
> Mike
> 
> 
> 
> 
> 
> -----Original Message-----
> From: users-bounces at lists.ghettoforge.net 
> <users-bounces at lists.ghettoforge.net> On Behalf Of Peter
> Sent: Monday, April 20, 2026 3:18 PM
> To: users at lists.ghettoforge.net
> Subject: Re: [GF-Users] postfix-tlspol v1.9.1 available upstream
> 
> Yeah, I'm not liking these changes.  They are fundamental changes with little or no explanation as to why they are made in the git logs or change logs.  I was able to find this for the socket file change:
> 
> https://github.com/Zuplu/postfix-tlspol/issues/111
> 
> I read this as being that they made the change in order to have more restrictive permissions on the socket file itself, but the problem is it seems to lead down a rabbit hole of issues that they are now resolving such as this one:
> 
> https://github.com/Zuplu/postfix-tlspol/issues/140
> 
> I'm uncomfortable with it because this fundamental change seems to affect enterprise stability and requires changes that may very well cause other seemingly non-related issues.  That said, that would mean that we are stuck with the following options:
> 
> 1.  Go ahead and implement the change (as you're doing) anyways.
> 
> 2.  Stick with an older version of the package and start backporting bug fixes (this requires a lot more maintenance) and only use the newer version in EL11 when it eventually drops.
> 
> 3.  Include patches that reverse the changes for EL<=10 but which may cause issues with further changes in the future.
> 
> I don't like any of these options but the one I dislike the most is #2 due to the increased complexity of maintaining the package.  I'd like your input on whether you think 1 or 3 is better.
> 
> I'm curious as to why they removed query.sh, I can't find the explanation anywhere.
> 
> The change you made for OOMPolicy makes sense.
> 
> I also noticed you changed the address for the resolver to 127.0.0.1.  I find it puzzling that they used 127.0.0.53 but it shouldn't matter because 127 is a /8 and any IP address that starts with 127 is loopback.
>    Also since the line is commented out anyways I won't worry about that change because for someone to use it they will have to uncomment the line in which case they can change it to anything they want at the time.
> 
> 
> Peter
> 
> 
> On 20/04/2026 22:12, Michael Webb wrote:
>> Hi Peter
>>
>> v1.9.1 has been released. It has three differences from previous 
>> versions that require changes inside the spec file. The upgrade has 
>> both new features and fixes, but I think we should wait a few weeks 
>> to evaluate stability. At this stage, I am more interested in your 
>> feedback about the changes I made to the spec file and whether this 
>> is a good change for end-users. I have the package running on an EL10 
>> production system.
>>
>> https://github.com/Zuplu/postfix-tlspol/releases <https://github.com/ 
>> Zuplu/postfix-tlspol/releases>
>>
>> The main changes to the package install that need to be addressed in 
>> the spec file are:
>>
>> * New systemd socket unit file
>>
>> * query.sh file was removed from package
>>
>> * New OOMPolicy=continue added to the service unit file, but it will 
>> only work EL >= 9
>>
>> https://www.integrilog.com/adhj5jkuuk2sfsf0/postfix-tlspol/
>> Custom%201.9.1/0/EL10/x86_64/ <https://www.integrilog.com/ 
>> adhj5jkuuk2sfsf0/postfix-tlspol/Custom%201.9.1/0/EL10/x86_64/>
>>
>> Thanks
>>
>> Mike
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.ghettoforge.net
>> http://lists.ghettoforge.net/mailman/listinfo/users
> 
> _______________________________________________
> users mailing list
> users at lists.ghettoforge.net
> http://lists.ghettoforge.net/mailman/listinfo/users
> _______________________________________________
> users mailing list
> users at lists.ghettoforge.net
> http://lists.ghettoforge.net/mailman/listinfo/users

_______________________________________________
users mailing list
users at lists.ghettoforge.net
http://lists.ghettoforge.net/mailman/listinfo/users