Conversation

Notices

1. Embed this notice
   Rich Felker (dalias@hachyderm.io)'s status on Friday, 19-Jun-2026 23:18:00 JST Rich Felker

   Graph I'd be really interested in seeing: relative size of headers vs body for legitimate (not spam or automated stuff, actual human-written) email over time.

   Inspired by the gignatic amount of DKIM & other garbage blobs present these days in otherwise tiny mail, and wondering how much of my mail storage is wasted on that.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Friday, 19-Jun-2026 23:20:26 JST Rich Felker

     in reply to

     I'm strongly considering doing a delivery-time filter on headers to strip DKIM and other junk. Both to get storage size (and folder load time) down, and to avoid holding hostile non-repudiation vectors and other privacy-leaking stuff that's irrelevant to the sender's actual message.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Friday, 19-Jun-2026 23:44:25 JST Rich Felker

     in reply to

     • MacLemon
     • leyrer

     @MacLemon @leyrer Yeah I'm not counting that as legitimate email tho. 😁 Thankfully it's a tiny % of what I receive. My bulk is free software mailing lists where body is text and attachments are at most patches.

   • Embed this notice
     MacLemon (maclemon@chaos.social)'s status on Friday, 19-Jun-2026 23:44:28 JST MacLemon

     in reply to

     • leyrer

     @leyrer That was a few years ago… but back then already the header part was larger by quite a margin compared to a text body part without attachments.

     Given that today everything is sent as completely bogus HTML and marketing department force people to add company logos, etc to each and every email … the meaningful-content to other-useless-bullshit ratio is fubared.

     @dalias

   • Embed this notice
     leyrer (leyrer@23.social)'s status on Friday, 19-Jun-2026 23:44:29 JST leyrer

     in reply to

     • MacLemon

     @dalias IIRC, @MacLemon did that statistic ...

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Saturday, 20-Jun-2026 02:54:06 JST Rich Felker

     in reply to

     • leyrer

     @leyrer I don't use overcommit, so.. 🤷

     Yeah, for files that won't be modified in-place, transparent compression doesn't break anything, but the filesystem can't see what future usage for files will be, and in general transparent compression does not get you any additional commit budget because you have to account for the possibility of file contents being replaced by high entropy.

   • Embed this notice
     leyrer (leyrer@23.social)'s status on Saturday, 20-Jun-2026 02:54:07 JST leyrer

     in reply to

     @dalias given current compression techniques that work _very_ well on plain text, is size even a concern? (I am with you on the principle).

     https://forums.freebsd.org/threads/auto-zfs-install-why-is-compression-enabled-by-default.92972/