Hi Marcus,

At 2026-07-28T10:43:20+0200, Marcus Rohrmoser wrote:
> On Mon, 27 Jul 2026 16:08:05 -0500
> "G. Branden Robinson" <[email protected]> wrote:
> > ...
> 
> thanks for your entertaining and enlighting essay,

Thank you for saying so!  I strive always to be worth reading, at least
for the sorts of audiences I can envision.

Yours was the only concrete feedback I saw on this issue.

> > Tell me what you'd like to see!
> 
> I prefer social agreements rather than hard technical limits

I have the opposite preference in this case; because I am (1) a
prominent producer of big attachments, (2) one of the mailing list
administrators, and (3) a forgetful sort, I fear creating an impression
of refusing to abide by the rules that supposedly apply to everyone.
That's a principle of "leadership" all too commonly in evidence, from
volunteer FLOSS projects to nation-states.

I'd prefer to configure a technical limit that will bounce my own
excessively large mails back to me.  Similarly, I have to hand-approve
my own announcements to the info-groff list--that list is moderated, so
_all_ posts get held for moderation.  This is not an onerous procedure.

> ...and would be happy to receive emails with at max 1MB of weight if
> need be.  100K is fine, 1MB annoying and 10MB or above is
> indistinguishable from a DOS-attack.  Can we amend the prose list
> rules/howto and just practice it that way?

Since the community didn't exactly buzz into activity and present me
with a consensus I can implement, I'm having to rely more on my own
judgment and authority than I would prefer.

Taking into account your parameters, and the specimens of attachment
seen earlier this month, after composing this mail I'll apply a
threshold of 768 kB (or KiB, whichever unit Mailman uses) to the
administrative interface.

This limit is deliberately _below_ your annoyance threshold.  It's
easily high enough for attachments like Deri's 76 KB squirrel, anyone's
PGP signature, and almost any human-maintained *roff source document.

Looking at <https://www.gnu.org/software/groff/manual/>, I observe that
the PDF, uncompressed plain text, and ("all one page") HTML rendered
forms of groff's Texinfo manual are well over 1 MB, as is the collected
groff man pages PDF, which is one of the exhibits that saturated your
slow link for long enough that it drew your attention.

Without applying data compression, and sometimes even if one does,
"practical documents" in the range of a few hundred pages--typical of
much long-form literature across many disciplines--seem irreducible very
far below your 1 MB annoyance threshold, so setting the limit exactly
there doesn't seem like it really buys anything special.

Consequently, _lowering_ the threshold below even that by a bit seems
like it wouldn't exclude major new classes of document, _and_ would less
often ping your annoyance meter (and that of others similarly situated
in WAN bandwidth).

Proceeding purely on the instincts of my alimentary canal, 512 KB
"feels" a bit too restrictive, so the arithmetic mean of that and 1 MB
"feels" like it might work okay.  Thus, 768 KB.

(Someday, I hope to use the _harmonic_ mean in anger for something other
than calculating a parallel resistance.)

So I'll give that a try and apply a notice to the "groff" mailing list's
description at <https://lists.gnu.org/mailman/listinfo/groff>.

Thanks for your patience while I struggle with the responsibilities of
management.

Regards,
Branden

P.S.  Keywords for fun and for pursuit (outside the alimentary canal) of
      the issues raised here: Shannon entropy, Kolmogorov complexity.
      Also apparently it turns out that publishing economics, material
      properties, and human ergonomics drive printed, bound matter
      toward an accumulation point (or interval) around 300-400 pages.
      The "plain text" of such a work falls easily below our 768 KB
      limit, especially if gzipped or similar, whereas the same text set
      as type blows well past 1 MB no matter what one does, it seems.

Attachment: signature.asc
Description: PGP signature

Reply via email to