BLU Discuss list archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- Subject: [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: ron at bclug.ca (Ron)
- Date: Wed, 21 Jan 2026 23:28:46 -0800
- In-reply-to: <20260120215709.4cd9c226.Richard.Pieri@gmail.com>
- References: <61c91e0a-f658-415c-a91d-bc8cb008bf0b@borg.org> <26989.37879.578151.953291@gargle.gargle.HOWL> <26989.37936.100241.254462@gargle.gargle.HOWL> <c40fd68e-e540-471c-a253-7ae04dedaa65@borg.org> <20260119080150.7891b97d.Richard.Pieri@gmail.com> <56dcf563-62a6-4c16-aa84-ed825818def7@borg.org> <987cd7dc-096a-4a4c-be90-20e4847cdb17@bclug.ca> <20260120162647.1d90d2d7@mydesk.domain.cxm> <32eaffac-42e5-4af7-9fae-8a0514d9b97d@bclug.ca> <20260120215709.4cd9c226.Richard.Pieri@gmail.com>
Rich Pieri wrote on 2026-01-20 18:57: > On Tue, 20 Jan 2026 14:05:10 -0800 Ron<ron at bclug.ca> wrote: > >> A DB makes most sense for email messages - index-able, ACID >> compliance (depending on DB), fast, etc. > > Databases are the WORST possible way to store arbitrary files. We're talking email *messages*, not files - there's no requirement that messages are files. And when it comes to storing data, databases are kinda designed for it. Email is data: each message a record; maybe a column for headers, subject, to, from, and body, folder, date,... Index several of those for fast access. Perfect. Postfix and Dovecot both already support storing & retrieving info with SQL. >> when a message is marked "Read", the *file name* is changed to >> reflect the change in status! >> > It's efficient Maybe the rename is efficient but... > It's fast, faster than any database > could ever hope to be on the same filesystem. Not a chance, else PostgreSQL et al would store each record as a file. "Find the one message out of 50,000 where the subject is $x" is going to be faster in a DB. Every. Single. Time. (Searching on the server is not uncommon.) Also, it depends on which file system it's installed on. Some are tuned for many small files, some less so. And running out of inodes can be rather disruptive. Per the Stalwart dev(s): > Maildir is an ancient format that does not scale well. It is not going > be supported [as a message store] by Stalwart. > anything beyond exporting/importing Maildir is out of scope for > Stalwart. Making Stalwart write Maildirs to the filesystem would feel > like adding an exhaust to an electric car > It's brilliant in its simplicity. But it's outdated in its implementation. This isn't the 90s anymore (MailDir designed in 1995). And, what other software changes filenames to indicate something has happened with the file? myfile.txt becomes myfile.txt.read once opened? Nonsense. I say this as someone who has a script that relies on Maildir files to rewrite the subject of my Chinese Word Of The Day lessons to include the kanji & jyutping. Not sure how I'd do that in a DB. Oh, and backups - rsync sees all these changes in file names and wants to back them all up again despite the contents unchanged. PostgreSQL will happily replicate only changed records offsite for backup, maybe a bit more flexible. >> Designed to be *fast* at up-to a couple hundred terabytes. >> > Designed to compete with Microsoft Exchange on Windows, more like. So? I'm unclear on what that's supposed to mean, but since it's *not* MS Exchange, it *does* support open standards, and it *is* open source software, what's the problem? Also, when scaling beyond "my own personal email server, plus maybe family" to "people I do not know pay money for email accounts", Stalwart allows users to do their own password management. Stalwart also allows user-controlled at-rest encryption of email. Those are quite important these days. One can run RoundCube webmail client with necessary plug-in to interact with Dovecot's password management to allow users to change their own passwords, but that requires PHP, RoundCube, httpd, etc. And still no encryption at-rest (with per-user encryption keys). Finally, it's nice to have quotas for mailboxes, Cal/Card/WebDAV managed in one place, i.e. one quota applied to everything. > Stalwart runs on Windows which means it needs to perform acceptably > on NTFS, and the "easy" way to do that is throw it all in a big ol' > database. Got anything to back up that assertion? Because "Stalwart devs chose a database because Windows" sounds like some wild fever-dream conspiracy theory. Both mbox and maildir suffer from inefficiencies of either large files (mbox) or many small files (maildir). Both suck for efficiency when dozens / hundreds / thousands / more users are accessing storage of possibly millions of messages. Databases are a perfect tool for fast, concurrent access. Here's an example MailDir file name: 1768962755.V2c00b601I89a3bM177540.mail.bclug.ca:2,RSb Probably "Read", "Seen", plus some other flags set - mark as unread or reply and whole file gets backed up again. And, that's not even touching on how folders are represented: .Archives.2026.01_January is roughly the folder path for /Archives/2026/01_January (I've forgotten that particular piece of brain damage). I'm fond of MailDir because I have a Python script on the server that detects new messages in a specific folder, it parses the HTML, rewrites the Subject, recomposes the message so Subject lines are meaningful, then writes the new file to ./INBOX/Cantonese/new and voila, I can refresh my Chinese learning from scanning subjects. That'll be more work to do if I decide to use Stalwart for email. Almost certainly will use it for Cal/Card/WebDAV though - that's another critical feature that Postfix / Dovecot don't support, requiring something else (NextCloud or Stalwart seem the best options?).
- Follow-Ups:
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: markw at mohawksoft.com (markw at mohawksoft.com)
- [Discuss] Stalwart E-mail; Was: Re: SSH options
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- References:
- [Discuss] Future of X11 (was Trying to connect to internet in Debian)
- From: kentborg at borg.org (Kent Borg)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: dbarrett at blazemonger.com (Daniel Barrett)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: kentborg at borg.org (Kent Borg)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: kentborg at borg.org (Kent Borg)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: ron at bclug.ca (Ron)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: slitt at troubleshooters.com (Steve Litt)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: ron at bclug.ca (Ron)
- [Discuss] SSH options (was Future of X11 (was Trying to connect to internet in Debian))
- From: richard.pieri at gmail.com (Rich Pieri)
- [Discuss] Future of X11 (was Trying to connect to internet in Debian)
- Prev by Date: [Discuss] MIT IAP seminar: Testing APIs and HTTP with Hurl
- Next by Date: [Discuss] Stalwart email & DB vs file system for message storage
- Previous by thread: [Discuss] Stalwart email & DB vs file system for message storage
- Next by thread: [Discuss] Stalwart E-mail; Was: Re: SSH options
- Index(es):
