Hello, I have an idea or request if the GUI for the Postfix settings are edited in between times.
Unfortunately, the settings for the maximum message size can only be set very roughly in the GUI. The next step after 20 MB is 50 MB. That doesn’t seem fine enough to me.
(we had found that we had to set a message size of 28 MB for a message size of 20 MB - also at the Proxmox mail gateway)
I know that you can define a different size in the database, but I’m not sure whether this will be reliably retained even after updates etc. The differently defined size is then no longer displayed in the GUI.
EDIT: Im sorry, this was wrong, I looked at the wrong GUI (wrong machine). The maximum message size is displayed in the GUI as in the Config DB, but in a wrong position
Wouldn’t it be possible to get a separate input field in the GUI to enter the desired size as a number? Or a finer adjustment in the slider.
@stephdl
Is mail your module? What do you think about it. Is it a big problem to change the slider.
@yummiweb
A solution for you could be a custom template. I didn’t try, but I think it should work like the following:
copy /etc/e-smith/templates/etc/postfix/main.cf/30message_size
to /etc/e-smith/templates-custom/etc/postfix/main.cf/30message_size
and edit it. I think it had to look so:
This also works so far. Could there be any night parts with that?
Otherwise I would prefer the DB variant:
++ A own template is possibly more stable in terms of expands.
–– (the template does not change with Postfix syntax or function changes)
–– The template and the value stored there could be forgotten.
–– The Template value can “only” be found in the “/etc/postfix/main.config” (and the template, of course)
–– The value set in the Config DB is still displayed in the GUI. This means that the config shows a different value than is actually used.
++ The value set in the Config DB is* displayed (but not correctly positioned) in the GUI
(* in my first post i was wrong, I looked on the wrong GUI (wrong machine))
++ The entry in the Config DB is displayed when “config show postfix” is called
–– The Slider in the GUI must then no longer be changed
Therefore I also advocate an (optional) numerical setting option.
Which method is recommended in view of the further development (Nethserver 8)? There is talk of a departure from the “e-smith” system.
If I remember it correctly, your solution works with the old Nethgui admin UI. That means the UI page preserves the custom value among other slider values when the settings are saved.
Could you verify it behaves the same with Cockpit?
Thank you for the PR: it is a little improvement, however even if we add more value points to the slider the original request (28MB) is not satisfied.
We have now a rough non-linear sequence: 10,20,50,100,200,500,1000. I agree we could improve it by some means …but how?
Proposal.
check that Yummiweb’s custom value is preserved after the UI page is saved (see above). This is a hard requirement IMO, because we can’t do enough assumptions on which value is correct. Also the template approach suggested by Michael is acceptable in extreme cases.
see if it is possible to replace our rough and arbitrary data sequence with a range 10-500 (steps of 1). The VueSlider component could support that and it seems there’s plenty of screen space for the slider.
In my case, with the somewhat crooked value 27.5, I get the following error message:
Validation failed: Must be a positive integer
EDIT: in Cockpit
With a value that does not have to be broken with a point in the GUI (e.g. 28000000 which is displayed as 28 in the GUI), the own value is retained even after “saving”.
EDIT: in Cockpit
My suggestion would be an optional field for your own numerical value in addition to the previous or changed slider.vPerhaps with a brief note that e.g. “28000000” corresponds to a value of “28 MB” ".
Or is there a claim that the value entered here should be “human readable”?
(In this case, you should perhaps point out that the values set or displayed here will not automatically accept e-mails of this size)
Personal opinion: changing the “Maximum message size” is rarely needed. Those who need something different from the default value 20000000 want a “special” custom value that is often not among those provided by the slider UI control.
I can accept a numerical field (e.g. touchspin UI widget) in place of the spinner, as alternative to point 2 of my proposal:
From this** perspective, I understand that the effort would probably be greater than the benefit for the community. For individual cases there is a solution that I can work with.
However, a partial aspect of my original request has not yet been answered: “Is it safe to use this own setting in the config DB or could it be lost in the event of later changes, updates or the like or even lead to problems with future Nethserver upgrades (NS 8) ?”
** I have different experiences here. Most mail servers we communicate with allow sizes around 20MB. The expectation is therefore that we can also receive corresponding quantities. This is not ensured (in our case ***) by the setting "20MB. In our case e-mails with more than 16 MB were rejected, although 20 MB should be allowed according to the bounce message.
A research showed that there is still a lot of “overhead” to be added here. In our case, only the odd value of “27.5 MB” allows the receipt of e-mails with an actual 20 MB. I have found experimentally that about 35-40% must be added to the desired target size for it to work. The next larger value “50 MB” makes no sense for us, since internal and external mail communication should not have different limits. This would confuse users and will lead to bounces for mixed recipients (internal and external).
*** It is possible that this only affects environments in which (like us) a Proxmox mail gateway is operated. For years we had always relied on the displayed values (and error messages). Only after a specific (and very annoying) case a few days ago did we take a closer look at the matter and came across the discrepancy between the set and actually achievable sizes.
It would be interesting to find out whether there are similar experiences in these or similar constellations. If that is the case - and there is a requirement that you can roughly rely on the set values - I would alternatively suggest a second slider with which a value for the overhead can be set.
As it was verified with your previous test, if the prop is set to a custom value it is always preserved, as long as it can be rounded. If not, the value is preserved as-is until the UI page is saved. For sure a custom value will not be altered by upgrade/migration scripts, unless stated otherwise in the release notes.
As said, the template-custom of /etc/e-smith/templates/etc/postfix/main.cf/30message_size ensures that the desired value is applied even after a UI “save” operation occurs.
It could be caused by the base64 overhead. The underlying Postfix parameter is message_size_limit. It is the byte size of the raw message (SMTP envelope, headers, and encoding overheads included).
Yes I’m curious too! Let’s hear other experiences!
I would like to test this out if I knew how. I assume that I would have to make certain settings / changes to the package sources? But how complicated is it to undo that without leaving any residue?
