Carlos E. R. said the following on 08/26/2013 01:57 PM:
El 2013-08-26 a las 11:26 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 08/26/2013 10:54 AM:
Maildir, to my knowledge, is only more efficient when you do many inserts and deletes. And frankly, with good clients like Pine I don't even notice it.
I fail to understand why you would want to modify mail messages once they have been stored. I can understand the modification of the headers as they pass though relays, though spam detectors and the like, but once they hit storage .... why? Do you really want to modify what people have said? I don't understand that.
No, not that.
It is removal of a complete post, because you do not want to keep it, or because you move it to another folder.
Ah. So you think its done like in VI where the lines are removed from the middle of the file? I think not. I think that its done by a copy-and-skip. In VI the file is buffered and the lines are taken out of the buffer and then the remainder is written out as if it were a new file. Something like that. Certainly with IMAP that all doesn't get done until you tell the IMAP server to 'compact".
It is possible to want to add an email in the middle of the "list" (because it is sorted). Yes, normally the clients will do the sorting just fine without that.
I'm not sure about that. Personally, without looking at the source, I think the MUAs do the sorting at the presentation. How else can threading work? I don't think that a change in the sort order in Thunderbird causes a change in the order of the messages in the mbox. If a new message appears with a header saying it was sourced at a time 'in the middle' then it gets appended and its up to the MUA to display it in the 'correct' position. It doesn't get inserted in the 'correct' position in the file. That concept is meaningless since it all depends on how you choose to sort, and any reasonable MUA will have many sort options. q.v.
Although I do not know of a client that does it, I would like to have a client that would allow adding a comment header (and display it by default), where I could write why that post interests me - very useful for the relatively few list emails I archive; often for something they say different that what the subject line says.
Since the index files and the 'metadata' used by something like Dovecot is outside of the mbox file there is no reason why not. We're quite used to directories having a .directory file to be used by Dolphin or the like, sure, why not. I recall one file manager that allowed 'ratings' by use of icons to be attached to each file icon that was displayed - can't recall its name.
Pine, for instance, changes one header to mark that an email has been read, or that it is important, and it does that very fast. I don't know exactly what it changes. In fact, dovecot does the same change, because I can see an email directly with pine or via dovecot, and the flags are correct on both. Ie, both Pine and dovecot use the same flags on mbox.
I *think* this is a case of altering the header inside the file when the mbox is closed. I'm sure that can easily be tested.
Another alledged problem of mbox is concurrent ussage (like fetchmail adding an email, while the client does something else. In practice, I have never hit such a problem in 15 years.
Same here, but make that much longer. The 'problem' of adding incoming to a mailbox while reading it is not new, it dates back to the late 70s. Concurrent access for read has never been a problem with UNIX; concurrent access for write is a logical problem not confined to UNIX. But the mbox format has used sentinel flags and all mail appreciations seem to obey that simple protocol. In absolute terms appending to a file isn't going to upset another process that is simply reading from the file. In reality, the MUA will 'see' (or be notified) that the file size has increased and re-scan for new headers. How efficiently it does that depends on whether or not you allow the MUA to modify the other mail messages.
In truth, MsDos was more advanced in this respect. When the 'share.exe' additions were loaded, you could lock a section of a file for writing while reading or even writing to another section of the same file.
You can now; but we had email on V6 and V7 UNIX which didn't have the ability to lock sections of files as we do now. Sentinel flags did the job just so long as the parties obeyed the protocol. Sometimes with NFS that was difficult.
Using another file as lock flag is, IMHO, a kludge, and may be ignored by software (the lock not enforced by the kernel).
Yes, all parties have to obey that agreed protocol. Mandatory control is better, but we didn't have it in V6/V7 days.
One reason to use Dovecot and IMAP is that the MUA - Thunderbird, KDE-Mail, whatever - relies on Dovecot to tell it what is going on. Dovecot maintains metadata about the mail box. It can modify the metadata DB without having to modify the mbox itself. It keeps indexes on the mbox and they are 'cleaner' than the MUA/thunderbird (etc) might.
True.
Although here I have a problem there, because I still use procmail to write directly to folders. Dovecot copes with this, but I owuld like to instead (using procmail) send that email to dovecot.
My incoming mail is dragged in by fetchmail, passed to procmail and put in folders using the locking protocol procmail supports. Dovecot is *NOT* a mail transfer agent, it is a IMAP/POP server. You don't 'send' email to dovecot. Dovecot is smart enough that when it sees a mbox or directory change it rescans and reindexes. One reason I have a lot of smaller folders rather than one big INBOX :-) Oops! googling I see that dovecot does have a local delivery agent - lda. http://wiki.dovecot.org/LDA It seems you need it to do filtering. I'm doing my filtering with procmail (as I have for a few decades ...) so I don't use the LDA. My .forward sends incoming email to procmail. The dovecot lda methods sends it to "/usr/local/libexec/dovecot/deliver". I gather that its an either/or situation. I'm sure you could kludge procmail to pipe though dovecot's filters, but what make it that complicated: do one or the other. That's fine, but I'll stick with what I know works until I have a need to change. -- When nothing is sure, everything is possible. - Margaret Drabble -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org