Hi Marcus, Greg and Branden,
this is very interesting. In my mail user agent (Thunderbird), when
trying to load and read Branden's mail with the two compilations of
groff manpages (one single-digit MB, the other one double-digit MB in
size), this very mail does not show that it comes with attachments. The
attachments are only visibly indicated once I click on the subject line,
and then the system falls into a half-freeze state, obviously because it
is fetching the attachments.
Since I frequently work with large attachments in the 10 MB range, which
usually load *much quicker*, there is perhaps a bottleneck on the
sending side of things? Which, in turns, slows down the user experience
significantly.
Even stranger, if I select a different mail for reading and then want to
go back to Branden's mail, the system slows down again to a semi-halt,
even affecting the user input while writing this mail. This is also
something I never experience with other big attachments. Once
Thunderbird fetches the attachment, it stays --- not in this case,
though. Is there a different type of handshake between MUA and list, in
comparison to ordinary mail systems?
No idea whether my observations are worth a cent.
Thank you for your wonderful work, and please accept my apologies for my
prolonged silence on the list.
Best,
Oliver.
On 27/07/2026 23:08, G. Branden Robinson wrote:
(This email is about 5.7 KB.)
Hi Marcus & Greg,
At 2026-07-27T08:54:43+0200, Marcus Rohrmoser wrote:
recently I received several emails weighting way over what to expect
from plaintext emails. I have a slow uplink.
At 2026-07-27T17:07:38+1000, Greg 'groggy' Lehey wrote:
I was wondering this too. It doesn't directly affect me, but it did
seem excessive.
Sorry about that. Depending on what your pain threshold for email/
attachment sizes is, that was either completely or mostly my fault.
I sent some attachments to the list yesterday that weighed in at 1.6 MB,
11 MB, and 3.7 MB respectively.
And Deri sent one of 76 KB, a PDF of a squirrel on a log. ;-)
Perhaps it didn't help that _last_ month was our lowest-traffic month in
years. The first part of this month was almost dead quiet as well. So
recency bias may play a role here, but I wouldn't dare claim that it's
the whole story.
[Marcus again:]
Is this normal here and will happen again or was this exceptional?
...neither?
It's not normal, nor is it unprecedented or extremely rare. Here are
the sizes of cumulative monthly mbox files corresponding to this list,
going back to January 2024.
$ (cd ~/Mail && ls -hl groff.202[456]*)
-rw-r--r-- 1 branden branden 5.7M Jan 31 2024 groff.2024-01.mbox
-rw-r--r-- 1 branden branden 1.9M Feb 28 2024 groff.2024-02.mbox
-rw-r--r-- 1 branden branden 4.6M Mar 31 2024 groff.2024-03.mbox
-rw-r--r-- 1 branden branden 2.3M Apr 30 2024 groff.2024-04.mbox
-rw-r--r-- 1 branden branden 9.3M May 29 2024 groff.2024-05.mbox
-rw-r--r-- 1 branden branden 2.8M Jun 28 2024 groff.2024-06.mbox
-rw-r--r-- 1 branden branden 2.0M Jul 31 2024 groff.2024-07.mbox
-rw-r--r-- 1 branden branden 5.7M Aug 31 2024 groff.2024-08.mbox
-rw-r--r-- 1 branden branden 3.3M Sep 30 2024 groff.2024-09.mbox
-rw-r--r-- 1 branden branden 32M Oct 29 2024 groff.2024-10.mbox
-rw-r--r-- 1 branden branden 3.4M Nov 30 2024 groff.2024-11.mbox
-rw-r--r-- 1 branden branden 3.0M Dec 31 2024 groff.2024-12.mbox
-rw-r--r-- 1 branden branden 13M Jan 29 2025 groff.2025-01.mbox
-rw-r--r-- 1 branden branden 1.5M Feb 26 2025 groff.2025-02.mbox
-rw-r--r-- 1 branden branden 1.7M Mar 31 2025 groff.2025-03.mbox
-rw-r--r-- 1 branden branden 216K Apr 29 2025 groff.2025-04.mbox
-rw-r--r-- 1 branden branden 914K May 30 2025 groff.2025-05.mbox
-rw-r--r-- 1 branden branden 3.8M Jun 30 2025 groff.2025-06.mbox
-rw-r--r-- 1 branden branden 250K Jul 31 2025 groff.2025-07.mbox
-rw-r--r-- 1 branden branden 712K Aug 31 2025 groff.2025-08.mbox
-rw-r--r-- 1 branden branden 1.5M Sep 30 2025 groff.2025-09.mbox
-rw-r--r-- 1 branden branden 2.5M Oct 31 2025 groff.2025-10.mbox
-rw-r--r-- 1 branden branden 775K Dec 29 2025 groff.2025-12.mbox
-rw-r--r-- 1 branden branden 1.8M Jan 31 15:06 groff.2026-01.mbox
-rw-r--r-- 1 branden branden 3.7M Feb 28 18:42 groff.2026-02.mbox
-rw-r--r-- 1 branden branden 1.6M Mar 30 18:49 groff.2026-03.mbox
-rw-r--r-- 1 branden branden 843K Apr 30 19:28 groff.2026-04.mbox
-rw-r--r-- 1 branden branden 362K May 29 12:14 groff.2026-05.mbox
-rw-r--r-- 1 branden branden 165K Jun 26 14:54 groff.2026-06.mbox
(Anyone can obtain these files from the GNU site.
<https://lists.gnu.org/archive/mbox/groff/>)
We see a wide variance in these data. Let's get quantitative.
$ (cd ~/Mail && ls -l groff.202[456]*) \
| awk '{print $5}' | datamash range 1 median 1 mean 1 sstdev 1
33242119 2015232 3974174.3793103 6358996.8424221
To 2 significant figures, that's a range of 32 MB, a median of 2.0 MB, a
mean of 4.0 MB, and a sample standard deviation of 6.4 MB.
The foregoing implies that the groff list's monthly traffic level is
right-skewed and not well modeled by a normal (Gaussian) distribution.
That in turn makes it harder to reason about what to expect, as human
experience and habits of thought are strongly adapted to situations
where the Central Limit Theorem holds. We are likely to be startled by
outliers that should not surprise us from a statistical standpoint.
Humans struggle to deal with phenomena where the median is lower than
the mean. We encounter it as a great scotoma of political economy,
accounting for why societies around the world are excessively tolerant
of L-shaped wealth and income distributions. Working-class people
accept far higher tax burdens than they should, and let themselves get
rolled by rhetoric implying that billionaires already pay far too much.
But let's get practical, and deal with a matter we can affect today.
I'd prefer to use the tools we have to apply "etiquette" coequally to
all mailing list participants, including myself.
I checked the Mailman admin interface for the groff list and there is
_no_ inherent limit on message size at present. But we can set one.
The info-groff list, for example, has a limit of 40 KB. That seems a
bit low to me for a discussion list.
We manage typesetting software and have to deal with PDFs. A certain
amount of bandwidth is necessary for us to conduct business. That fact
doesn't imply that we should impose no limit at all, however.
I invite you and all other list participants to suggest figures for a
limit. Let's see if we can reach a consensus on one. If so, I'm happy
to configure that value into the Mailman setup for this list.
I deliberately do not propose a number to start with, as I bear primary
responsibility for both the problem _and_ for implementing any remedy.
Tell me what you'd like to see!
Regards,
Branden
--
Dr. Oliver Corff
mailto:[email protected]
