Re: Default mailbox display?
On Mon, Jan 22, 2001 at 12:37:09AM +0100, Axel Bichler wrote: Hi Dave! that's more constructive than a self-confessed "uppish tone". It would seem you've decided to do that so I don't really see a problem or a need for such a tone. On the other hand, meticulously insisting on an "It does what it says" point of view could be perceived as an "uppish tone", too. Then your perception would be wrong. I was simply pointing out that the current method wasn't unreliable because it did exactly what it says it does. Moreover, it's never given me any problems. IOW, I was reporting my experiences with it. I see no problem with that. I see nothing uppish about that either. I reported a fact and an experience. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
mutt and Maildir support
Basically just a very basic question: mutt can use Maildir type folders. But how can I tell procmail to sort my Mail into Maildir type folders instead of Mbox type folders? -- [EMAIL PROTECTED] System Engineerinnominate AG Diplom-Informatiker the linux architects tel: +49.30.308806-62 fax: -698 www.innominate.com PGP signature
Re: mutt and Maildir support
On Mon, Jan 22, 2001 at 11:38:25AM +0100, Ralf Hildebrandt wrote: Basically just a very basic question: mutt can use Maildir type folders. But how can I tell procmail to sort my Mail into Maildir type folders instead of Mbox type folders? There is a patch for procmail to deliver into a maildir. See http://www.qmail.org/ Another solution is to use maildrop, which has maildir delivery builtin, and, IMHO, is much easier to program... Maildrop is also available from the above URL... Best regards, -- Pedro Melo Cunha - [EMAIL PROTECTED] Novis - Dir. Rede - ISP - Infraes. Portal http://www.novis.pt/ Ed. Atrium Saldanha - Pa. Dq. Saldanha, 1 - 7 / 1050-094 Lisboa tel: +351 21 0104340 - Fax: +351 21 0104301
Re: mutt and Maildir support
Ralf Hildebrandt writes: Basically just a very basic question: You'll get a very basic answer, too :) mutt can use Maildir type folders. But how can I tell procmail to sort my Mail into Maildir type folders instead of Mbox type folders? man procmailrc. And you definitely want procmail 3.15 or newer.
Re: mutt and Maildir support
On Mon, Jan 22, 2001 at 10:49:56AM +, Pedro Melo wrote: There is a patch for procmail to deliver into a maildir. See http://www.qmail.org/ Might be. But Procmail-3.15.1 can do this without a patch. Isn't it great if an author accepts patches to his program... Another solution is to use maildrop, which has maildir delivery builtin, and, IMHO, is much easier to program... Maildrop is also available from the above URL... I use a recent postfix (delivers to MAILDIR anyway) and a recent procmail -- I don't need this. Basically I just want to know how this rule: :0 W: bounce.lock * ^From.*postmaster@ $MAILDIR/bounces looks for MAILDIR delivery instead of MBOX delivery. -- [EMAIL PROTECTED] System Engineerinnominate AG Diplom-Informatiker the linux architects tel: +49.30.308806-62 fax: -698 www.innominate.com PGP signature
Re: mutt and Maildir support
Might be. But Procmail-3.15.1 can do this without a patch. Isn't it great if an author accepts patches to his program... The procmail author hasn't been involved with the software in years!
Re: mutt and Maildir support
On Mon, Jan 22, 2001 at 12:04:35PM +0100, Ralf Hildebrandt wrote: :0 W: bounce.lock * ^From.*postmaster@ $MAILDIR/bounces looks for MAILDIR delivery instead of MBOX delivery. It's really as easy as postpending a "/" to the mailbox name: :0 W: bounce.lock * ^From.*postmaster@ $MAILDIR/bounces/ sorry for being such a nuisance... -- [EMAIL PROTECTED] System Engineerinnominate AG Diplom-Informatiker the linux architects tel: +49.30.308806-62 fax: -698 www.innominate.com PGP signature
Re: Default mailbox display? [partially solved]
first for the important part:
while reading the source to find a place to put Brandon Long's "folder
count" patch. i've found a configure switch named "--enable-buffy-size"
that seems to solve the detection issue. i only browsed through the
source since it was quite late, but it seems to read the end of the
mbox to find out if the last message is a new one. so it partially
scans the mbox file. i guess i can extend that to a full scan to
report real numbers.
but at least it partially solves the detection issue.
On Sun, Jan 21, 2001 at 08:07:58PM +, Dave Pearson wrote:
On Sun, Jan 21, 2001 at 06:44:54PM +0100, Heinrich Langos wrote:
On Sun, Jan 21, 2001 at 03:59:22PM +, Dave Pearson wrote:
[...]
Saving such information won't help you work out how many new mails there
are, or if there is new mail at all. It would let you know if the
mailbox had been modified in some way, which is pretty much what mutt
does right now.
nope ... right now mutt only shows that the mailbox has been accessed. not
if it has been modified.
It would appear that we have different definitions of "accessed" and
"modified". My copy of mutt shows me when an mbox has been modified, not
when it has been accessed.
do me a favor and check your "mutt -v" output. if it says
"+BUFFY_SIZE" than your mutt is not just checking access times but
much more than that. if it says "-BUFFY_SIZE" (like mine did) and
after grep-ing your mailbox still shows an "N", i don't get it.
grep doesn't modify your mbox.
so says strace:
open("/var/spool/mail/heinrich", O_RDONLY|0x8000) = 3
(though i have to admit i didn't find out what the 0x8000 part means
in a quick look at /usr/include/*)
BTW: is your mutt running 24/7 or do you start it anew in the morning
like i do... ( and several times a day whenever i've found a new
feature in mutt that i would like to try out ? :) )
right now a simple grep will screw up new mail detection.
try this:
$ echo blah | mail yourself@localhost
$ grep something /var/spool/mail/yourself
$ mutt -y
and you see no "N" ... pretty sad, isn't it?
No, I don't find it sad, I find it consistent with the documentation.
consistent? yes! i admit it is
consistent with a documentation that says: in some cases new mail
detection is not working as one would expect, because there is evil in
world and "Something is rotten in the state of Denmark" :-)
Obviously you're more than happy to find it an itch worth scratching, feel
free to scratch it. All I've been saying is that it *is* reliable, it does
exactly what it says it does. That it doesn't do what you'd like is a
different matter, I'm not commenting on that.
it's not only me who wants mutt to behave that way, i guess.
if it was not the intention to make mutt detect new mail it would say
"... the main menu status bar displays how any of these folders have
been modified since they where accessed by some programm." ;-)
i'm not saying that mutt should constantly scan the whole mailboxes or
anything like that. i just say it could do so on request. or on startup.
The problem with such a scan is that it could take ages. I've got a lot of
mailboxes, some of which can be huge.
it only scans mailboxes that are marked as incoming mailboxes.
so it would do the same thing it does, when opening that mbox. only to
all of them at once... ok ok .. that would be some overhead.
but it will not scan all your mailboxes. especially not those archive
like things where you keep several years of the kernel developers list
or bugtraq :-)
if you keep your incoming mboxes down to a month back or two, it
shouldn't be such a problem. and the results of scanning can be cached
(just in memory or in a status file) and only refreshed if the file
was modified.
with _you_ chosing your favorite or most reliable way you see fit to
detect modification. be it access/modification time, file size
or md5sum.
any volunteers to go for it? i have to finish a studies project before
i can go for more than a quick'n'dirty hack.
-heinrich
--
Heinrich Langos [EMAIL PROTECTED]
pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc
_
|o| The reason we come up with new versions is not to fix bugs. |o|
|o| It's absolutely not. It's the stupidest reason to buy a new |o|
|o| version I ever heard. -- Bill Gates, Microsoft Corporation |o|
~
Maildir and Lines
My mbox - maildir migration worked. As an (expected) side effect, NFS isn't causing problems anymore and detection of new mail works reliable. Life is sweet. Except for one thing: 12 010120 [EMAIL PROTECTED] (120) RE: [TDSC3D395D04] InterScan v3.5 for Solaris Problem 13 010121 Jan Brinkmann ( 26) Schn?ppchenjagd bei HIFICOMPONENTS.de 14 r 010122 Heinz Boeke ZI1 ( 0) Re: Possible_duplicate! 15 r 010122 Heinz Boeke ZI1 ( 0) mq the 5th column always indicated the number of lines in a mail. As you see, with my old mail in MAILDIR format, it works, but with newly arrived mail (the last two=, I always get a "( 0)" for the number of lines. Any ideas? -- [EMAIL PROTECTED] System Engineerinnominate AG Diplom-Informatiker the linux architects tel: +49.30.308806-62 fax: -698 www.innominate.com PGP signature
Re: German umlauts and alternates in Mutt.
* Wilhelm Wienemann [EMAIL PROTECTED] [19/01/01, 18:42:55]: Why didn't read you the answers to the same question from --- cut here - From: Jens Paulus [EMAIL PROTECTED] Subject: German umlauts and alternates in Mutt. To: [EMAIL PROTECTED] Date: Tue, 12 Dec 2000 18:29:00 +0100 X-Mailer: Mutt 1.0.1i --- cut here - Well, I'm going to put the Umlauts into the mutt newbie manual... it's RTFM soon ;) Kai -- Kai Blin Webmasterof http://www.uni-tuebingen.de/uni/thm/molgen/ Univ. of Tuebingen Inst. of Human Genetics fon +49-7071-2974890 Wilhelmstrasse 27 Dept. of Molecular Genetics fax +49-7071-295233 D-72074 Tuebingen Do molecular biologists wear designer genes?
Re: Default mailbox display? [partially solved]
On Mon, Jan 22, 2001 at 01:34:03PM +0100, Heinrich Langos wrote: On Sun, Jan 21, 2001 at 08:07:58PM +, Dave Pearson wrote: It would appear that we have different definitions of "accessed" and "modified". My copy of mutt shows me when an mbox has been modified, not when it has been accessed. do me a favor and check your "mutt -v" output. if it says "+BUFFY_SIZE" than your mutt is not just checking access times but much more than that. if it says "-BUFFY_SIZE" (like mine did) and after grep-ing your mailbox still shows an "N", i don't get it. I don't use the buffy feature. Neither have I ever said that an external access of a given mailbox won't cause mutt to fail to show the "N". I keep saying that it works as documented. BTW: is your mutt running 24/7 or do you start it anew in the morning like i do... ( and several times a day whenever i've found a new feature in mutt that i would like to try out ? :) ) 24/7. I also run other instances of mutt on an ad-hoc basis. it's not only me who wants mutt to behave that way, i guess. if it was not the intention to make mutt detect new mail it would say "... the main menu status bar displays how any of these folders have been modified since they where accessed by some programm." ;-) I agree that this can be viewed as a documentation problem. The problem with such a scan is that it could take ages. I've got a lot of mailboxes, some of which can be huge. it only scans mailboxes that are marked as incoming mailboxes. That's why I said "mailboxes". so it would do the same thing it does, when opening that mbox. only to all of them at once... ok ok .. that would be some overhead. That could and would be a *lot* of overhead. but it will not scan all your mailboxes. especially not those archive like things where you keep several years of the kernel developers list or bugtraq :-) I said "mailboxes", not archives. -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
IMAP + INBOX + mbox
Im using mutt for my mail agent, and am having problems with it since the 1.25 - 1.3 update. I am using it to view mail over IMAP, and in 1.2 versions the mail that was in my INBOX, and was read was then moved to my mbox folder, but with version 1.3 that doesn't happen anymore... could you please help me find out how to make it move the read mail? I have read the docs and have found nothing on this subject THX in advance! Bostjan -- Botjan Mller [NEONATUS], [EMAIL PROTECTED], http://neonatus.net/~neonatus For my PGP key finger: [EMAIL PROTECTED], RSA id: 0x90178DBD, ICQ #:7506644 Celular: +386(0)41243189, Powered by Debian GNU/LiNUX , Student of VFUL Tagline generated by 'gensig' mail-client-independent .signature generator. Get your copy at http://www.geeks.com/~robf/gensig/
Re: Maildir and Lines
On Mon, Jan 22, 2001 at 01:50:24PM +0100, Ralf Hildebrandt wrote: the 5th column always indicated the number of lines in a mail. As you see, with my old mail in MAILDIR format, it works, but with newly arrived mail (the last two=, I always get a "( 0)" for the number of lines. Ok. Ok. It's in the FAQ. Sorry. :) -- [EMAIL PROTECTED] System Engineerinnominate AG Diplom-Informatiker the linux architects tel: +49.30.308806-62 fax: -698 www.innominate.com PGP signature
Reliably detecting/counting new mail. WAS:[Re: Default mailbox display? [partially solved]]
On Mon, Jan 22, 2001 at 01:10:46PM +, Dave Pearson wrote: On Mon, Jan 22, 2001 at 01:34:03PM +0100, Heinrich Langos wrote: On Sun, Jan 21, 2001 at 08:07:58PM +, Dave Pearson wrote: [...] it's not only me who wants mutt to behave that way, i guess. if it was not the intention to make mutt detect new mail it would say "... the main menu status bar displays how any of these folders have been modified since they where accessed by some programm." ;-) I agree that this can be viewed as a documentation problem. In your opinion the documentation is wrong and should be changed to something like the above? Well, ok then I really misunderstood you all the time and I misunderstood the documentation. I'm sorry I wasted your time. I guess continuing this discussion will not get us anywhere then. Anyway I will continue this mail since I have some ideas that may improve the performance in case somebody, maybe me, wants to fix the non-existing problem :-) Dave, you may stop reading. The rest will only bother you and further waste your time. The problem with such a scan is that it could take ages. I've got a lot of mailboxes, some of which can be huge. it only scans mailboxes that are marked as incoming mailboxes. That's why I said "mailboxes". ok ok .. just wanted to make sure we talk about the same thing. i guess most users don't have huge mailboxes since mbox-hooks are a such a nice way to move older mail out of mailboxes after some time. anyway... so it would do the same thing it does, when opening that mbox. only to all of them at once... ok ok .. that would be some overhead. That could and would be a *lot* of overhead. realy? lets see... and keep in mind that this does not need to be mutts standard way to detect new mail. just the one it uses when you TAB TAB. or start mutt with -y. when you save modification date, filesize, known amount of new mail, and an md5sum they will only be generated once for each mailbox. so assuming that you don't add mailboxes on an hourly base I will forget about that one-time load. if a change occures (detecting may be done by modification time, filesize, md5sum (sorted accending by paranoia)) and the filesize increases you could assume that there is new mail (if it decreased you could mark that mailbox as "C" for changed or something like that and stop here). jump to the previously know end of the file and scan how may new mails arrived. that shouldn't be too much of a burden for a system. since mails usually don't arrive in large batches. (i know, fetchmail users will hate me.) to prevent errors due to other programms, maliciously changing your mailboxes and increasing its size, you could check for that. depending on your level of paranoia you could do anything. from A) checking if a new mail starts exactly where it is supposed to start (at the previously know file-end, which you do anyway by starting parsingthere) to Z) checksumming the mailbox up to the last known fileend and comparing with the saved checksum. assuming that increased size usually means that new mail has been added the overhead would be very small. if you still think it is too much overhead go for this one: cache the information that you gathered during those scans to skip the initial scan that mutt does when you enter a folder. this will reduce the overhead to almost zero. only if you don't read the folder that has new mail you will have wasted time. but why do you get that mail at all if you dont read it ? :-) for maildir environments the solution seems straightforward. what about imap? i don't have a clue. could somebody enlighten me? -heinrich -- Heinrich Langos [EMAIL PROTECTED] pgp: http://wh9.tu-dresden.de/~heinrich/pub_pgp_key.asc _ |o| The reason we come up with new versions is not to fix bugs. |o| |o| It's absolutely not. It's the stupidest reason to buy a new |o| |o| version I ever heard. -- Bill Gates, Microsoft Corporation |o| ~
Re: Reliably detecting/counting new mail. WAS:[Re: Default mailbox display? [partially solved]]
On Mon, Jan 22, 2001 at 04:16:25PM +0100, Heinrich Langos wrote: Dave, you may stop reading. The rest will only bother you and further waste your time. With an attitude like that it's not surprising that you're confused about what I've been saying. Read what I've actually said, look for the reasonable reason this time, then you might find that I've said nothing against the idea of providing the feature you'd like to see. IOW, try being less insulting and use a little more comprehension. That's why I said "mailboxes". ok ok .. just wanted to make sure we talk about the same thing. i guess most users don't have huge mailboxes since mbox-hooks are a such a nice way to move older mail out of mailboxes after some time. anyway... But we can't actually make such a guess can we? You also seem to be under the impression that I don't archive older mail. I do. Arguing that "most users" do what you'd like them to do doesn't detract from the point that there can and will be large mailboxes defined by the mailbox command. When designing new features it makes sense to work to the extreme case, not the average case (especially when you can't really know what the average is). if a change occures (detecting may be done by modification time, filesize, md5sum (sorted accending by paranoia)) and the filesize increases you could assume that there is new mail (if it decreased you could mark that mailbox as "C" for changed or something like that and stop here). Note that an increase in size might be a reduction in the number of actual emails. I might have deleted a load but saved one large email from somewhere else to the mailbox in question. IOW, an increase in size can't be assumed to be new mail. jump to the previously know end of the file and scan how may new mails arrived. that shouldn't be too much of a burden for a system. since mails usually don't arrive in large batches. (i know, fetchmail users will hate me.) I don't use fetchmail but the above still isn't true. email does arrive in large batches for me. to prevent errors due to other programms, maliciously changing your mailboxes and increasing its size, you could check for that. depending on your level of paranoia you could do anything. from A) checking if a new mail starts exactly where it is supposed to start (at the previously know file-end, which you do anyway by starting parsingthere) That sounds like a good solution for the problem I highlight above. PS: You still appear to have a configuration problem with your copy of mutt: , | Mail-Followup-To: heinrich, [EMAIL PROTECTED] ` -- Dave Pearson: | mutt.octet.filter - autoview octet-streams http://www.davep.org/ | mutt.vcard.filter - autoview simple vcards Mutt: | muttrc2html - muttrc - HTML utility http://www.davep.org/mutt/ | muttrc.sl - Jed muttrc mode
Re: Default mailbox display?
Daniel -- ...and then Daniel Freedman said... % % My mutt is now at 1.0.1i, and I'll try to convince the sysadmin to % upgrade to 1.25. Could this version difference affect my not seeing Well, you could always grab the source and build it yourself; the only special program is mutt_dotlock, and I believe that was around for 1.0... % new mail marked, or maybe it's still present in the current release? % Am i correct to guess AFS? Any other suggestions are much % appreciated. I dunno from AFS; sorry. % % Thanks so much, HTH HAND % % Daniel % :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! PGP signature
Re: IMAP: marking messages for deletion
On Friday, 19 January 2001 at 13:05, Brian J. Murrell wrote: On Fri, Jan 19, 2001 at 07:07:19PM -, [EMAIL PROTECTED] wrote: --- In [EMAIL PROTECTED], Nils Vogels [EMAIL PROTECTED] wrote: Hi Brian J. Murrell ! Hi Nils, I am not 100% sure, but wouldn't the sync-mailbox (by default binded to '$') take care of that ? Not really. What I want to do is *mark* a message deleted but not actually purge (EXPUNGE in IMAP parlance) it from the mailbox. I want this not only for survival of a Mutt session (start mutt, mark messages deleted, quit, restart mutt and it be remembered -- using IMAP mechanisms) but I want others in a shared folder to see the deletes as they happen. Well, if you sync but don't say yes to the "purge deleted messages?" question, you should get the effect you're looking for. PGP signature
