Re: Netiquette / Email weight

Hi Marcus, Greg and Branden,

this is very interesting. In my mail user agent (Thunderbird), when=20
trying to load and read Branden's mail with the two compilations of=20
groff manpages (one single-digit MB, the other one double-digit MB in=20
size), this very mail does not show that it comes with attachments. The=20
attachments are only visibly indicated once I click on the subject line,=
=20
and then the system falls into a half-freeze state, obviously because it=
=20
is fetching the attachments.

Since I frequently work with large attachments in the 10 MB range, which=
=20
usually load *much quicker*, there is perhaps a bottleneck on the=20
sending side of things? Which, in turns, slows down the user experience=20
significantly.

Even stranger, if I select a different mail for reading and then want to=
=20
go back to Branden's mail, the system slows down again to a semi-halt,=20
even affecting the user input while writing this mail. This is also=20
something I never experience with other big attachments. Once=20
Thunderbird fetches the attachment, it stays --- not in this case,=20
though. Is there a different type of handshake between MUA and list, in=20
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=
=20
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

=2D-=20
Dr. Oliver Corff
mailto:[email protected]