Re: Netiquette / Email weight

At 2026-07-30T17:50:58-0500, G. Branden Robinson wrote:

> * P.S. Keywords for fun and for pursuit (outside the alimentary canal) of
> the issues raised here: Shannon entropy, Kolmogorov complexity.*


Gonna interpret that first keyword as an invitation for stochastic
terrorism:

At 2026-07-28T10:43:20+0200, Marcus Rohrmoser wrote:

> *and 10MB or above is indistinguishable from a DOS-attack *


That's impossible, MS-DOS had at most ~60 KB of RAM, and anything as large
as 10 MB would've just been stored and loaded from optical media.

I believe you meant a DoS-attack (with the medial minuscule). Casing is
important in e-mail discourse!

Kidding aside, I wish it were possible to upload files as a detached, uh,
attachment in the same way that Savannah allows file uploads to be
referenced by ID, or the way GitHub allows one to upload whitelisted
filetypes to a comment that you don't even end up posting (which leaves me
to speculate on whether those attachments remain hosted on GitHub's CDN
indefinitely, or if they get purged, and if so, do they only get purged if
nobody's accessed them?)

Anything larger than 1 MB has me questioning if it's better to upload to
PasteBin (if it's solid text), a GitHub Gist, or even just a link to
Dropbox, Google Drive, or some other cloud-hosting service I only use to
backup stuff I wouldn't miss on a stolen thumb-drive. Having that 1 MB
attachment be a link to an attachment uploaded by GNU's mail-archive in
parallel with its mailing list archival would go a long way to eliminating
qualms about what to attach to a mailing list that ends up filling the
inboxes of hundreds of subscribers.

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.


I'm actually gonna see if I can build and test the new release candidate so
I won't accost a hapless Brendan with complaints about Roff code breaking
because I wrote it in an obliquely idiotic fashion. That'll be my
appropriately minuscule contribution to this month's e-mail discourse.
=E2=80=94 Alhadis

On Fri, 31 Jul 2026 at 08:51, G. Branden Robinson <
[email protected]> wrote:

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