Numeric input field for maximum message size or a finer adjustment in the slider

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.

Thanks very much!

1 Like

Is mail your module? What do you think about it. Is it a big problem to change the slider.

A solution for you could be a custom template. I didn’t try, but I think it should work like the following:
and edit it. I think it had to look so:

# 30message_size -- Max message size
# message_size_limit = { $postfix{MessageSizeMax}  }
message_size_limit = 28000000
# mailbox_size_limit = 0

Save it and expand the template
expand-template /etc/postfix/


I am not sure about which UI you are talking, can you add a screenshot (english version please)

Here you are

Ok just UI stuff I can look on it


Thanks for the suggestion and the instructions with the template.In principle, this also works and will therefore outlast template expands.

In the meantime I had entered the desired “message_size_limit” value in the Config DB:

config setprop postfix MessageSizeMax 27500000
signal-event nethserver-mail-server-save

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.


At the moment developers build a version with containers on debian. I think e-smith is not possible on this solution.


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?


  1. 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.

  2. 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.

1 Like

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

Regards yummiweb

1 Like

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)

Regards yummiweb

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:

I verified my impressions on the field, by checking the value of MessageSizeMax prop of mail servers (Nethesis customers).

That’s not completely true. A non-default value is picked among what the slider provides by 17.5% of mail servers.

That’s false. The “special-custom-value” is used by <0.1% of mail servers.

So adding more points to the slider is surely a nice improvement, but I can say it is not useful as we already have a manual procedure for edge cases.

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.

Regards yummiweb


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/ 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!

1 Like

this is smart :smiley:

PS: I dislike custom-template :stuck_out_tongue:

We have a range from 10 to 1000 with a step of 2MB (better for the mouse)


who want to test please


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?

Regards yummiweb

the best would be to use a VM, else yum update nethserver-mail\* --enablerepo=nethserver-testing

to go back to stable package

yum downgrade nethserver-mail\*

1 Like