From: Jean Louis <bugs@gnu.support>
To: Tim Cross <theophilusx@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Add Maildir support to RMAIL
Date: Mon, 26 Jul 2021 09:08:36 +0300 [thread overview]
Message-ID: <YP5RZFgHBg8RSUma@protected.localdomain> (raw)
In-Reply-To: <87wnpdhm0s.fsf@gmail.com>
* Tim Cross <theophilusx@gmail.com> [2021-07-26 05:01]:
> How your email provider (e.g. google) stores messages is irrelevant. You
> retrieve messages from your provider via imap (or possibly pop3), which
> is a protocol that sits at a higher level than storage - it does not
> know or care about how the messages are stored. It simply retrieves the
> message and passes it through to your imap client.
That is right in most cases.
Though MTA on the remote server may store messages in Maildir
format. That allows also tools like scp or rsync to be used to move
remote Maildirs to local computer.
> These days, I use mu4e and mbsync. My messages are stored in maildir
> format and I have the power of 'mu' to search/manipulate them and the
> ease of mu4e for reading.
The `mu' indexer is great, and `mu4e' is using the `mu' indexer, and
not directly Maildir format. it is "via" that helps in finding emails
like a search engine, but does not really help handling and reading
and manipulating Maildir format.
> The nice thing about mu4e is that it uses Emacs' standard message
> mode for composing messages and Gnus' for displaying/rendering
> messages (but without the overhead/confusion of a Gnus
> interface).
One bad thing is that mu4e cannot handle number of Maildirs when it
comes to 50000 conversations, it will never complete the list of
Maildirs. I have alerted author longer time ago, though it does not
help.
> Another 'simple' mail interface which is quite popular is 'notmuch',
> which I've not used, but I believe is based on similar principals
> i.e. small utilities which are combined together with a nice
> interface wrapper written in Emacs lisp.
It is way slower on my x86_64 GNU/Linux system than `mu', or it may
never even finish the indexing process. It needs probably 5 times
longer time to index 50000+ Maildirs than `mu' indexer.
> The only time when you really need to worry about what storage format
> your email client uses is when it comes to sorting out backups or
> perhaps fixing data corruption. The maildir architecture became popular
> because mbox was seen as a bit inefficient and fragile (large files
> where any corruption make all messages unavailable) or when using
> multiple clients.
Nothing changed in that regard. Mbox system did not improve over the
Maildir system.
Using maildir format by D.J. Bernstein
http://cr.yp.to/proto/maildir.html
Quote:
Why should I use maildir?
Two words: no locks. An MUA can read and delete messages while new
mail is being delivered: each message is stored in a separate file
with a unique name, so it isn't affected by operations on other
messages. An MUA doesn't have to worry about partially delivered mail:
each message is safely written to disk in the tmp subdirectory before
it is moved to new. The maildir format is reliable even over NFS.
> I think it is a bad idea to try and share the same data across clients.
> I've found that even when a client claims to use maildir format, there
> can be some subtle differences in implementation which can affect how
> reliable the storage is.
Various software is free by the Maildir specification to expand on it,
but Maildir still remains readable and manageable by Maildir
clients. If you have particular software that is not compatible to
Maildir but is expected to be, let me know.
--
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
next prev parent reply other threads:[~2021-07-26 6:08 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-25 12:02 Add Maildir support to RMAIL csh
2021-07-25 12:56 ` Eli Zaretskii
2021-07-25 13:08 ` Eli Zaretskii
2021-07-25 13:54 ` csh
2021-07-25 14:09 ` Eli Zaretskii
2021-07-25 14:18 ` csh
2021-07-25 14:26 ` Eli Zaretskii
2021-07-25 14:57 ` csh
2021-07-25 15:55 ` tomas
2021-07-25 15:58 ` tomas
2021-07-25 16:21 ` Eli Zaretskii
2021-07-26 1:26 ` Tim Cross
2021-07-26 6:08 ` Jean Louis [this message]
2021-07-26 13:03 ` Eli Zaretskii
2021-07-27 0:23 ` Richard Stallman
2021-07-26 5:23 ` Jean Louis
2021-07-26 9:34 ` Antoine Kalmbach
2021-07-26 10:45 ` Jean Louis
2021-07-26 10:59 ` Antoine Kalmbach
2021-07-26 13:36 ` Jean Louis
2021-07-26 21:56 ` csh
2021-07-27 6:37 ` Antoine Kalmbach
2021-07-28 1:00 ` Richard Stallman
2021-07-28 5:25 ` Yuri Khan
2021-07-25 13:50 ` csh
2021-07-26 8:35 ` Philip Kaludercic
2021-07-25 22:18 ` Eric Abrahamsen
2021-07-26 5:53 ` Paul Jarc
2021-07-26 15:42 ` Eric Abrahamsen
2021-07-26 5:19 ` Jean Louis
2021-07-26 5:29 ` Jean Louis
2021-07-26 8:35 ` Philip Kaludercic
[not found] <1627220913.7967@bluehome.net>
2021-07-25 14:06 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2021-07-27 22:02 csh
2021-07-28 7:13 ` Antoine Kalmbach
2021-07-28 21:31 ` csh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YP5RZFgHBg8RSUma@protected.localdomain \
--to=bugs@gnu.support \
--cc=emacs-devel@gnu.org \
--cc=theophilusx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.