A setting to adjust the max attachment size allowed in webmail

you are welcome, always, just like everyone else

you weren’t, at all

I surely don’t want it, you’re getting me wrong

An email containing an attachment is roughly 30% bigger than the original file size due to encoding.
What do you think about automatically setting the maximum attachment size to max email size - 30 %?
Or do you think that adding a web option to set the max attachment size is easier to understand?
Side note: we could leave max mail size and add the 30% rule" to the online help.

Please, share your opinions, the code is easy and quick to write, the hard part is deciding the interface and I think that the opinion of the users counts more than anything else.


I like it. Whatever we choose, we should avoid sending messages that are bigger than the “queue max size”.

Thank you for hearing (me) us!

IMO, adding a web option to set the max attachment size is easier to understand and more useful.
I usually set the attachment size to 25 MB. But there are situation when you need more size (I have a web app that sending emails with attached files which can reach 75 MB/email).

I think it depends on the system administrator. The sysadmin must know what is better for his system. Let’s give him a chance! ( Firewall UI for policy rules )

We can correlate the two settings, even by a warning.

Interesting point I think, would you mind to continue the discussion here?

Again, @GG_jr can ask whatever he wants, ready to convince the community to support his proposal, discussing and defending such improvement.

People MUST compare NethServer to other distributions because we need to improve the product learning from others. If others have already a feature we should ask ourselves why and discuss if it’s worth to develop it or not.

Asking, proposing and discussing is enough for me.
Check also:
Provide your voice in NethServer development and roadmap

Please, stop these kind of sentences once and for all :wink: they don’t fit our culture and don’t help people, they scares them indeed. Thank you, hope you understand

well, looks like both of you just misunderstood me or I wasn’t able to explain me…

asking for feature is not a bad idea, even if NFR should be in some way catalogued, just to see WHAT people ask and discuss the opportunity to develop them or not… is there such a catalogue? where it is?

The real fact here is that there are way too many “hei guys, add this, that, $whatever” e really few "oh, guys, how can I add this feature? I’m really interested, I need it"
moreover, such a requests are seldom just “do it”…

when you talk about “our culture”, who are you referring to? the community?

anyway, I NEVER told anyone (if I did it I apologized and I’m ready to do it right now again) here or elsewhere to STOP talking/writing.

How many is “too many”?
Seriously, I’m a man of science, where do you set “your bar”? And why?

From the screenshot you provided I see both Zentyal and Endian have only one parameter. I think one is enough; the other can be calculated.

1 Like

Of course, you didn’t do it directly but people stop doing it anyway because they don’t feel comfortable to continue the discussion after your post.


Please correct me if I’m wrong: The total size of an email is given by the “size of the body” plus the “size of the attachment”. Of course i saw many times pictures in the body of the emails (not as attachment), but the size of the body, usually is smaller than the size of the attachment.

So, I think the size of the attachment is more important, and IMO, this parameter should be adjustable.
I also used Axigen as email server. And there, this parameter is adjustable.

I’m sure, together, we will find the proper solution!

No other solutions, that fun you are no more in the user-case of an email server, but clearly here in a file server.

The size of the attachment multiplied for 1.33.
We can have a single value and do the math.


I reviewed the Endian documentation about the email size.
They refer only at “maximum email content size” (I think the whole email: body and attachment):

"Choose maximal email contentsize:
The maximum size allowed for a single e-mail message. Several predefined values can be selected from the drop-down menu*. Choosing the custom email contentsize option reveals the next option.

Custom maximum email contentsize (in KB):
The maximum size in mega bytes of the e-mail that will be accepted by the SMTP server."

*Drop-down menu: custom maximum email content size; 5 MB; 10 MB; 15 MB; 20 MB; 25MB; 30 MB; 35 MB; 40 MB; unlimited email contentsize.

So the same NethServer property, right?

Yes, if we put “=” between “The Queue message max size” and “Maximum email contentsize”.

Also by definitions:

NethServer: The Queue message max size slider sets the maximum size of messages traversing the system

Endian: The maximum size in mega bytes of the e-mail that will be accepted by the SMTP server

In NS it’s about mesages and in Endian it’s about a single e-mail message. And the Queue is a “place” for all messages.

I’m not sure if it’s about the same thing.

AFAIK they are the same thing,

our Postfix template sets the following parameter


We can easily convert that value to a max upload size for Roundcube configuration. IIRC sogo has a similar setting. If the weight of all attachments exceedes the limit a SMTP error is returned to the application.

(default: 10240000)

The maximal size in bytes of a message, including envelope information.

Note: be careful when making changes. Excessively small values
will result in the loss of non-delivery notifications, when a bounce
message size exceeds the local or remote MTA’s message size limit.

(default: see “postconf -d” output)

The location of the Postfix top-level queue directory. This is the
root directory of Postfix daemon processes that run chrooted.

(default: 100)

The maximal number of (name=value) attributes that may be stored
in a Postfix queue file. The limit is enforced by the cleanup(8)

This feature is available in Postfix 2.0 and later.

(default: 0)

The minimal amount of free space in bytes in the queue file system
that is needed to receive mail. This is currently used by the
Postfix SMTP server to decide if it will accept any mail at all.

By default, the Postfix SMTP server rejects MAIL FROM commands when
the amount of free space is less than 1.5*$message_size_limit
(Postfix version 2.1 and later).
To specify a higher minimum free space limit, specify a queue_minfree
value that is at least 1.5*$message_size_limit.

With Postfix versions 2.0 and earlier, a queue_minfree value of
zero means there is no minimum required amount of free space.

(default: 300s)

The time between deferred queue scans by the queue manager;
prior to Postfix 2.4 the default value was 1000s.

This parameter should be set less than or equal to
$minimal_backoff_time. See also $maximal_backoff_time.

Time units: s (seconds), m (minutes), h (hours), d (days), w (weeks).
The default time unit is s (seconds).

(default: qmgr)

The name of the qmgr(8) service. This service manages the Postfix
queue and schedules delivery requests.

This feature is available in Postfix 2.0 and later.

From all of above, I understand that if an email have 20 MB (message size), it can be delivered by the Postfix SMTP only if the Queue (directory) have more than 1.5*20=30 MB. Am I wrong?

You are right.
The cursor from GUI set the message size limit, not the Queue message max size.
So, you can set the maximum size limit of a mail message from GUI.
It’s a labeling error which generate misunderstanding. Can you fix this?

I think that the cursor for “Queue message lifetime” should be in “Queue management” section.