Re: Hide a message?
On Fri, Dec 14, 2018 at 10:53:03PM -0500, Kurt Hackenberg wrote: > I dislike mbox because it's a bad design, and has many variants that > are partially incompatible and more or less indistinguishable. And yet Mutt manages to handle them all flawlessly. I don't agree the design is bad. I would agree that it has drawbacks, and the fact that historically the various Unix vendors basically refused to ever agree on anything sucks. But Maildir also has drawbacks, and DJB sucks in his own way too. So does everything. > In practice, used certain ways, mbox sometimes loses messages. > Trouble arises mostly when an mbox file is read and written by > multiple programs, because they might implement different variants > of it. No, trouble arises mostly when two different programs are trying to write the mail spool file simultaneously, and one or both of them is doing it wrong. Reads simultaneous to a single write should never cause corruption. Ever. If it happens, it's because one program has a critical bug. The biggest culprit is using mbox on NFS. You just shouldn't. This counts as "doing it wrong." =8^) This has to do with the inherent tradeoffs of designing a network file system that is reliable and performant, as much as it is about how mbox works. The mbox format predates NFSv1 by on the order of 15 years, so it's hardly fair to blame mbox's design for that deficiency. It depends on POSIX file system semantics, and NFS breaks them, so... you either need a different file system, or a different file object store format. Or both. We got both. :) I haven't looked into how mbox does on NFSv4 because I still think NFS-mounted mail spools are dumb for other reasons (like security) so I can't say whether it works well enough to make using mbox reliable or not. > Mbox stores multiple RFC 822 messages in a single file. RFC 822 > doesn't include a way to say where a message ends, so mbox has to do > that. Mbox does that poorly, and in many different ways. That's > the problem. The only actual problem is that various Unix vendors contrived their own solutions to that problem, and rather quite intentionally did not standardize them. So, a well-behaved MUA needs to handle them all, under the assumption you may have used all of them. It's not hard to do if you understand them all, and Mutt does that. > Mbox doesn't mark the end of each message; the end is implied by the > beginning of the next message, identified by the control line mbox > puts before each message, which starts with "From ". Actually it's "\n\nFrom " (two newlines, two spaces, followed by whatever). That matters because it's not normally something you would put in a message you've typed. But, your mailer, at least, knows what you typed. Ideally it should prevent you from sending such a message, by using QP or B64 or some such thing. ">From" quoting is AFAIK not really used anymore--or at least shouldn't be. This is a known problem with known solutions which are not hard to implement. > Unfortunately, there are many syntaxes for that From_ line. This turns out to be largely uninteresting, due to much of the above. After the demarcation of the next message is established (the "\n\nFrom " matches) the format is not remotely interesting. > I'm not saying anything against Mutt. In fact, from my limited > knowledge, Mutt's implementation of mbox seems pretty solid. The > problem is the design of the file format, which came from elsewhere, > long before Mutt existed. These statements seem largely contradictory to me. If Mutt has an implementation that's reliable (it is) and performs well given known tradeoffs (it does), and isn't overly complex in its implementation (it's not) then it seems the design is not the problem, but rather whatever problems you're having are caused by the bad implementation of what you're using. Or, you're doing something crazy. I will grant you that Maildir's design has the benefit of happening after many years of the pain of dealing with different vendors' solving the different issues differently, and so it has a single well defined spec (mbox predates maildir by more than 2 decades). But despite that Maildir still does have its drawbacks, some of which I've already pointed out (or referred to). It also suffers from a portability problem that DJB *should not* have gotten wrong: it uses colons as separators in the name, which is not an allowable character in filenames on some platforms. I'm by no means denigrating Maildir; DJB is brilliant and Maildir does a great job at solving certain problems. But that doesn't mean that mbox is bad. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpiya5xeiDa8.pgp Description: PGP signature
Re: Hide a message?
On 17Dec2018 12:57, derek martin wrote: On Sat, Dec 15, 2018 at 11:49:05AM +0700, Victor Sudakov wrote: Ian Zimmerman wrote: >I agree that there are good reasons to use IMAP, but none of them seem >to apply to me :) How about accessing your mail archives from a mobile device, for a reason? FWIW this, for me, is the ONLY reason I want to use IMAP. But I find it's not a good enough reason to go through the pain of converting all my folders to one type in order to do it. Anything important, I can just write a procmail rule to forward to my gmail account. Indeed. My mail flow goes: suck from my mail server with POP, file locally, forward important messages to my "for my phone" IMAP accessable account. My filing rules do that automatically for certain things and my mutt settings do it for: any message to which I reply (original and reply forwarded) and any message I flag (flags the messages, forwards a copy to the phone). And when I say "forward" I mean "bounce" in mutt terms. Cheers, Cameron Simpson
Re: Hide a message?
On Sat, Dec 15, 2018 at 11:49:05AM +0700, Victor Sudakov wrote: > Ian Zimmerman wrote: > >I agree that there are good reasons to use IMAP, but none of them seem > >to apply to me :) > > How about accessing your mail archives from a mobile device, for a reason? FWIW this, for me, is the ONLY reason I want to use IMAP. But I find it's not a good enough reason to go through the pain of converting all my folders to one type in order to do it. Anything important, I can just write a procmail rule to forward to my gmail account. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpU1dytxKvyi.pgp Description: PGP signature
Re: Hide a message?
On 2018-12-15 12:04, Victor Sudakov wrote: > Please name a couple of horrible consequences that could happen to my > mail because of procmail. I'm not doubting your words, I just want to > be aware. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771958 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-16844 These have been fixed, but the particular "BuGless" style in which the code is written makes me suspect they weren't the last ones. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: Hide a message?
On 12/15/18 1:01 AM, Erik Christiansen wrote: On 13.12.18 13:05, Kurt Hackenberg wrote: You may want to preserve message attributes -- things like, this message has been read, this message has been replied to, this message has been flagged, this message has been assigned the keyword "blorgh". Mail delivery agents, including procmail, are likely to drop that information. Hmmm ... can any of that actually be true? Let's check. Mutt makes flag and read status persistent through added headers such as: Status: RO X-Status: F Is it in reality even remotely "likely" that any LDA contains code to search out those headers and delete them in transit? (Please feel free to post any code snippets found.) The assertion also seems to ignore that mutt inserts those headers _after_ the LDA has delivered the messages, so there is normally no possible opportunity for the claimed LDA header removal - is there? That is true when the delivery agent is part of receiving a new message coming in from the Internet -- but that's not what I was talking about. My message was a reply to Ian Zimmeran's suggestion to use a delivery agent as part of converting mail that has already been received, to a different storage format (converting mbox to maildir). Ian said this: > For conversion, you can use formail -s together with some script that > will deliver to maildirs. I can provide you with mine if you ask. > Also, something like > > DEFAULT=/path/to/maildir/ procmail /dev/null > > will work (but I try to avoid procmail for data-critical tasks). See? Conversion after the fact, not original delivery.
Re: Hide a message?
On 15.12.18 19:35, Cameron Simpson wrote: > On 15Dec2018 17:01, Erik Christiansen wrote: > > Is it in reality even remotely "likely" that any LDA contains code to > > search out those headers and delete them in transit? (Please feel free > > to post any code snippets found.) > > > > The assertion also seems to ignore that mutt inserts those headers > > _after_ the LDA has delivered the messages, so there is normally no > > possible opportunity for the claimed LDA header removal - is there? > > If you use a tool which isn't mutt, yes there's some scope to lose this > information. Yup, I could write an MUA, then there'd be scope for a bug, I bet. The problem with that is that the post to which I replied posited that local delivery agents could interfere with mutt's use of headers for internal purposes. That's an entirely different discussion. ... > If you use mutt to do the conversion, I'd expect flags to survive. I would > not normally have any specific confidence that another tool would do so. Yup, mutt's good stuff. But the post which I queried posited that LDAs could magically mangle headers which mutt does not insert until _after_ delivery. It is not least the time-travel component which my post queried. I do not think that you have addressed that with this new topic of MUA comparison. Erik
Re: Hide a message?
On 15Dec2018 17:01, Erik Christiansen wrote:
On 13.12.18 13:05, Kurt Hackenberg wrote:
You may want to preserve message attributes -- things like, this
message has
been read, this message has been replied to, this message has been flagged,
this message has been assigned the keyword "blorgh". Mail delivery agents,
including procmail, are likely to drop that information.
Hmmm ... can any of that actually be true? Let's check. Mutt makes flag
and read status persistent through added headers such as:
Status: RO
X-Status: F
Is it in reality even remotely "likely" that any LDA contains code to
search out those headers and delete them in transit? (Please feel free
to post any code snippets found.)
The assertion also seems to ignore that mutt inserts those headers
_after_ the LDA has delivered the messages, so there is normally no
possible opportunity for the claimed LDA header removal - is there?
If you use a tool which isn't mutt, yes there's some scope to lose this
information. For example, in a mbox the Status: and/or X-Status: headers
hold flags. In a Maildir the flags are stored in the message filename,
not the headers (they may get _duplicated_ there).
As an example, my mail filing programme can save to mbox or Maildir and
has this function:
def save_to_folderpath(folderpath, M, message_path, flags):
''' Save the Message `M` to the resolved `folderpath`.
`message_path`: pathname of existing message file, allowing
hardlinking to new maildir if not None
`flags`: save flags as from MessageFiler.flags
'''
if not os.path.exists(folderpath):
make_maildir(folderpath)
if ismaildir(folderpath):
# save to Maildir
mdir = Maildir(folderpath)
maildir_flags = ''
if flags.draft: maildir_flags += 'D'
if flags.flagged: maildir_flags += 'F'
if flags.passed: maildir_flags += 'P'
if flags.replied: maildir_flags += 'R'
if flags.seen:maildir_flags += 'S'
if flags.trashed: maildir_flags += 'T'
if message_path is None:
savekey = mdir.save_message(M, flags=maildir_flags)
else:
savekey = mdir.save_filepath(message_path, flags=maildir_flags)
savepath = mdir.keypath(savekey)
info("OK %s" % (shortpath(savepath)))
if message_path is None:
# update saved message for hard linking
message_path = savepath
else:
# save to mbox
status = ''
x_status = ''
if flags.draft: x_status += 'D'
if flags.flagged: x_status += 'F'
if flags.replied: status += 'R'
if flags.passed: x_status += 'P'
if flags.seen:x_status += 'S'
if flags.trashed: x_status += 'T'
if len(status) > 0:
M['Status'] = status
if len(x_status) > 0:
M['X-Status'] = x_status
with LogExceptions():
text = M.as_string(True).replace('\nFrom ', '\n>From ')
with open(folderpath, "a") as mboxfp:
mboxfp.write(text)
info("OK >> %s" % (shortpath(folderpath)))
return message_path
So when I wrote this, the mbox flags are _split_ over the Status: and
the X-Status: headers. Yay.
If you use mutt to do the conversion, I'd expect flags to survive. I
would not normally have any specific confidence that another tool would
do so.
Cheers,
Cameron Simpson
Re: Hide a message?
On 13.12.18 13:05, Kurt Hackenberg wrote: > > You may want to preserve message attributes -- things like, this message has > been read, this message has been replied to, this message has been flagged, > this message has been assigned the keyword "blorgh". Mail delivery agents, > including procmail, are likely to drop that information. Hmmm ... can any of that actually be true? Let's check. Mutt makes flag and read status persistent through added headers such as: Status: RO X-Status: F Is it in reality even remotely "likely" that any LDA contains code to search out those headers and delete them in transit? (Please feel free to post any code snippets found.) The assertion also seems to ignore that mutt inserts those headers _after_ the LDA has delivered the messages, so there is normally no possible opportunity for the claimed LDA header removal - is there? As for "blorgh", if you refer to e.g. colour keywords, then mutt assigns colours on regexes evaluated at the time of display. There is no connection between that and any LDA run some time beforehand. So, is there anything factual in the assertion? Erik
Re: Hide a message?
Ian Zimmerman wrote: On 2018-12-14 11:27, Victor Sudakov wrote: > DEFAULT=/path/to/maildir/ procmail /dev/null > > will work (but I try to avoid procmail for data-critical tasks). May I ask why? procmail has been in my ~/.forward for two decades, with lots of rules, and I've not seen any problems from it. Because I have seen its source code, and tried to hack it :-) Please name a couple of horrible consequences that could happen to my mail because of procmail. I'm not doubting your words, I just want to be aware. In all these years, I've seen only one really annoying thing: one of my users uploaded a procmailrc with MSDOS-style CR/LF line endings, and this was very tricky to find out and fix. OTOH, FreeBSD's awk is also intolerant to CR/LF line endings and it's not a reason not to use it. > Lastly, are you sure you need IMAP and dovecot at all? Sure. First of all, other users need it, and I don't like the idea of personal settings for myself. Then, I like to use a mobile app (AquaMail) for mail access when on the road. Yes, that's certainly a reason. Too bad; in my case I and the few other users all agree that email (a relatively slow and deliberate mode of communication on a modern scale) doesn't mix well with "on the road", unlike SMS. You are correct about communication per se. But being able to read mailing lists on the road is precious. I usually mark as unread the interesting messages, and reply to them later when I'm at my desktop. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
Derek Martin wrote: [dd] What we really need is some sort of a database back end anyway, so we can have reasonable virtual folders. :) I hope you are kidding. Microsoft Exchange went this way. I don't like the result. I don't necessarily mean storing the message in the database... the file system could be used for that. Or not... For virtual folders, I use symlinks in my ~/Mail. They work fine both with mutt and (seemingly) dovecot: [vas@adm2 ~] file Mail/sibptus/fido7.ru.unix.bsd Mail/sibptus/fido7.ru.unix.bsd: symbolic link to unix I'm not sure however if this method really works correctly with dotlocking (e.g. mutt_dotlock). Or do you mean individual message "labels" instead of folders, like in Gmail? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
Ian Zimmerman wrote: On 2018-12-13 13:05, Kurt Hackenberg wrote: Whether to use IMAP at all -- well, one reason to use IMAP, even if you have direct access to the mail files, is so you can use any mail reader, not just one. When various mail readers read and write files directly, even file formats that are supposedly the same, the mail readers may not do it compatibly with each other. That's especially true of mbox, which is actually many related file formats, not just one. Also, IMAP allows concurrent access. Direct access to files by a mail reader many or may not implement concurrent access. I copy message files from the new/ part of my spool on the server to my local box for reading. Since this is just a file copy the lock-freedom of the maildir format avoids any concurrency problems. I agree that there are good reasons to use IMAP, but none of them seem to apply to me :) How about accessing your mail archives from a mobile device, for a reason? That is probably the only reason I have my procmail deliver mail to IMAP-accessible mboxes instead of elsewhere. AquaMail is of course inferior to mutt but running a SSH-client with mutt inside is still not convenient on a smartphone. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On 12/13/18 10:05 PM, Patrick Shanahan wrote: mbox still serves my needs and has never failed me. why would I want to invest time and effort to change to something (anything) else? maildir does not "work better" as I can see. If mbox works for the way you use it, there's no need to change. I dislike mbox because it's a bad design, and has many variants that are partially incompatible and more or less indistinguishable. In practice, used certain ways, mbox sometimes loses messages. Trouble arises mostly when an mbox file is read and written by multiple programs, because they might implement different variants of it. I can believe that your mbox files work all right if they're only used by Mutt. Mbox stores multiple RFC 822 messages in a single file. RFC 822 doesn't include a way to say where a message ends, so mbox has to do that. Mbox does that poorly, and in many different ways. That's the problem. Mbox doesn't mark the end of each message; the end is implied by the beginning of the next message, identified by the control line mbox puts before each message, which starts with "From ". Unfortunately, there are many syntaxes for that From_ line. A message line can also start with "From ", so a message line like that is escaped, by changing it to ">From " -- with any of three different algorithms, or sometimes not at all. Sometimes all this is combined with either or both of Lines: and Content-Length:, both invented for mbox, neither standardized. As others have said, there are tradeoffs between a single file of messages and multiple files, but that's not specific to mbox format. Any single sequential file, mbox or some other format, would be well suited to import/export, file transfer, and archives, and poorly suited to random access and concurrent access. I'm not saying anything against Mutt. In fact, from my limited knowledge, Mutt's implementation of mbox seems pretty solid. The problem is the design of the file format, which came from elsewhere, long before Mutt existed.
Re: Hide a message?
Tim Chase wrote: On 2018-12-13 22:05, Patrick Shanahan wrote: mbox still serves my needs and has never failed me. why would I want to invest time and effort to change to something (anything) else? maildir does not "work better" as I can see. Perhaps you're not putting strains on mbox that others have. I've found that mbox works well in certain conditions: 1) only one reader/writer (no other scripts/tools touching your mail store) on local file-systems 2) particularly well if your mboxes are mostly append-only (it tends to perform worse and have more risk of data-loss if you're modifying messages in the middle). The one-big-file-of-mail also compresses nicely if stored on a ZFS volume. I have had mbox files break when on NFS shares and when multiple programs are writing to them (especially when removing messages from the middle of the file). Sometimes I'm lucky and it's not grievous and I only lose a message or two or things get sheared removing the intra-message markers, putting one message at the end of a previous message. It is interesting however that Communigate Pro uses indexed mbox as its internal storage format. Even under heavy load and large mboxes, it does not seem fragile or inefficient (from my own experience of supporting a Communigate server at an ISP). OTOH, Communigate is the only process accessing its own mboxes, and they are local, so perhaps this helps. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On Fri, Dec 14, 2018 at 11:43:17AM +1100, Cameron Simpson wrote: > On 13Dec2018 18:26, derek martin wrote: > >Maildir + header caching improves the case for Maildir in some, but > >not all, cases (and if mbox is also supported by header caching > >now, that goes out the window, but I don't recall it ever being > >added). > > The tricky bit with mbox and header caching is that if the mbox is > modified outside of mutt, mutt has to invalidate the entire cache. I think not necessarily. Caching mbox probably means storing the file offset of the messages (i.e. at least the first header, probably all the interesting ones). In the typical case of outside access, we're really talking about appending messages to the end of the mbox. So if Mutt noticed that the file GREW, and the headers of the previously known last message still match, it's probably safe to assume it was appended to and add the new messages to the cache. Of course as you access various messages, you'd confirm they match the cache, and if you find mismatches, then you'd need to rescan the mail folder. But Mutt already needs to rescan the folder if it changes anyway. With the cache this could be made faster--lseeK() through the folder to various cached locations, and only start doing a full scan from the point where they differ... > >Your filesystem also matters... On older systems, maildir would fail > >horribly with very large numbers of messages in a folder because the > >underlying filesystem was very bad at dealing with them. On modern > >systems that's typically much less true, but the details matter. > > Generally mbox is more compact in terms of disc usage. But less > flexible. What we really need is some sort of a database back end anyway, so we can have reasonable virtual folders. :) I don't necessarily mean storing the message in the database... the file system could be used for that. Or not... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpmfsovcZFvK.pgp Description: PGP signature
Re: Hide a message?
On Fri, Dec 14, 2018 at 07:37:28AM -0600, Tim Chase wrote: > On 2018-12-13 22:05, Patrick Shanahan wrote: > > mbox still serves my needs and has never failed me. why would I > > want to invest time and effort to change to something (anything) > > else? maildir does not "work better" as I can see. > Perhaps you're not putting strains on mbox that others have. I've > found that mbox works well in certain conditions: > > 1) only one reader/writer (no other scripts/tools touching your mail > store) on local file-systems > > 2) particularly well if your mboxes are mostly append-only (it tends > to perform worse and have more risk of data-loss if you're modifying > messages in the middle). The one-big-file-of-mail also compresses > nicely if stored on a ZFS volume. > > I have had mbox files break when on NFS shares and when multiple > programs are writing to them (especially when removing messages from > the middle of the file). Sometimes I'm lucky and it's not grievous > and I only lose a message or two or things get sheared removing the > intra-message markers, putting one message at the end of a previous > message. mbox over NFS (especially old or improperly implemented NFS) can be an issue. However, with many filesystems, Maildir has its own set of inefficiencies, especially for very large mailboxes. Tho there are certain operations that are easier, because you just have to stat the files to get the status of each message, vs. parsing a big file. I use a combination of the two; for situations where I'm never using IMAP and always sshing somewhere to read mail using Mutt, I do slightly prefer mbox. w
Re: Hide a message?
On Thu, Dec 13, 2018 at 12:38:42PM -0500, Kurt Hackenberg wrote: > On 12/13/18 11:15 AM, Victor Sudakov wrote: > > >Dan Ritter wrote: > >>That doesn't happen in Maildir storage. Is it reasonable to > >>switch from mbox to maildir? > > > >An interesting idea! > > In my opinion, it's always a good idea to convert from mbox to > something that works better. On Unix systems, maildir is usually a > good choice. Define "works better." -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpEn82mSwUnx.pgp Description: PGP signature
Re: Hide a message?
On 2018-12-13 13:05, Kurt Hackenberg wrote: > Whether to use IMAP at all -- well, one reason to use IMAP, even if > you have direct access to the mail files, is so you can use any mail > reader, not just one. When various mail readers read and write files > directly, even file formats that are supposedly the same, the mail > readers may not do it compatibly with each other. That's especially > true of mbox, which is actually many related file formats, not just > one. > > Also, IMAP allows concurrent access. Direct access to files by a mail > reader many or may not implement concurrent access. I copy message files from the new/ part of my spool on the server to my local box for reading. Since this is just a file copy the lock-freedom of the maildir format avoids any concurrency problems. I agree that there are good reasons to use IMAP, but none of them seem to apply to me :) -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: Hide a message?
On Fri, Dec 14, 2018 at 09:06:13AM -0800, Ian Zimmerman wrote: > Yes, that's certainly a reason. Too bad; in my case I and the few other > users all agree that email (a relatively slow and deliberate mode of > communication on a modern scale) doesn't mix well with "on the road", > unlike SMS. For what it's worth, I really can't understand this attitude. If you have e-mail going to your phone, there's practically no difference. The main one is that e-mail can send messages of arbitrary length, whereas SMS is limited to a small number of characters... but you can send more than one, so this limitation is effectively null. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpVm7ngj2hMV.pgp Description: PGP signature
Re: Hide a message?
On 2018-12-14 11:27, Victor Sudakov wrote: > > DEFAULT=/path/to/maildir/ procmail /dev/null > > > > will work (but I try to avoid procmail for data-critical tasks). > > May I ask why? procmail has been in my ~/.forward for two decades, > with lots of rules, and I've not seen any problems from it. Because I have seen its source code, and tried to hack it :-) > > Lastly, are you sure you need IMAP and dovecot at all? > > Sure. First of all, other users need it, and I don't like the idea of > personal settings for myself. Then, I like to use a mobile app > (AquaMail) for mail access when on the road. Yes, that's certainly a reason. Too bad; in my case I and the few other users all agree that email (a relatively slow and deliberate mode of communication on a modern scale) doesn't mix well with "on the road", unlike SMS. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: Hide a message?
I got cured of mbox when I had malware infect my spool file. There were a few thousand messages I wanted to go through in that mbox but clamav quarrantined the whole mbox file and I couldn't read the messages that weren't infected and never learned which of the messages actually got infected either. Now, with MAILDIR, each message gets stored in its own file and for that reason had I run clamav in that environment clamav would have only quarrantined the individual infected messages and not all of them. On Fri, 14 Dec 2018, Tim Chase wrote: > Date: Fri, 14 Dec 2018 08:37:28 > From: Tim Chase > To: mutt-users@mutt.org > Subject: Re: Hide a message? > > On 2018-12-13 22:05, Patrick Shanahan wrote: > > mbox still serves my needs and has never failed me. why would I > > want to invest time and effort to change to something (anything) > > else? maildir does not "work better" as I can see. > > Perhaps you're not putting strains on mbox that others have. I've > found that mbox works well in certain conditions: > > 1) only one reader/writer (no other scripts/tools touching your mail > store) on local file-systems > > 2) particularly well if your mboxes are mostly append-only (it tends > to perform worse and have more risk of data-loss if you're modifying > messages in the middle). The one-big-file-of-mail also compresses > nicely if stored on a ZFS volume. > > I have had mbox files break when on NFS shares and when multiple > programs are writing to them (especially when removing messages from > the middle of the file). Sometimes I'm lucky and it's not grievous > and I only lose a message or two or things get sheared removing the > intra-message markers, putting one message at the end of a previous > message. > > -tkc > > > > > > > --
Re: Hide a message?
On 2018-12-13 22:05, Patrick Shanahan wrote: > mbox still serves my needs and has never failed me. why would I > want to invest time and effort to change to something (anything) > else? maildir does not "work better" as I can see. Perhaps you're not putting strains on mbox that others have. I've found that mbox works well in certain conditions: 1) only one reader/writer (no other scripts/tools touching your mail store) on local file-systems 2) particularly well if your mboxes are mostly append-only (it tends to perform worse and have more risk of data-loss if you're modifying messages in the middle). The one-big-file-of-mail also compresses nicely if stored on a ZFS volume. I have had mbox files break when on NFS shares and when multiple programs are writing to them (especially when removing messages from the middle of the file). Sometimes I'm lucky and it's not grievous and I only lose a message or two or things get sheared removing the intra-message markers, putting one message at the end of a previous message. -tkc
Re: Hide a message?
Cameron Simpson wrote:
On 14Dec2018 11:40, Victor Sudakov wrote:
Kurt, once you've mentioned it. How do I create a maildir folder from
within mutt if my default $mbox_type is mbox?
When I want to create a new folder "foo", I tag some messages and save
them to =foo, mutt asks whether to create "foo" but creates it in mbox
format per $mbox_type.
Well you could make a macro to fiddle $mbox_type. Or fiddle it yourself.
Or you could see my mboxify script elsewhere in this thread for adaption
to your mbox->maildir wish. Its process is to make the maildir from the
script (mkdir foo foo/tmp foo/cur foo/new) and _then_ invoke mutt to do
the message move.
Indeed, after pre-creating the mailbox with
"mkdir -p ~/Mail/foo/{tmp,cur,new}" mutt can save into it.
The only problem left is dovecot's handling of both formats
simultaneously.
That way mutt doesn't make the mailbox and $mbox_type
doesn't come into play.
Thank you!
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On 14Dec2018 11:40, Victor Sudakov wrote: Kurt, once you've mentioned it. How do I create a maildir folder from within mutt if my default $mbox_type is mbox? When I want to create a new folder "foo", I tag some messages and save them to =foo, mutt asks whether to create "foo" but creates it in mbox format per $mbox_type. Well you could make a macro to fiddle $mbox_type. Or fiddle it yourself. Or you could see my mboxify script elsewhere in this thread for adaption to your mbox->maildir wish. Its process is to make the maildir from the script (mkdir foo foo/tmp foo/cur foo/new) and _then_ invoke mutt to do the message move. That way mutt doesn't make the mailbox and $mbox_type doesn't come into play. Cheers, Cameron Simpson
Re: Hide a message?
Michael Tatge wrote: On 12 December 2018 13:39:25 CET, Victor Sudakov wrote: The dovecot IMAP server keeps its folder (mailbox) metadata as a pseudo-message. When I access those mboxes locally with mutt, I see this pseudo-message but I don't want to. Might be a silly question, but why do that in the first place? I presume imap is accessible locally. It is. The only reason not to access IMAP locally is that I'll have to enter the IMAP password each time, or store it in muttrc in plain text, or devise some sophisticated passwordless authentication scheme for dovecot (like Kerberos authentication). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
Kurt Hackenberg wrote: [dd] You can convert mbox to maildir through Mutt, since it can read and write both. Read an mbox folder, copy all its message to a new maildir folder. Kurt, once you've mentioned it. How do I create a maildir folder from within mutt if my default $mbox_type is mbox? When I want to create a new folder "foo", I tag some messages and save them to =foo, mutt asks whether to create "foo" but creates it in mbox format per $mbox_type. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On 2018-12-13 11:23, Jude DaShiell wrote: > maildir if I remember correctly has an inc command once you get it > set up. It looks for an mbox file and does the conversion of that > mbox file for you and loads the mail into the mail directories for > you. This sounds like mh/nmh (which has an `inc`orporate command) format which has its own one-file-per-message storage format similar to Maildir, but isn't Maildir. -tkc
Re: Hide a message?
Ian Zimmerman wrote: I have over 400 mboxes in my ~/Mail directory, some of them being mailing list archives, others being Usenet groups archives, or mboxes inherited from my decommissioned CommuniGate server. My dovecot configuration is simple: "mail_location = mbox:~/Mail:INBOX=/var/mail/%u" If I knew how to convert all this stuff to Maildir storage... Do I have to convert all of them at once? No, mutt can handle maildirs and mboxes alongside each other. It just looks at what kind of file/directory it is dealing with at runtime. I know mutt can, I doubt that dovecot can. For conversion, you can use formail -s together with some script that will deliver to maildirs. I can provide you with mine if you ask. Also, something like DEFAULT=/path/to/maildir/ procmail /dev/null will work (but I try to avoid procmail for data-critical tasks). May I ask why? procmail has been in my ~/.forward for two decades, with lots of rules, and I've not seen any problems from it. Lastly, are you sure you need IMAP and dovecot at all? Sure. First of all, other users need it, and I don't like the idea of personal settings for myself. Then, I like to use a mobile app (AquaMail) for mail access when on the road. Do you have shell access to the server? I do, that's where I use mutt for local access to mailboxes. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On 13.12.18 22:05, Patrick Shanahan wrote: > mbox still serves my needs and has never failed me. why would I want to > invest time and effort to change to something (anything) else? maildir > does not "work better" as I can see. +1 I've used mbox exclusively since the days of SunOS4.1.3 or a bit before, with a variety of MUAs - between three and four decades of trouble-free use. Migrating my 1254 mboxes to mdir would not give me anything other than an extra pile of directories and a horrifying number of files. (What it might give the reader is his concern entirely.) Erik
Re: Hide a message?
* Kurt Hackenberg [12-13-18 12:40]: > On 12/13/18 11:15 AM, Victor Sudakov wrote: > > > Dan Ritter wrote: > > > That doesn't happen in Maildir storage. Is it reasonable to > > > switch from mbox to maildir? > > > > An interesting idea! > > In my opinion, it's always a good idea to convert from mbox to something > that works better. On Unix systems, maildir is usually a good choice. and that is *your* opinion and quite a few others. but there are still many of us who have been around quite some time and still prefer/utilize mbox. linux is *still* about choice even when someone decides that choice is wrong. mbox still serves my needs and has never failed me. why would I want to invest time and effort to change to something (anything) else? maildir does not "work better" as I can see. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri Registered Linux User #207535@ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode
Re: Hide a message?
On 13Dec2018 18:26, derek martin wrote: On Thu, Dec 13, 2018 at 08:46:23AM -0800, Ian Zimmerman wrote: On 2018-12-13 23:15, Victor Sudakov wrote: > If I knew how to convert all this stuff to Maildir storage... Do I > have to convert all of them at once? No, mutt can handle maildirs and mboxes alongside each other. It just looks at what kind of file/directory it is dealing with at runtime. But I believe Dovecot can not... unless that's changed. It was the reason I never switched to it, since I often read my mail locally and use both formats. Yeah, it is quite annoying. We runs dovecot in Maildir mode on our EC2 VM (we self host our email), but only access it with IMAP (or POP). I pull stuff locally from it and read with muttlocally. I think I'd use offlineimap if the IMAP server was my primary email store, so I could IMAP (from my phone or remotely) and mutt on the local copy. You should also be aware that mbox does have advantages over maildir in terms of performance, depending greatly on your access patterns, system configuration, and Mutt configuration. Maildir is often better for frequently-visited, frequently-pruned mailboxes, whereas mbox will likely do better for large archive folders. Maildir + header caching improves the case for Maildir in some, but not all, cases (and if mbox is also supported by header caching now, that goes out the window, but I don't recall it ever being added). The tricky bit with mbox and header caching is that if the mbox is modified outside of mutt, mutt has to invalidate the entire cache. Your filesystem also matters... On older systems, maildir would fail horribly with very large numbers of messages in a folder because the underlying filesystem was very bad at dealing with them. On modern systems that's typically much less true, but the details matter. Generally mbox is more compact in terms of disc usage. But less flexible. Cheers, Cameron Simpson
Re: Hide a message?
On 13Dec2018 15:20, Felix Finch wrote: On 20181214, Cameron Simpson wrote: Others have spoken of preserving attributes (read, flagged, etc). You get all of this by using mutt itself to perform the conversion. Basic scheme: - make an empty maildir - open the mbox with mutt - save all messages to the maildir - close mutt Now you have an empty mbox and a new Maildir with the same messages. Sounds tedious? Couldn't you just tag all messages, then ";s" and name the maildir? Sure, but Victor has 400 mboxes. Besides, that's basicly what my script does. uses mutt but noninteractively. Cheers, Cameron Simpson
Re: Hide a message?
On Thu, Dec 13, 2018 at 11:04:08PM +0100, Michael Tatge wrote: > On 12 December 2018 13:39:25 CET, Victor Sudakov wrote: > >The dovecot IMAP server keeps its folder (mailbox) metadata as a > >pseudo-message. When I access those mboxes locally with mutt, I see > >this pseudo-message but I don't want to. > > Might be a silly question, but why do that in the first place? > I presume imap is accessible locally. Because local file access is very probably considerably faster than IMAP, for at least some access patterns. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpvGmW9hUg5N.pgp Description: PGP signature
Re: Hide a message?
On Thu, Dec 13, 2018 at 08:46:23AM -0800, Ian Zimmerman wrote: > On 2018-12-13 23:15, Victor Sudakov wrote: > > If I knew how to convert all this stuff to Maildir storage... Do I > > have to convert all of them at once? > > No, mutt can handle maildirs and mboxes alongside each other. It just > looks at what kind of file/directory it is dealing with at runtime. But I believe Dovecot can not... unless that's changed. It was the reason I never switched to it, since I often read my mail locally and use both formats. You should also be aware that mbox does have advantages over maildir in terms of performance, depending greatly on your access patterns, system configuration, and Mutt configuration. Maildir is often better for frequently-visited, frequently-pruned mailboxes, whereas mbox will likely do better for large archive folders. Maildir + header caching improves the case for Maildir in some, but not all, cases (and if mbox is also supported by header caching now, that goes out the window, but I don't recall it ever being added). Your filesystem also matters... On older systems, maildir would fail horribly with very large numbers of messages in a folder because the underlying filesystem was very bad at dealing with them. On modern systems that's typically much less true, but the details matter. For a somewhat detailed discussion about the performance differences, you can see my posts in this ancient thread: https://mutt-users.mutt.narkive.com/OE3ugjuM/is-it-safe-to-use-mbox On Thu, Dec 13, 2018 at 01:05:00PM -0500, Kurt Hackenberg wrote: > Since an IMAP server is involved, the ideal would be to do > everything through that server -- read an mbox through IMAP, write a > maildir through IMAP. Offhand, I don't know whether Dovecot can > handle both at the same time... Even if it could, I would imagine this would be much, much slower than using formail or even Mutt, due to the overhead of dealing with the protocol. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpMS_Dpqv5UA.pgp Description: PGP signature
Re: Hide a message?
On 20181214, Cameron Simpson wrote: > Others have spoken of preserving attributes (read, flagged, etc). You get > all of this by using mutt itself to perform the conversion. Basic scheme: > > - make an empty maildir > - open the mbox with mutt > - save all messages to the maildir > - close mutt > > Now you have an empty mbox and a new Maildir with the same messages. Sounds > tedious? Couldn't you just tag all messages, then ";s" and name the maildir? -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o
Re: Hide a message?
On 13Dec2018 23:15, Victor Sudakov wrote: I have over 400 mboxes in my ~/Mail directory, some of them being mailing list archives, others being Usenet groups archives, or mboxes inherited from my decommissioned CommuniGate server. My dovecot configuration is simple: "mail_location = mbox:~/Mail:INBOX=/var/mail/%u" If I knew how to convert all this stuff to Maildir storage... Do I have to convert all of them at once? You don't need to do them all at once, or all at all! I keep my archive folders as mbox and several of my bulky and rarely visited folders as mbox, with the active folders (eg my "python" and "mutt" folders) as Maildir. Others have spoken of preserving attributes (read, flagged, etc). You get all of this by using mutt itself to perform the conversion. Basic scheme: - make an empty maildir - open the mbox with mutt - save all messages to the maildir - close mutt Now you have an empty mbox and a new Maildir with the same messages. Sounds tedious? You can script this. See this script: https://bitbucket.org/cameron_simpson/css/src/tip/bin/mboxify which converts Maildir to mbox (I was going the other way). It would be trivial to adapt it to convert mbox to Maildir. If you're rolling your own script you will be particularly interested in the mutt incantation in the middle: mutt -n -F /dev/null -f "$mailbox" -e "set sort=mailbox-order; set confirmappend=no; set delete=yes; push '.$mailboxtmp'" That is all on one line, in case the email folds it up. In the incantation $mailbox is the source Maildir folder and $mailboxtmp is the target mbox file. The latter is a scratch file, renamed to the original if everything going smoothly; you will see the script itself does a fair bit of sanity checking toavoid accidents. You would reverse that, in that $mailbox would be a source mbox file and $mailboxtmp with be a shiny new Maildir folder. Cheers, Cameron Simpson
Re: Hide a message?
Might be a silly question, but why do that in the first place? I presume imap is accessible locally. On 12 December 2018 13:39:25 CET, Victor Sudakov wrote: >The dovecot IMAP server keeps its folder (mailbox) metadata as a >pseudo-message. When I access those mboxes locally with mutt, I see >this pseudo-message but I don't want to. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Hide a message?
On 12/13/18 11:46 AM, Ian Zimmerman wrote: On 2018-12-13 23:15, Victor Sudakov wrote: I have over 400 mboxes in my ~/Mail directory, some of them being mailing list archives, others being Usenet groups archives, or mboxes inherited from my decommissioned CommuniGate server. My dovecot configuration is simple: "mail_location = mbox:~/Mail:INBOX=/var/mail/%u" If I knew how to convert all this stuff to Maildir storage... Do I have to convert all of them at once? No, mutt can handle maildirs and mboxes alongside each other. It just looks at what kind of file/directory it is dealing with at runtime. For conversion, you can use formail -s together with some script that will deliver to maildirs. I can provide you with mine if you ask. Also, something like DEFAULT=/path/to/maildir/ procmail /dev/null will work (but I try to avoid procmail for data-critical tasks). Lastly, are you sure you need IMAP and dovecot at all? Do you have shell access to the server? You may want to preserve message attributes -- things like, this message has been read, this message has been replied to, this message has been flagged, this message has been assigned the keyword "blorgh". Mail delivery agents, including procmail, are likely to drop that information. You can convert mbox to maildir through Mutt, since it can read and write both. Read an mbox folder, copy all its message to a new maildir folder. Or read an IMAP folder, copy to a maildir folder. I don't know whether Mutt can copy a local folder (eg mbox) to an IMAP folder. Since an IMAP server is involved, the ideal would be to do everything through that server -- read an mbox through IMAP, write a maildir through IMAP. Offhand, I don't know whether Dovecot can handle both at the same time, or whether Mutt can handle two IMAP folders at the same time. But I think, in practice, Mutt and Dovecot get along all right -- that is, Mutt could do the conversion directly, not through IMAP, and Dovecot will understand the result. You'd have to test it, of course. Whether to use IMAP at all -- well, one reason to use IMAP, even if you have direct access to the mail files, is so you can use any mail reader, not just one. When various mail readers read and write files directly, even file formats that are supposedly the same, the mail readers may not do it compatibly with each other. That's especially true of mbox, which is actually many related file formats, not just one. Also, IMAP allows concurrent access. Direct access to files by a mail reader many or may not implement concurrent access.
Re: Hide a message?
On 12/13/18 11:15 AM, Victor Sudakov wrote: Dan Ritter wrote: That doesn't happen in Maildir storage. Is it reasonable to switch from mbox to maildir? An interesting idea! In my opinion, it's always a good idea to convert from mbox to something that works better. On Unix systems, maildir is usually a good choice.
Re: Hide a message?
On 2018-12-13 23:15, Victor Sudakov wrote: > I have over 400 mboxes in my ~/Mail directory, some of them being > mailing list archives, others being Usenet groups archives, or mboxes > inherited from my decommissioned CommuniGate server. > > My dovecot configuration is simple: "mail_location = > mbox:~/Mail:INBOX=/var/mail/%u" > > If I knew how to convert all this stuff to Maildir storage... Do I > have to convert all of them at once? No, mutt can handle maildirs and mboxes alongside each other. It just looks at what kind of file/directory it is dealing with at runtime. For conversion, you can use formail -s together with some script that will deliver to maildirs. I can provide you with mine if you ask. Also, something like DEFAULT=/path/to/maildir/ procmail /dev/null will work (but I try to avoid procmail for data-critical tasks). Lastly, are you sure you need IMAP and dovecot at all? Do you have shell access to the server? -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: Hide a message?
maildir if I remember correctly has an inc command once you get it set up. It looks for an mbox file and does the conversion of that mbox file for you and loads the mail into the mail directories for you. On Thu, 13 Dec 2018, Victor Sudakov wrote: > Date: Thu, 13 Dec 2018 11:15:52 > From: Victor Sudakov > To: mutt-users@mutt.org > Subject: Re: Hide a message? > > Dan Ritter wrote: > >> > >> Is there a way to hide a message (e.g. with a certain subject) from view in > >> a mailbox, without actually deleting it? > >> > >> The dovecot IMAP server keeps its folder (mailbox) metadata as a > >> pseudo-message. When I access those mboxes locally with mutt, I see this > >> pseudo-message but I don't want to. > > > >That doesn't happen in Maildir storage. Is it reasonable to > >switch from mbox to maildir? > > An interesting idea! > > I have over 400 mboxes in my ~/Mail directory, some of them being > mailing list archives, others being Usenet groups archives, or mboxes > inherited from my decommissioned CommuniGate server. > > My dovecot configuration is simple: "mail_location = > mbox:~/Mail:INBOX=/var/mail/%u" > > If I knew how to convert all this stuff to Maildir storage... Do I have to > convert all of them at once? > > --
Re: Hide a message?
Dan Ritter wrote: Is there a way to hide a message (e.g. with a certain subject) from view in a mailbox, without actually deleting it? The dovecot IMAP server keeps its folder (mailbox) metadata as a pseudo-message. When I access those mboxes locally with mutt, I see this pseudo-message but I don't want to. That doesn't happen in Maildir storage. Is it reasonable to switch from mbox to maildir? An interesting idea! I have over 400 mboxes in my ~/Mail directory, some of them being mailing list archives, others being Usenet groups archives, or mboxes inherited from my decommissioned CommuniGate server. My dovecot configuration is simple: "mail_location = mbox:~/Mail:INBOX=/var/mail/%u" If I knew how to convert all this stuff to Maildir storage... Do I have to convert all of them at once? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On Thu, Dec 13, 2018 at 09:32:33PM +0700, Victor Sudakov wrote: > Thank you, Cameron, I'll probably use this solution. However, I would like > to have something like $score_threshold_hide alongside with > $score_threshold_delete and $score_threshold_read, but I see there is none. I suspect you could do this with a folder hook: folder-hook some-folder 'push ~n 100-200' where 100-200 is the "acceptable range score. Would that do? -F
Re: Hide a message?
Cameron Simpson wrote: Is there a way to hide a message (e.g. with a certain subject) from view in a mailbox, without actually deleting it? Limit to negated pattern does not work? E.g., to see all messages *except* those with 'mutt' in subject: ! ~s mutt It does work, but as I said in another mail, I use limiting interactively, so as soon as I limit the messages by some other criterion, the undesirable message will show. If your exclusion pattern is pretty fixed you can rewire the "l" macro. Support you want to ignore messages with "mutt" in the subject. Then: macro index l '! ~s mutt ' In this way when you want to use (l)imit the exclusion is always prepended to the pattern, so you can just type the extra condtions. Thank you, Cameron, I'll probably use this solution. However, I would like to have something like $score_threshold_hide alongside with $score_threshold_delete and $score_threshold_read, but I see there is none. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On 13Dec2018 09:29, Victor Sudakov wrote: Mihai Lazarescu wrote: On Wednesday, December 12, 2018 at 19:39:25 +0700, Victor Sudakov wrote: Is there a way to hide a message (e.g. with a certain subject) from view in a mailbox, without actually deleting it? Limit to negated pattern does not work? E.g., to see all messages *except* those with 'mutt' in subject: ! ~s mutt It does work, but as I said in another mail, I use limiting interactively, so as soon as I limit the messages by some other criterion, the undesirable message will show. If your exclusion pattern is pretty fixed you can rewire the "l" macro. Support you want to ignore messages with "mutt" in the subject. Then: macro index l '! ~s mutt ' In this way when you want to use (l)imit the exclusion is always prepended to the pattern, so you can just type the extra condtions. Cheers, Cameron Simpson
Re: Hide a message?
Claus Assmann wrote: Is there a way to hide a message (e.g. with a certain subject) from view in a mailbox, without actually deleting it? Maybe this works: show only messages matching a pattern Details can be found in the documentation. Well, I often use limiting to show only useful messages in a mailbox (e.g. ~f from a certain person only, or ~s by subject). But it has never occured to me to use it for showing all messages but one. Can scoring be used for hiding messages? I think not :-( -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN 2:5005/49@fidonet http://vas.tomsk.ru/
Re: Hide a message?
On Wed, Dec 12, 2018, Victor Sudakov wrote: > Is there a way to hide a message (e.g. with a certain subject) from view in > a mailbox, without actually deleting it? Maybe this works: show only messages matching a pattern Details can be found in the documentation.
