Re: NNTP reader?
On Mon, Oct 03, 2011 at 02:33:45PM +, Grant Edwards wrote: > On 2011-09-30, Aaron Toponce wrote: > > On 09/29/2011 06:17 AM, Leonardo M. Ram? wrote: > >> Hi, does anyone knows if it can be possible to read/subscribe to newsgroups > >> (nntp) with mutt?. > > > > Mutt is just an MUA, and attempts to extend it into anything more than > > that (RSS reader, NNTP reader, etc.) are silly IMO. If you must > > absolutely have NNTP and mail, then Mutt isn't for you. I would > > recommend using Gnus (http://gnus.org). > > Many mutt users find slrn to be sufficiently "mutt-like" that they > decide to forget about trying to pound the mutt peg into the nntp > hole. > Personally I use tin rather than slrn as it seems to fit my 'mutt mind' better. -- Chris Green
Re: Improve mutt search: how?
On Sun, Aug 14, 2011 at 12:24:49PM -0300, Marcelo Luiz de Laia wrote: > Mutt have a search function, / , the is very simple. But, it do search > only in the to: and subject: fields. > > Are ther a way to do search in all field (to:, subject:, body, etc) of > messages? > Yes, there's a set of ~ parameters that allows you to specify where to search after entering /. There's a whole set of them all documented in the mutt documentation. To search in the body it's /, then at the prompt ~b -- Chris Green
Re: Moving IMAP directories about with mutt - is it easy? How to do it?
On Wed, Jul 06, 2011 at 02:04:56AM -0700, William Yardley wrote: > On Wed, Jul 06, 2011 at 10:56:13AM +0200, Michael Tatge wrote: > > > * On Tue, Jul 05, 2011 05:58PM +0100 Chris G (c...@isbd.net) muttered: > > > As a result I need to move some IMAP mail from some local backups > > > (copies made just before the move) to the new IMAP server. How do I > > > do this so that the directory structure is preserved? > > > > Your best bet is a gui client :) > > Maybe UW's 'mailutil' program (which ships with (al)pine) would help? > It's sometimes handy for transferring mail from between different IMAP > servers, IMAP and local spool files, etc. > Possibly, thanks, I've used that in the distant past. -- Chris Green
Re: Moving IMAP directories about with mutt - is it easy? How to do it?
On Wed, Jul 06, 2011 at 10:56:13AM +0200, Michael Tatge wrote: > * On Tue, Jul 05, 2011 05:58PM +0100 Chris G (c...@isbd.net) muttered: > > As a result I need to move some IMAP mail from some local backups > > (copies made just before the move) to the new IMAP server. How do I do > > this so that the directory structure is preserved? > > Your best bet is a gui client :) > Which probably can't read the local file system maildir mailboxes. -- Chris Green
Moving IMAP directories about with mutt - is it easy? How to do it?
I have recently moved my mail hosting, not from one ISP to another but from one platform to another. As a result I need to move some IMAP mail from some local backups (copies made just before the move) to the new IMAP server. How do I do this so that the directory structure is preserved? To be specific I want to use mutt to copy some E-Mails from local maildir files (they look like Courier IMAP ones) to a remote IMAP server. -- Chris Green
Re: rsync removes the "N" from mailboxes with new mail
On Sat, Mar 12, 2011 at 07:00:46PM -0500, Nathan Stratton Treadway wrote: > On Fri, Mar 11, 2011 at 14:17:49 -0600, Derek Martin wrote: > > $ stat rsyncfrom/* > > File: `rsyncfrom/bar' > > Size: 0 Blocks: 0 IO Block: 4096 regular empty file > > Device: 805h/2053d Inode: 41984 Links: 1 > > Access: (0644/-rw-r--r--) Uid: (24574/demartin) Gid: ( 600/ staff) > > Access: 2011-03-08 15:45:52.0 -0500 > > Modify: 2011-03-08 15:45:52.0 -0500 > > Change: 2011-03-08 15:45:52.0 -0500 > [...] > > > > HOWEVER, NONE OF THE TIMES OF THE SOURCE FILES HAVE BEEN UPDATED. > > Like John, in my tests rsync both with and without "-t" updates the > access time of the original file (see session log below) > Yes, I think (as one would expect from what the rsync man page says) that rsync doesn't *intentionally* do anything clever with the access time. Either it always changes it or it never changes it and the -t option doesn't make any difference. As suggested it's probably the presence or otherwise of the noatime option in fstab that makes the difference. -- Chris Green
Re: rsync removes the "N" from mailboxes with new mail
On Fri, Mar 11, 2011 at 02:17:49PM -0600, Derek Martin wrote: > On Fri, Mar 11, 2011 at 05:50:34PM +0000, Chris G wrote: > > On Tue, Mar 08, 2011 at 02:40:06PM -0800, John Magolske wrote: > > > I'd like the original (source) mailboxes to retain their N's, I'm not > > > concerned about copying over this to the backup copy. > > > > > That's because rsync is changing the *access* time of the 'source' > > mailboxes isn't it, I'm not sure you can stop it doing this. > > YOU ABSOLUTELY CAN, by using rsync -t as I've said several times now. > [snip] > So, as I've already said several times now, rsync -t absolutely is the > solution. > I just did some tests too, rsync doesn't change the access time even without using -t as far as I can tell. I have a python script called lt that shows all three times associated with a file, so:- chris$ lt again.rtf Times for file again.rtf 2010-04-27 18:31:35.00 Modifed 2010-11-24 09:03:51.00 Accessed 2010-04-27 18:31:35.00 Status changed chris$ rsync -t again.rtf /tmp/again.rtf chris$ lt /tmp/again.rtf Times for file /tmp/again.rtf 2010-04-27 18:31:35.00 Modifed 2011-03-12 18:27:16.00 Accessed 2011-03-12 18:27:16.73 Status changed So, rsync -t leaves the original file's access time unchanged and copies the modification time to the destination. chris$ rsync again.rtf /tmp/again.rts chris$ lt again.rtf Times for file again.rtf 2010-04-27 18:31:35.00 Modifed 2010-11-24 09:03:51.00 Accessed 2010-04-27 18:31:35.00 Status changed chris$ lt /tmp/again.rtf Times for file /tmp/again.rtf 2010-04-27 18:31:35.00 Modifed 2011-03-12 18:27:16.00 Accessed 2011-03-12 18:27:16.73 Status changed ... and without the -t rsync *doesn't* copy the modification time to the destination but *still* leaves the access time of the original unchanged. -- Chris Green
Re: rsync removes the "N" from mailboxes with new mail
On Tue, Mar 08, 2011 at 02:40:06PM -0800, John Magolske wrote: > * Chris G [110308 14:30]: > > On Tue, Mar 08, 2011 at 02:50:26PM -0600, Derek Martin wrote: > > > On Tue, Mar 08, 2011 at 06:29:47PM +, Chris G wrote: > > > > On Tue, Mar 08, 2011 at 10:54:23AM -0600, Derek Martin wrote: > > > > > On Mon, Mar 07, 2011 at 03:37:45PM -0800, John Magolske wrote: > > > > > > After doing an rsync backup, the "N" preceding mailboxes with new > > > > > > mail > > > > > > is removed from all mailboxes. I suppose this is a result of the > > > > > > mbox > > > > > > files being touched somehow by the rsync process. Is there any way > > > > > > to > > > > > > prevent this? > > > > > > > > > > Use rsync -t. This preserves the file modification times on the > > > > > mailboxes. Note that it may be possible that there will be a race > > > > > condition causing mail folders which have mail delivered during the > > > > > rsync to not show new mail. If this happens at all, it will most > > > > > likely be pretty rare (i.e. it will still be much better than losing > > > > > the N flag on *all* mailboxes every time). > > > > > > > > > Surely "rsync -t" means *copy* the modification time to the destination, > > > > what the OP wants is to preserve the modification and access times of > > > > the source files being copied (I think). > > > > > > Surely you are mistaken. :) > > > > > In what the "rsync -t" means or in what the OP wanted? :-) > > > > OP, tell us what you want, do you want the *original* mailboxes to be > > 'N' still or do you want the copies to have the 'N'? > > I'd like the original (source) mailboxes to retain their N's, I'm not > concerned about copying over this to the backup copy. > That's because rsync is changing the *access* time of the 'source' mailboxes isn't it, I'm not sure you can stop it doing this. -- Chris Green
Re: rsync removes the "N" from mailboxes with new mail
On Tue, Mar 08, 2011 at 03:26:41PM -0600, Derek Martin wrote: > On Tue, Mar 08, 2011 at 09:11:59PM +0000, Chris G wrote: > > On Tue, Mar 08, 2011 at 02:50:26PM -0600, Derek Martin wrote: > > > On Tue, Mar 08, 2011 at 06:29:47PM +, Chris G wrote: > > > > On Tue, Mar 08, 2011 at 10:54:23AM -0600, Derek Martin wrote: > > > > > On Mon, Mar 07, 2011 at 03:37:45PM -0800, John Magolske wrote: > > > > > > After doing an rsync backup, the "N" preceding mailboxes with new > > > > > > mail > > > > > > is removed from all mailboxes. I suppose this is a result of the > > > > > > mbox > > > > > > files being touched somehow by the rsync process. Is there any way > > > > > > to > > > > > > prevent this? > > > > > > > > > > Use rsync -t. This preserves the file modification times on the > > > > > mailboxes. Note that it may be possible that there will be a race > > > > > condition causing mail folders which have mail delivered during the > > > > > rsync to not show new mail. If this happens at all, it will most > > > > > likely be pretty rare (i.e. it will still be much better than losing > > > > > the N flag on *all* mailboxes every time). > > > > > > > > > Surely "rsync -t" means *copy* the modification time to the destination, > > > > what the OP wants is to preserve the modification and access times of > > > > the source files being copied (I think). > > > > > > Surely you are mistaken. :) > > > > > In what the "rsync -t" means or in what the OP wanted? :-) > > The former. It does what I said, and (at least when the destination > is local and you do not specify an alternative program to use) does > *not* do what you said, though I admit, it seems like it ought to, or > that there should be two separate flags that control access time > preservation for each source and destination files. If you don't > believe me, try it... then run stat on all the files you copied. > I did. > Er, surely copying a file won't change the modification time of the copied file anyway will it? -- Chris Green
Re: rsync removes the "N" from mailboxes with new mail
On Tue, Mar 08, 2011 at 02:50:26PM -0600, Derek Martin wrote: > On Tue, Mar 08, 2011 at 06:29:47PM +0000, Chris G wrote: > > On Tue, Mar 08, 2011 at 10:54:23AM -0600, Derek Martin wrote: > > > On Mon, Mar 07, 2011 at 03:37:45PM -0800, John Magolske wrote: > > > > After doing an rsync backup, the "N" preceding mailboxes with new mail > > > > is removed from all mailboxes. I suppose this is a result of the mbox > > > > files being touched somehow by the rsync process. Is there any way to > > > > prevent this? > > > > > > Use rsync -t. This preserves the file modification times on the > > > mailboxes. Note that it may be possible that there will be a race > > > condition causing mail folders which have mail delivered during the > > > rsync to not show new mail. If this happens at all, it will most > > > likely be pretty rare (i.e. it will still be much better than losing > > > the N flag on *all* mailboxes every time). > > > > > Surely "rsync -t" means *copy* the modification time to the destination, > > what the OP wants is to preserve the modification and access times of > > the source files being copied (I think). > > Surely you are mistaken. :) > In what the "rsync -t" means or in what the OP wanted? :-) OP, tell us what you want, do you want the *original* mailboxes to be 'N' still or do you want the copies to have the 'N'? -- Chris Green
Re: rsync removes the "N" from mailboxes with new mail
On Tue, Mar 08, 2011 at 10:54:23AM -0600, Derek Martin wrote: > On Mon, Mar 07, 2011 at 03:37:45PM -0800, John Magolske wrote: > > After doing an rsync backup, the "N" preceding mailboxes with new mail > > is removed from all mailboxes. I suppose this is a result of the mbox > > files being touched somehow by the rsync process. Is there any way to > > prevent this? > > Use rsync -t. This preserves the file modification times on the > mailboxes. Note that it may be possible that there will be a race > condition causing mail folders which have mail delivered during the > rsync to not show new mail. If this happens at all, it will most > likely be pretty rare (i.e. it will still be much better than losing > the N flag on *all* mailboxes every time). > Surely "rsync -t" means *copy* the modification time to the destination, what the OP wants is to preserve the modification and access times of the source files being copied (I think). -- Chris Green
Re: strange content-types of attachments
On Wed, Feb 09, 2011 at 03:54:29PM -0500, Ed Blackman wrote: > On Wed, Feb 09, 2011 at 08:26:03PM +0000, Chris G wrote: > >On Wed, Feb 09, 2011 at 01:49:33PM -0500, Ed Blackman wrote: > >>You can tell Mutt to use RFC2047 decoding on MIME file names with > >> set rfc2047_parameters=yes > >> > >Would that be in addition to the 'normal' decoding which works with most > >attachments? I.e. would everything that worked before continue to work > >correctly? > > Yes. The only thing that might break (and I'm not even sure it > would) is if someone sent you a file actually named something like > "=?blah?Q?foo?". In other words, a legitimate file name that > *looks* like it's RFC2047 encoded, but actually isn't. > > In practice, most people don't send files with weird names like > that, and there's a large set of people who use non-compliant user > agents that send files with RFC2047 encoded names. > OK, thanks for all the information. -- Chris Green
Re: strange content-types of attachments
On Wed, Feb 09, 2011 at 01:49:33PM -0500, Ed Blackman wrote: > On Wed, Feb 09, 2011 at 11:06:52AM +0000, Chris G wrote: > >I had something *vaguely* similar yesterday, a supplier sent me a note > >about an order I had placed and it was:- > > > > [-- application/octet-stream is unsupported (use 'v' to view this part) > > --] > > > >... which is OK[ish], but the file name was:- > > > > =?iso-8859-1?B?SU9TVF9DU0gyMTA1MjAucGRm? > > > >It was actually a PDF. Why they couldn't just reply to my E-Mail I > >don't know. > > That is a RFC2047 encoding of "IOST_CSH210520.pdf". RFC 2047 > *explicitly* says not to use RFC 2047 decoding on file name > parameters. > > Unfortunately, some commonly used mail user agents ignore that > section and send file names encoded that way instead of using the > correct way specified in RFC 2231. > > You can tell Mutt to use RFC2047 decoding on MIME file names with > set rfc2047_parameters=yes > Would that be in addition to the 'normal' decoding which works with most attachments? I.e. would everything that worked before continue to work correctly? > I've argued before that Mutt should make that the default. > -- Chris Green
Re: strange content-types of attachments
On Wed, Feb 09, 2011 at 09:04:34AM +0100, Jan-Herbert Damm wrote: > hello all, > > please skip this mail and excuse the noise if you hate slightly OT posts. > > I recently got attachments which were really pdfs but couldn't be detected as > such because they had strange content-type names: > > application/x-coremedia-dynamic > application/force-download > > I wrote .mailcap-entries so that they get displayed but i couldn't find out > where these names come from. Coremedia seems to be some marketing company and > force-download.com is an ugly site that I couldn't make sense of. > > How come some people trying to attach pdfs (presumably via a webmail client) > get these strange content-type entries and what might be the benefit? > > (My first paranoic thought is allways "mafia".) > I had something *vaguely* similar yesterday, a supplier sent me a note about an order I had placed and it was:- [-- application/octet-stream is unsupported (use 'v' to view this part) --] ... which is OK[ish], but the file name was:- =?iso-8859-1?B?SU9TVF9DU0gyMTA1MjAucGRm? It was actually a PDF. Why they couldn't just reply to my E-Mail I don't know. -- Chris Green
Re: Can I force mutt to scan for new messages (as opposed to written mbox files)?
On Tue, Dec 28, 2010 at 10:45:40AM -0600, Derek Martin wrote: > On Tue, Dec 28, 2010 at 04:29:24PM +0000, Chris G wrote: > > > However when I come to read mail in the morning the incoming E-Mail has > > > been accessed by my backup system and the above mechanism doesn't work. > > > I know one way to solve the problem would be to make the backup system a > > > bit cleverer but that's rather difficult at the moment. > > That's the best solution, and depending on the exact nature of "rather > difficult" I'd suggest you pursue that. If you really just can't, > then the alternative that's most likely to work for you is to set > $check_mbox_size. I seem to recall that this is also not without its > problems, though other than the obvious case of the mbox changing > in such a way that its size does not. But if there were other > problems, I can't recall what they were... > I'll take a look, it may be possible but it does seem a bit of a difficult way to do something essentially simple. > > > If I look in the individual mbox files the new mail *is* actually marked > > > as N[ew] by the mail delivery program. So, is there a way to get mutt > > > to scan the mbox files in my mailboxes list and flag up which ones have > > > new mail? ... and is the only reason for not doing this by default that > > > it would be slow? > > > > No answers? Is that because this is a really silly question or what? > > > > What I want is a means to ask mutt to scan the individual messages in > > each mbox file in the mailboxes list to look for messages which have 'N' > > in the Status: header. > > FWIW, most mail systems, AFAIK, don't actually deliver mail with a > 'N' in the Status header. Rather, they deliver the mail with no > status header at all. The status header usually only contains 'N' if > the user's mailer added it after the user actually read the mail, and > told the mailer it wanted the message to be treated as new. > My 'mail delivery system' is Postfix plus a Python script that does filtering, I think it must be Postfix that's adding the Status: header as I can't see how my Python script can possibly be doing it. > Regardless, Mutt lacks this feature. The historical reason is that > for large mailboxes, it's slow. I've argued for years that a) this is > mostly not true on any reasonable hardware, and b) so what if it is? > It's the only way to do new mail detection *properly*, and if that's > what the user wants, it should be possible to ask for it. > > Of course, someone would need to write the code... > I quite agree! :-) -- Chris Green
Re: Can I force mutt to scan for new messages (as opposed to written mbox files)?
On Sun, Dec 26, 2010 at 11:58:27AM +, Chris G wrote: > Is there any way I can force mutt to scan all files in 'mailboxes' for > new mail? > > In general during the day everything works fine, new mail is detected in > the normal way by seeing if the access time is before the modified time. > > However when I come to read mail in the morning the incoming E-Mail has > been accessed by my backup system and the above mechanism doesn't work. > I know one way to solve the problem would be to make the backup system a > bit cleverer but that's rather difficult at the moment. > > If I look in the individual mbox files the new mail *is* actually marked > as N[ew] by the mail delivery program. So, is there a way to get mutt > to scan the mbox files in my mailboxes list and flag up which ones have > new mail? ... and is the only reason for not doing this by default that > it would be slow? > No answers? Is that because this is a really silly question or what? What I want is a means to ask mutt to scan the individual messages in each mbox file in the mailboxes list to look for messages which have 'N' in the Status: header. Since my mail is delivered to the local hard disk it'll be quite fast enough. -- Chris Green
Can I force mutt to scan for new messages (as opposed to written mbox files)?
Is there any way I can force mutt to scan all files in 'mailboxes' for new mail? In general during the day everything works fine, new mail is detected in the normal way by seeing if the access time is before the modified time. However when I come to read mail in the morning the incoming E-Mail has been accessed by my backup system and the above mechanism doesn't work. I know one way to solve the problem would be to make the backup system a bit cleverer but that's rather difficult at the moment. If I look in the individual mbox files the new mail *is* actually marked as N[ew] by the mail delivery program. So, is there a way to get mutt to scan the mbox files in my mailboxes list and flag up which ones have new mail? ... and is the only reason for not doing this by default that it would be slow? -- Chris Green
Re: unicode
On Mon, Nov 29, 2010 at 11:38:43AM +, Jamie Paul Griffin wrote: > > Setting a ISO-8859 locale will mostly work but it's not so all > > encompassing as using UTF-8 so if you can use UTF-8 it's better. > > ISO-8859 character sets are basically only the 'Roman' character sets of > > western[ish] Europe. Using UTF-8 will show almost anything, I get to > > see chinese spam in all its chinese glory sometimes! :-) > > Out of interest Chris, do you use FreeBSD? I only ask because oddly enough i > had better results using the ISO character sets than with UTF-8. I don't > fully understand why and perhaps it's a BSD issue/thing. With my OpenBSD > system i have even more trouble getting unicode characters to display > properly. > No I don't, I use Linux (Xubuntu). I only moved from ISO-8859 to UTF-8 a little while ago though, mainly because until a year or two go I did a lot of work on legacy Sun systems which, as regards characters sets etc. were back in the dark ages and for cross compatibility with them ISO-8859 made things easier. My basic needs are really only western European character sets (I do actually read and write news and E-Mail in French as well as English and read, rarely, Polish) so ISO-8859 does most of what I want. I just found that so much software is now defaulting to UTF-8 that it was easier to go with that now that I don't have to deal with ancient Sun systems. -- Chris Green
Re: unicode
On Mon, Nov 29, 2010 at 10:58:12AM +, Jamie Paul Griffin wrote: > On Sun, Nov 28, 2010 at 02:52:22PM -0800, Chip Camden wrote: > > Someone must have solved this problem before, but all the Googling in the > > world isn't helping me so far. > > on my FreeBSD system, which i believe you are using, i managed to get it to > display these characters by setting the locale as Derek pointed out; but, the > values i used for $LANG and $MM_CHARSET are en_GB.ISO8859-1 and ISO-8859-1 > respectively. This is on the FreeBSD web faq/manual i believe where it > explains about localisation. You shouldn't need to set any of the other > locale values - at least i didn't need to but i'm no expert. > Setting a ISO-8859 locale will mostly work but it's not so all encompassing as using UTF-8 so if you can use UTF-8 it's better. ISO-8859 character sets are basically only the 'Roman' character sets of western[ish] Europe. Using UTF-8 will show almost anything, I get to see chinese spam in all its chinese glory sometimes! :-) -- Chris Green
Re: See some html's messages in external browser
On Sat, Nov 27, 2010 at 04:47:26PM +0100, Arele wrote: > Hi. > I would like to view some html's messages in external browser like > iceweasel/firefox, opera,... > I have configured to see the html message with w3m or links2 but > sometimes I would like to view all the message in graphical browser. > Well, at this time urlview don't work like I want because sometimes I > receive some messages who has not links to extract. > What hook or trick can I use? I do the following:- In my muttrc file I have:- auto_view text/html In my .mailcap I have:- text/html; /usr/bin/firefox %s text/html; links -dump %s -html-numbered-links 1; copiousoutput; nametemplate=%s.html This means that HTML E-Mails are automatically shown within mutt as text by links (obviously you can use lynx, w3m or whatever). Then if I want to view the E-Mail in a GUI browser I v[iew] the message and hit return against the .html version to pop the message up in firefox (again you can obviously select whatever GUI browser you want). I believe it's the 'copiousoutput' that's necessary to make it work like this. -- Chris Green
Re: Is there any way to prevent the *ll-oo-nn-gg* wait while mutt checks a PGP signature?
On Sat, Nov 27, 2010 at 11:05:40AM +0800, Charles Jie wrote: > There is a parameter to turn off the auto-verifying, isn't there? > > #unset pgp_verify_sig # automatically verify message signatures > (yes) > > Just uncomment this line (if not, add it). > That sounds like a sensible solution, thanks. > best regards, > charlie > > > On Fri, Nov 26, 2010 at 08:50:15PM +, Chris G wrote: > > On Fri, Nov 26, 2010 at 03:35:20PM -0500, Nathan Stratton Treadway wrote: > > > On Fri, Nov 26, 2010 at 19:56:13 +, Chris G wrote: > > > > Sitting for tens of seconds while mutt retrieves a key from a web site > > > > is just silly. > > > > > > > > Is there a way to turn this off while still allowing me to send (using > > > > 'p') signed messages? > > > > > > I haven't paid a lot of attention to the Mutt side of configuring GPG > > > operation recently (since the setup that I put in place years ago has > > > been doing what I need), but off hand it sounds like you may be able to > > > do what you would like by commenting out the "keyserver" line in the > > > $HOME/.gnupg/gpg.conf file. > > > > > > Once you do that, GPG won't try to automatically download keys for new > > > correspondents when checking signatures (it will instead give just you > > > a warning that the signature could not be verified), but it shouldn't > > > change the way it signs your outgoing messages... > > > > > Thanks, I've done that (commenting out the keyserver line), we'll see if > > it works! :-) > > > > -- > > Chris Green -- Chris Green
Re: Is there any way to prevent the *ll-oo-nn-gg* wait while mutt checks a PGP signature?
On Fri, Nov 26, 2010 at 03:35:20PM -0500, Nathan Stratton Treadway wrote: > On Fri, Nov 26, 2010 at 19:56:13 +0000, Chris G wrote: > > Sitting for tens of seconds while mutt retrieves a key from a web site > > is just silly. > > > > Is there a way to turn this off while still allowing me to send (using > > 'p') signed messages? > > I haven't paid a lot of attention to the Mutt side of configuring GPG > operation recently (since the setup that I put in place years ago has > been doing what I need), but off hand it sounds like you may be able to > do what you would like by commenting out the "keyserver" line in the > $HOME/.gnupg/gpg.conf file. > > Once you do that, GPG won't try to automatically download keys for new > correspondents when checking signatures (it will instead give just you > a warning that the signature could not be verified), but it shouldn't > change the way it signs your outgoing messages... > Thanks, I've done that (commenting out the keyserver line), we'll see if it works! :-) -- Chris Green
Is there any way to prevent the *ll-oo-nn-gg* wait while mutt checks a PGP signature?
Now that I have implemented PGP (for one correspondent who wants it) I'm realising why I didn't do so before. It takes *ages* for mutt to show any message from a new correspondent who has a PGP signature. Seriously this is a big issue for me, I *really* don't care who wrote most of the messages I read, especially on mailing lists and such. Sitting for tens of seconds while mutt retrieves a key from a web site is just silly. Is there a way to turn this off while still allowing me to send (using 'p') signed messages? -- Chris Green
Re: Some (beginner) PGP questions
On Wed, Nov 24, 2010 at 12:12:54PM -0900, Roger wrote: > On Wed, Nov 24, 2010 at 05:53:22PM +0000, Chris G wrote: > >(e)ncrypt - presumably encrypts the message and, when it asks "Enter > >keyID for x...@yyy.zzz: " one enters the keyID for the *recipient*. > >This had me fooled initially, I guess it's obvious when you think > >about it but not straight away. > > > >(s)ign - presumably 'signs' the message to prove (maybe!) it's from > >me. > > > >(s)ign as - what does this do? > > Sign as or with "another user/key"? > > >(b)oth - presumably encrypts and signs the message > > Yes, both - sign & encrypt. > > >(i)nline - is this just the old-fashioned way of doing it? > To the best of my knowledge as well, sign inline instead of attach. > > From what I understand, attaching is standard nowadays. > > >(c)lear - do nothing? I.e. I hit 'p' by mistake > This I agree is misleading. Took me a month to figure-out this really meant > "exit" and not my mislead interpretation of "clear sign"... although GNUPG > doesn't have this option? > > Most of these option explanations can be found within the GNUPG (gpg) man > page. > Thanks! :-) That's got me most of the way. -- Chris Green
Some (beginner) PGP questions
I have configured PGP with mutt (1.5.20 running on Xubuntu 10.04) according to the instructions at:- http://wiki.mutt.org/?MuttGuide/UseGPG It seems to be basically working but I have some questions about actually using it. I'm not doing any automatic signing or encryption, I only want to use it for messages to one user so initially I will compose a message and then hit 'p' (I may add a sender-hook in due course). So, when I hit 'p' I get a series of options:- PGP (e)ncrypt, (s)ign, sign (a)s, (b)oth, (i)nline, or (c)lear? and I want to understand what these mean, so I'll say what I think they mean and wait for corrections and elucidations:- (e)ncrypt - presumably encrypts the message and, when it asks "Enter keyID for x...@yyy.zzz: " one enters the keyID for the *recipient*. This had me fooled initially, I guess it's obvious when you think about it but not straight away. (s)ign - presumably 'signs' the message to prove (maybe!) it's from me. (s)ign as - what does this do? (b)oth - presumably encrypts and signs the message (i)nline - is this just the old-fashioned way of doing it? (c)lear - do nothing? I.e. I hit 'p' by mistake -- Chris Green
Re: Can one fix the directory for saving attachments?
On Sun, Nov 21, 2010 at 09:59:50AM -0600, David Champion wrote: > * On 20 Nov 2010, Chris G wrote: > > By default mutt saves attachments in the current directory (i.e. in the > > directory in which it was started). In my case this is often somewhere > > completely random and most definitely isn't where I want to save > > attachments. > > > > Apart from being careful about the dreictory from which I start mutt is > > there any way to force it to always save attachments to the same place > > (for example ~/tmp)? > > I have recently begun wanting to do this, and created this macro: > > macro attach S "~/maildrop/" "Save to maildrop > folder" > > (~/maildrop is a zfs filesystem on my opensolaris server that is > nfs-exported to an IP address controlled by OpenVPN. I use OpenVPN > client on my Macbook and mount maildrop wherever I go.) > I just tried:- macro attach S "~/tmp/" "Save to ~/tmp" and it sort of works but it's a bit laborious because you have to accept the directory to save to and then enter the file name to save to. However simply changing it to:- macro attach S "~/tmp/" "Save to ~/tmp" does exactly what I want, it offers to save the file with the existing attachment filename in ~/tmp, just hit CR and it's saved. Thanks for pointing me in the right direction. -- Chris Green
Can one fix the directory for saving attachments?
By default mutt saves attachments in the current directory (i.e. in the directory in which it was started). In my case this is often somewhere completely random and most definitely isn't where I want to save attachments. Apart from being careful about the dreictory from which I start mutt is there any way to force it to always save attachments to the same place (for example ~/tmp)? -- Chris Green
Re: Can I use a sendmail across my LAN?
On Thu, Oct 28, 2010 at 12:21:41PM +0100, Chris G wrote: > On Thu, Oct 28, 2010 at 01:00:43PM +0200, Matthias Apitz wrote: > > El día Thursday, October 28, 2010 a las 11:50:23AM +0100, Chris G escribió: > > > > > I have a small home LAN and have one machine set up as a server machine. > > > That machine has postfix on it fully configured to both send and receive > > > mail. > > > > > > Is it possible to use the sendmail (well, postfix's sendmail) on that > > > machine from other machines on the LAN to send mail? Otherwise I have > > > to configure each machine my ISP's smarthost SMTP details whereas if I > > > use my LAN machine's sendmail I only need to set up the smart/relay host > > > in one place. > > > > > > If it is possible how do I configure the various mutts to use it? > > > > You could configure each sendmail to use your central box as relay > > (smarter host) or you can set in each mutt something like: > > > But then I have to install and configure an MTA on every machine. > > > set smtp_url=smtp://your-central-box/ > > > Yes, I guess this is the way to do it, just seems wrong somehow to > convert it all to SMTP and back. Will it work just as above with no > user name or password? I guess I can just try it. > Seems to work OK, I get to see all the negotiations on the status line too. -- Chris Green
Re: Can I use a sendmail across my LAN?
On Thu, Oct 28, 2010 at 03:26:27PM +0100, Jamie Paul Griffin wrote: > > > There are no web clients of any sort involved. I just have four or five > > machines on a LAN with one always on server machine. Most of the time I > > send mail from my desktop machine using mutt but occasionally I send > > mail from other machines on the LAN and it would be very convenient if I > > could simply tell those other mutts that they can send their mail > > through the LAN server's postfix. > > I think you'd need to configure the mta's on each of the other machines you > would like to use to route mail to your main postfix server. The mutt's on > those machine wouldn't need any changes to their configuration. Otherwise it > would be using the smtp_url configuration as was suggested earlier. > Yes, I think my possible solutions are:- Configure mutt to use my ISP's smarthost directly with smtp_url Configure mutt to us my LAN server's postfix as SMTP smarthost with smtp_url Configure an MTA on all systems and mutt will 'just work' I think I'm leaning towards the last solution, once I have postfix working on the LAN server it's pretty simple to copy the configuration (or at least the relevant parts of it) to any other system where I want postix as MTA. It also has the advantage that anything that fires off an E-Mail will find a working sendmail. -- Chris Green
Re: Can I use a sendmail across my LAN?
On Thu, Oct 28, 2010 at 10:07:20AM -0400, Patrick Shanahan wrote: > * Chris G [10-28-10 09:57]: > > What I was hoping/imagining might be possible was to tell mutt that the > > sendmail it should use is on another machine. Given that that is a > > trusted/closed network behind a firewall that isn't unreasonable > > security wise. > > > > There are no web clients of any sort involved. I just have four or five > > machines on a LAN with one always on server machine. Most of the time I > > send mail from my desktop machine using mutt but occasionally I send > > mail from other machines on the LAN and it would be very convenient if I > > could simply tell those other mutts that they can send their mail > > through the LAN server's postfix. > > Then the simplest solution would be to ssh into your machine containing > the smtp system and use the mutt instance resident there. I do this or > vnc to my home machine frequently when on the road with my wife and her > windoz laptop. > Yes, I do that sometimes, however it does have other issues if mutt isn't actually running on the desktop machine. In particular:- I can't use Firefox to view HTML messages via 'v'. I use lynx via auto_view for most things but occasionally I want to look at something with a GUI browser. If I save attachments they end up on the server machine, not on my desktop machine. OK, there are ways around the above inconveniences but they then rather negate the simplicity I was after. -- Chris Green
Re: Can I use a sendmail across my LAN?
On Thu, Oct 28, 2010 at 08:39:42AM -0400, Brian Cuttler wrote: > On Thu, Oct 28, 2010 at 12:21:41PM +0100, Chris G wrote: > > On Thu, Oct 28, 2010 at 01:00:43PM +0200, Matthias Apitz wrote: > > > El d�a Thursday, October 28, 2010 a las 11:50:23AM +0100, Chris G > > > escribi�: > > > > > > > I have a small home LAN and have one machine set up as a server machine. > > > > That machine has postfix on it fully configured to both send and receive > > > > mail. > > > > > > > > Is it possible to use the sendmail (well, postfix's sendmail) on that > > > > machine from other machines on the LAN to send mail? Otherwise I have > > > > to configure each machine my ISP's smarthost SMTP details whereas if I > > > > use my LAN machine's sendmail I only need to set up the smart/relay host > > > > in one place. > > > > > > > > If it is possible how do I configure the various mutts to use it? > > > > > > You could configure each sendmail to use your central box as relay > > > (smarter host) or you can set in each mutt something like: > > > > > But then I have to install and configure an MTA on every machine. > > Sorry for jumping in... > > How where you planning to generate the mail to begin with ? > Well, if it's user generated mail then (surprise!) I'm using mutt. > If you are just using a browser email client of some kind you > can configure, oh, thunderbird, or whatever to use the mailhub > and be done with it, but you will need some config in some client > on each end-point... unless you want to install squirl mail or some > other web-based email server, but you will still need the mailhub > and pop or imap under it. > What I was hoping/imagining might be possible was to tell mutt that the sendmail it should use is on another machine. Given that that is a trusted/closed network behind a firewall that isn't unreasonable security wise. There are no web clients of any sort involved. I just have four or five machines on a LAN with one always on server machine. Most of the time I send mail from my desktop machine using mutt but occasionally I send mail from other machines on the LAN and it would be very convenient if I could simply tell those other mutts that they can send their mail through the LAN server's postfix. -- Chris Green
Re: Can I use a sendmail across my LAN?
On Thu, Oct 28, 2010 at 01:00:43PM +0200, Matthias Apitz wrote: > El día Thursday, October 28, 2010 a las 11:50:23AM +0100, Chris G escribió: > > > I have a small home LAN and have one machine set up as a server machine. > > That machine has postfix on it fully configured to both send and receive > > mail. > > > > Is it possible to use the sendmail (well, postfix's sendmail) on that > > machine from other machines on the LAN to send mail? Otherwise I have > > to configure each machine my ISP's smarthost SMTP details whereas if I > > use my LAN machine's sendmail I only need to set up the smart/relay host > > in one place. > > > > If it is possible how do I configure the various mutts to use it? > > You could configure each sendmail to use your central box as relay > (smarter host) or you can set in each mutt something like: > But then I have to install and configure an MTA on every machine. > set smtp_url=smtp://your-central-box/ > Yes, I guess this is the way to do it, just seems wrong somehow to convert it all to SMTP and back. Will it work just as above with no user name or password? I guess I can just try it. -- Chris Green
Can I use a sendmail across my LAN?
I have a small home LAN and have one machine set up as a server machine. That machine has postfix on it fully configured to both send and receive mail. Is it possible to use the sendmail (well, postfix's sendmail) on that machine from other machines on the LAN to send mail? Otherwise I have to configure each machine my ISP's smarthost SMTP details whereas if I use my LAN machine's sendmail I only need to set up the smart/relay host in one place. If it is possible how do I configure the various mutts to use it? -- Chris Green
Do many here still use abook or are there better alternatives now?
Do many people here still use abook? It hasn't been updated for several years now (although that doesn't mean it's no good necessarily). Or are there alternative ways of maintaining the mutt alias list (and maybe an addressbook as well) nowadays? -- Chris Green
Re: How to cope with a mailing list that has two addresses?
On Fri, Oct 22, 2010 at 03:36:04PM -0500, Derek Martin wrote: > On Fri, Oct 22, 2010 at 06:36:17PM +0100, Chris G wrote: > > Thus when I do a L[ist reply] I get an E-Mail sent to *both* list > > addresses which is a bit annoying. This happens because both list > > addresses tend to appear somewhere in the list headers > > Either I have a severe case of deja-vu, or someone (you, I thought) > asked this exact question some months ago. I suspect if you search > the archives you'll find a thread about this with a very similar > title. > It's possible, I am approaching retirement age! :-) You're absolutely right, it was over a year ago though. I can re-try the ideas there. The reason that the problem has raised its ugly head again is that I have 'improved' my filtering system and that means that the script that extracts the list of addresses for 'subscribe' and 'lists' no longer skips over the second address for the mailing list. I guess I can simply put a special case in which handles this. Sorry for the noise. -- Chris Green
Re: How to cope with a mailing list that has two addresses?
On Fri, Oct 22, 2010 at 10:54:01AM -0700, Chip Camden wrote: > Quoth Chris G on Friday, 22 October 2010: > > I subscribe to one mailing list which has two addresses both of which > > are used fairly frequently. So my mutt 'subscribe' entries have two > > entries relating to one list. > > > > Thus when I do a L[ist reply] I get an E-Mail sent to *both* list > > addresses which is a bit annoying. This happens because both list > > addresses tend to appear somewhere in the list headers > > > > Apart from getting the list fixed can anyone see a way around this > > problem? > > > > -- > > Chris Green > > Put both lists in one subscribe statement. For example: > > subscribe freebsd-questi...@freebsd.org questi...@freebsd.org > They already are:- .. ipswichrecycle-ow...@yahoogroups.com ix...@ixiemaster.ixion.org.uk ix...@ixion.org.uk leafnode-l...@dt.e-technik.uni-dortmund.de . it's those two ixion ones which cause the problem. -- Chris Green
How to cope with a mailing list that has two addresses?
I subscribe to one mailing list which has two addresses both of which are used fairly frequently. So my mutt 'subscribe' entries have two entries relating to one list. Thus when I do a L[ist reply] I get an E-Mail sent to *both* list addresses which is a bit annoying. This happens because both list addresses tend to appear somewhere in the list headers Apart from getting the list fixed can anyone see a way around this problem? -- Chris Green
Re: auto_view with firefox doesn't leave the file for firefox to view
On Fri, Aug 20, 2010 at 08:02:11AM +0800, bill lam wrote: > I heard that firefox is client-server in that it will open link in a remote > running instance of firefox. If firefox is not already running, it will > start one and close the current instance and then start again to connect to > the new remote instance. Try if it will improve by keeping a running > instance of firefox before launching from mutt. > There nearly always is a running copy of Firefox. I've not noticed this problem before, maybe it was just one very brief E-Mail that provoked it, since then most have worked OK. -- Chris Green
auto_view with firefox doesn't leave the file for firefox to view
I'm sure this used to work for me but I have changed a few things in this area recently so I may have broken it by leaving something vital out. I have mutt set up so that by default HTML messages are displayed in the pager using links. However if I want to view the E-Mail in firefox I hit 'v' and select the HTML part. Thus in my muttrc I simply have:- auto_view text/html ... and in my .mailcap I have:- text/html; /usr/bin/firefox %s text/html; links -dump %s -html-numbered-links 1; copiousoutput; nametemplate=%s.html However the problem is that when I 'v' the mail and then select the text/html part mutt fires it off at firefox but then continues and deletes the temporary file before firefox has displayed it. Sometime it works but with small files it usually doesn't work. I only realised what was happening when I recently hit return against the same file (after 'v') lots of times and firefox succeeded in displaying about half of them. Even those it had displayed had disappeared from /tmp but since firefox had grabbed and displayed them already they were still visible. How does on make mutt wait for firefox to display the file before it deletes it? -- Chris Green
Re: Further question(s) about locking, viewing inbox, etc.
On Tue, Aug 10, 2010 at 09:28:14AM +0100, Chris G wrote: > Thanks for all the help so far. :-) > > I've been thinking (now that's something!) about how mutt interacts > with mail delivery programs and I'm realising that I don't *really* > understand how it all works regarding locking etc. > > Take a trivially simple case, mail for user chris is delivered to > /var/mail/chris by, say, postfix. I run mutt which looks at > /var/mail/chris and displays the index of messages there. > > What happens (as regards locks etc.) when mutt is displaying the inbox > index and postfix wants to deliver another message? Obviously mutt > doesn't keep the file /var/mail/chris permanently locked as otherwise > postfix would never be able to append the new message (if it was > obeying the locking protocol). > > So what *does* happen? Does mutt open the file, scan the contents and > then close it periodically? This would seem to make sense as it often > does take a while for mutt to notice that postfix has appended a new > message. > > However I don't then understand what's going wrong when my python > script appends a message to /var/mail/chris (or wherever). What > happens (in the non NFS situation) is that mutt complains "Mailbox > was externally modified. Flags may be wrong." I can also provoke this > message if I run another copy of mutt and add/delete messages. This > error doesn't seem to relate to locking at all, it seems to be that > mutt is detecting some *other* change to the mbox file in question. > I now know! I went and looked at the Python mailbox class. When it writes *anything* to an mbox file what it actually does is to create a new file, copy the contents of the old mbox file to it, adds the new data and then renames the new mbox file over the old mbox file. This accounts for the errors I have been seeing. The problem has nothing whatsoever to do with locking, it's the replacement of the file that does it. There is a sort of logic to what python does, one *might* be deleting or adding a message into the middle of the mbox in which case the copy, rename sequence is the only sensible way to do it. However the documentation might have told me that and I'd not have wasted lots of my (and the list's) time trying to work out what was wrong. I can almost certainly fix the problem by simply not using the Python mailbox class and by just appending new messages to the mbox using straightforward file write calls (with appropriate locking of course). > Can someone tell me what exactly mutt is checking to decide that > "Mailbox was externally modified. Flags may be wrong."? Is it a check > to see if all messages up to the new appended one are unchanged, or is > it something simpler than this like a simple length check? > > -- > Chris Green > -- Chris Green
Further question(s) about locking, viewing inbox, etc.
Thanks for all the help so far. :-) I've been thinking (now that's something!) about how mutt interacts with mail delivery programs and I'm realising that I don't *really* understand how it all works regarding locking etc. Take a trivially simple case, mail for user chris is delivered to /var/mail/chris by, say, postfix. I run mutt which looks at /var/mail/chris and displays the index of messages there. What happens (as regards locks etc.) when mutt is displaying the inbox index and postfix wants to deliver another message? Obviously mutt doesn't keep the file /var/mail/chris permanently locked as otherwise postfix would never be able to append the new message (if it was obeying the locking protocol). So what *does* happen? Does mutt open the file, scan the contents and then close it periodically? This would seem to make sense as it often does take a while for mutt to notice that postfix has appended a new message. However I don't then understand what's going wrong when my python script appends a message to /var/mail/chris (or wherever). What happens (in the non NFS situation) is that mutt complains "Mailbox was externally modified. Flags may be wrong." I can also provoke this message if I run another copy of mutt and add/delete messages. This error doesn't seem to relate to locking at all, it seems to be that mutt is detecting some *other* change to the mbox file in question. Can someone tell me what exactly mutt is checking to decide that "Mailbox was externally modified. Flags may be wrong."? Is it a check to see if all messages up to the new appended one are unchanged, or is it something simpler than this like a simple length check? -- Chris Green
Re: Mbox locking, how to do it in a way that will work with mutt?
On Mon, Aug 09, 2010 at 06:18:41PM -0400, Patrick Shanahan wrote: > * Chris G [08-09-10 18:11]: > > Can anyone point me at some code that shows how I should do mbox > > locking in a way that will work with mutt? > > > > This is on an Ubuntu 9.10 (probably soon 10.04) system. > > > > I need to know what locking calls I must make (fcntl, or lockf, or > > what), do I need to do dot-locking as well, what is the necessary > > order of the calls to avoid deadlock etc.? > > on cl "mutt -v" will tell you what locking is compiled in your version. Yes, I've already done that:- +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK but does that mean that to co-operate with mutt another process *has* to use dotlock and fcntl? ... and, if so, what order should one do things in? -- Chris Green
Mbox locking, how to do it in a way that will work with mutt?
Can anyone point me at some code that shows how I should do mbox locking in a way that will work with mutt? This is on an Ubuntu 9.10 (probably soon 10.04) system. I need to know what locking calls I must make (fcntl, or lockf, or what), do I need to do dot-locking as well, what is the necessary order of the calls to avoid deadlock etc.? -- Chris Green
Re: Locking issues (or maybe not locking issues)
On Mon, Aug 09, 2010 at 02:23:17PM -0700, Chip Camden wrote: > Quoth Chris G on Monday, 09 August 2010: > > On Mon, Aug 09, 2010 at 09:20:05PM +0100, Chris G wrote: > > [snip my mutt/mbox/NFS issues] > > > > Can someone clarify something for me please, ignore NFS and assume I'm > > running mutt and the mail delivery agent on the same system on a local > > hard disk. > > > > If I open my inbox with mutt and leave it displaying the index of the > > inbox on the screen what should happen when a new message is delivered > > to the inbox? > > > > Should it:- > > > > 1 - Not get delivered because mutt has the inbox locked and the > > delivery agent can't open it for writing. > > > > 2 - Be delivered and appear correctly to mutt as a new message > > added at the bottom of the index listing with an 'N' beside it. > > > > 3 - Be delivered but cause mutt to complain "Mailbox was > > externally modified. Flags may be wrong." > > > > 4 - Something else. > > > > What I'm getting is 3 above which seems wrong to me, I suspect it is > > the underlying problem for my NFS issue, I just get a different error > > when viewing the mbox via NFS. > > > > I get (2), but only after keyboard input or the input timeout occurs. > Version 1.4.2.3i on FreeBSD. > Aha, thanks. That prompted me to go and try without my python delivery script (by using mutt to look at another user's inbox) and, as you say, it does 2 above. It even does 2 above when the inbox is mounted by NFS. So my problem is down to my python delivery script which, although it's using the 'proper' python classes for mail obviously isn't behaving itself properly. How does one tell what locking method(s) is/are being used by mutt? This is on an Ubuntu 9.10 system running mutt 1.5.20. Doing 'mutt -v' returns ". +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK", does another process *have* to use dotlock and fcntl locking or could it use just fcntl? -- Chris Green
Re: Locking issues (or maybe not locking issues)
On Mon, Aug 09, 2010 at 09:20:05PM +0100, Chris G wrote: [snip my mutt/mbox/NFS issues] Can someone clarify something for me please, ignore NFS and assume I'm running mutt and the mail delivery agent on the same system on a local hard disk. If I open my inbox with mutt and leave it displaying the index of the inbox on the screen what should happen when a new message is delivered to the inbox? Should it:- 1 - Not get delivered because mutt has the inbox locked and the delivery agent can't open it for writing. 2 - Be delivered and appear correctly to mutt as a new message added at the bottom of the index listing with an 'N' beside it. 3 - Be delivered but cause mutt to complain "Mailbox was externally modified. Flags may be wrong." 4 - Something else. What I'm getting is 3 above which seems wrong to me, I suspect it is the underlying problem for my NFS issue, I just get a different error when viewing the mbox via NFS. -- Chris Green
Locking issues (or maybe not locking issues)
I'm having problems getting mutt and a python script to play nicely together with an mbox format mailbox. I get different symptoms according to whether mutt is accessing the mailbox directly or via NFS. If I open the mbox file with mutt and have mutt displaying the index of messages and then the python script tries to write a new message to the mailbox I would expect the python script to see the file is locked and wait until mutt 'lets go'. What actually happens is that the python script writes to the mbox file and mutt says "Mailbox was externally modified. Flags may be wrong." It's as if locking isn't working at all but the python script is using the python mail libraries and is locking and unlocking correctly as far as I know. If, on the other hand, I open the mbox via NFS with mutt and leave mutt viewing the index and write a message to the mbox from the python script I get a different symptom - mutt just goes to a blank screen with the message "No mailbox is open". Hitting 'c' will open the mbox again because mutt sees the new mail there. Am I misunderstanding how the mbox locking is supposed to work? Should it be possible for another process to write to an mbox file that mutt has 'open' and is displaying the index? If mutt just opens the file and displays the index but closes the file then maybe "Mailbox was externally modified. Flags may be wrong." are just par for the course. However the NFS case seems to suggest that when another process modifies the file it actually becomes a different file from mutt's point of view and the original mbox disappears. -- Chris Green
Re: what does this "sender invalid" error mean?
On Mon, Aug 02, 2010 at 02:10:36PM -0700, Michael Elkins wrote: > On Mon, Aug 02, 2010 at 09:38:01PM +0100, Chris G wrote: > >I'm trying to b[ounce] a message and I'm getting the following error > >on the mutt status line:- > > > >SMTP session failed: 550 Sender invalid > > > >So what is it saying? Obviously "Chris@" id invalid but how is mutt > >creating it and what is missing such that mutt can't create a valid > >address? > > It looks like Mutt is not able to automatically determine the FQDN > for your host by inspecting /etc/resolv.conf. The easiest solution > is to manually set your $from or $hostname: > > set from=u...@example.com > set hostname=example.com > That was my line of thinking but. "hostname -fqdn" returns chris.isbd.net which is correct and /etc/resolv.conf is:- domain isbd.net search isbd.net nameserver 192.168.1.2 However I've just realised that I removed the record for chris.isbd.net from the zone file for isbd.net at my hosting provider, would the non-existence of chris.isbd.net break things? -- Chris Green
what does this "sender invalid" error mean?
I'm trying to b[ounce] a message and I'm getting the following error on the mutt status line:- SMTP session failed: 550 Sender invalid So what is it saying? Obviously "Chris@" id invalid but how is mutt creating it and what is missing such that mutt can't create a valid address? -- Chris Green
Re: Occasional "Stale NFS file handle" messages from mutt
On Tue, Jul 27, 2010 at 02:19:48PM -0700, Omen Wild wrote: > Quoting Chris G on Tue, Jul 27 22:10: > > > > I use my home brew python delivery program because it (for me) is much > > better than procmail or similar. In particular I can add a mailing > > list entry to a *single* configuration file and everything > > automagically works - mutt gets its Lists/Subscribe entries, the maill > > gets delivered to the right mailboxes, etc. > > That sounds really slick, any chance you could share? > I certainly could - when I get home, I'm in Belgium at the moment working through a mobile dongle. I'm aiming to be back homw in the UK on/around 6th August. If I don't produce the script in a week or so give me a prod! :-) -- Chris Green
Re: Occasional "Stale NFS file handle" messages from mutt
On Mon, Jul 26, 2010 at 05:09:59PM -0500, Derek Martin wrote: > On Sat, Jul 24, 2010 at 12:28:01PM +0100, Chris G wrote: > > I'm seeing the "Stale NFS file handle" messages on the mutt status > > line, I'm not *absolutely* sure when they are occurring but it looks > > as if it's when a mail is delivered into a mailbox when I'm viewing an > > E-Mail in that mailbox with mutt. > > Stale NFS filehandles are not, strictly speaking, locking problems. > They're caused by when a file or directory is deleted or renamed on > the server, but the client still has an open filehandle to the file, > IIRC. > Exactly, it seems odd to me too and I wondered if anyone had seen it before. > > E.g. I was working down my inbox (where non-list mail arrives) this > > morning and, after reading a message, when I returned to the inbox > > (quite likely after marking the mail as deleted) I saw the stale NFS > > error. I *think* the message I had just viewed had failed to get > > marked as D or O, it remained at N and there was one new message in > > the inbox. > > This doesn't sound like it should cause a stale filehandle, but you > mentioned some delivery program written in Python. I can't guess what > it's doing, and it may have some incorrect or conflicting > implementation of locking or delivery that's causing the problem. I > can't guess why you're not using procmail or some other well-tested > delivery agent, or why you're reading mbox mail over NFS, but in > general both of those choices seem rather bad. I'm not trying to > suggest you use maildir (though clearly that might be a solution to > your problem), but NFS + mbox = bad. Better would be to read the mail > locally on the server, or get it somehow delivered to the machine on > which you care to read it. Or IMAP. In my personal order of > preference. :) > I use my home brew python delivery program because it (for me) is much better than procmail or similar. In particular I can add a mailing list entry to a *single* configuration file and everything automagically works - mutt gets its Lists/Subscribe entries, the maill gets delivered to the right mailboxes, etc. I'm using well tested classes in python for delivering the mail. I did start reading the mail locally on the server but that has issues when handling attachments and/or when viewing HTML. It's a way around the issue but it's not perfect. It's difficult to deliver to the machine where I'm reading it as it's not turned on all the time. I have tried IMAP on and off over the years but it tends to be (for me) in the same place as maildir, usable but not ideal. I *think* I may have fixed the problem by a small change in the code (it sets the file dates after delivery), I haven't seen a Stale NFS file handle for a while. I still don't really understand how it was occurring. -- Chris Green
Occasional "Stale NFS file handle" messages from mutt
I'm running mutt on Linux (Ubuntu 9.10) with my incoming mail arriving on an NFS mounted directory. I.e. /home/chris/Mail is a symbolic link to /snake1/home/chris/Mail which is a directory on another system (snake1) which is where the mail is actually delivered. Mail is delivered to multiple sub-directries under ~/Mail by a python script which filters on (mostly) mailing list name. I'm seeing the "Stale NFS file handle" messages on the mutt status line, I'm not *absolutely* sure when they are occurring but it looks as if it's when a mail is delivered into a mailbox when I'm viewing an E-Mail in that mailbox with mutt. E.g. I was working down my inbox (where non-list mail arrives) this morning and, after reading a message, when I returned to the inbox (quite likely after marking the mail as deleted) I saw the stale NFS error. I *think* the message I had just viewed had failed to get marked as D or O, it remained at N and there was one new message in the inbox. No mail seems to get lost and mutt carries on with no other issues apart from the incorrect message status. So it looks as if I have some sort of locking issue between the delivery process on the server and mutt reading E-Mails (and updating the mailbox). This is mbox format of course. Don't tell me to go back to maildir, having just moved to mbox from maildir it works *so* much better in every way apart from this minor hiccough that I'd stay with mbox and put up with it if that was the only way forward. I'm hoping/guessing that there is maybe something I can do with the python script that delivers the E-Mails that will make it play better with mutt. Does anyone have any ideas on this front and/or pointers to places which will tell me more about how to make file locking etc. work properly on an NFS file system. -- Chris Green
Using a remote firefox from .mailcap - how?
I used to run mutt on my desktop machine at home with the following in my .mailcap file:- text/html; /usr/bin/firefox %s text/html; links -dump %s -html-numbered-links 1; copiousoutput; nametemplate=%s.html With "auto_view text/html" in my muttrc this means that by default I got to see HTML E-Mails in my mutt pager window but I could open up the HTML in Firefox using 'v' if I really needed do. I now run mutt on the mail server machine on my home network rather than on my desktop machine, it makes life easier in several ways so I don't want to change that. Hence it runs in a terminal window via ssh from my desktop, easy enough to implement 'transparently' for most of the time. However, obviously, the /usr/bin/firefox line in mailcap doesn't work because there's no Firefox on the GUI-less mail server. What's the easiest way (if there is one) of feeding the HTML E-Mail from mutt running on the mail server into a (nearly always) running firefox on my desktop machine? -- Chris Green
Re: A wish for the mailboxes command
On Fri, Jun 25, 2010 at 05:01:23PM +0200, Alex Huth wrote: > On Fri, Jun 25, 2010 at 03:33:07PM +0100, Chris G wrote: > > On Fri, Jun 25, 2010 at 03:23:55PM +0200, Alex Huth wrote: > > Only if it knows which ones have new mail in them! That's where we > > came in. > > > > That´s what i am talking about. I am using sidebar with lot of maildirs > and the following in the config: > set check_new=yes > set mail_check=60 > > Works perfect! > Fine, and 'c[hange to directory with new mail]' will work perfectly too, without the sidebar. -- Chris Green
Re: A wish for the mailboxes command
On Fri, Jun 25, 2010 at 03:23:55PM +0200, Alex Huth wrote: > On Fri, Jun 25, 2010 at 10:47:29AM +0100, Chris G wrote: > > On Thu, Jun 24, 2010 at 09:07:01AM -0700, Chip Camden wrote: > > > > > I don't really want to know when new mail arrives, what I want is the > > ability to quickly go to all the mailboxes which have new incoming > > mail when I'm running mutt. I don't have any need to respond quickly > > to messages, just a need to be able to find them. Mutt usually sits > > running in a dedicated terminal on one of my workspaces with the > > 'main' inbox displayed so I just need to glance at that to see any > > non-list E-Mails. > > Hmmm, if i understand it right sidebar will be your friend. It shows all > folders/files with new mails and give you quick acces to them. > Only if it knows which ones have new mail in them! That's where we came in. -- Chris Green
Re: Message save causes erroneous "New" mail detection.
On Fri, Jun 25, 2010 at 08:05:31PM +1000, Erik Christiansen wrote: > > [1] > If mutt knows not to flag the transferred email as new, then it also > knows enough not chuck up the erroneous "New mail" message. The logic > used for the message flags is different from that used for confusing > the user with a false message, it appears. > Yes, the N[ew], O[ld] and other flags are actually written to the mbox as I understand it - yes, just looked, there's a Status: line in the message header which has flags in it. Scanning for new messages is done (for mbox) by looking to see if the mbox file has changed since last read. Presumably mutt doesn't look at the header Status: line because that would take too long. It's a pity that there isn't an option to tell mutt to use the Status: header to check for new messages, on a fast single-user system that would be quite fast enough and much more accurate. -- Chris Green
Re: Message save causes erroneous "New" mail detection.
On Thu, Jun 24, 2010 at 09:00:13AM -0800, rog...@sdf.org wrote: > On Thu, Jun 24, 2010 at 03:05:14PM +0200, Christian Ebert wrote: > >I can't reproduce this, neither with $check_mbox_size set or > >unser. Unless, of course, I copy a message that is flagged as > >New. > > I've seen this sporadically when receiving new email, reading it, then > restarting mutt later or returning a few hours later and finding the email is > again marked new. > If you don't exit from mutt properly this is exactly what you will see. I.e. if you have mutt running in a terminal window and close your computer down without exiting from mutt any messages you have read will not be marked as read when you start up again. -- Chris Green
Re: A wish for the mailboxes command
On Thu, Jun 24, 2010 at 09:07:01AM -0700, Chip Camden wrote: > On Jun 24 16:09, Chris G wrote: > > After all the recent discussion of detecting new mail etc. it occurs > > to me that it would be very useful to be able to tell mutt that it > > should scan all files in a particular directory for new mail. > > > > If one does have more than one (and non-standard) incoming mail > > destinations then it's almost inevitable that they will be in one > > place, or at most two or three places. > > > > In my case I have:- > > > > ~/Mail/In with inbox, junk and bcs in it > > ~/Mail/Li with all my mailing list incoming mail, each to its own > > file/folder > > > > If I could just say:- > > mailboxes ~/Mail/In ~/Mail/Li > > it would make my life a whole lot simpler. > > > > (I guess I might want to unmailboxes ~/Mail/In/junk) > > > > -- > > Chris Green > > I don't rely on mutt to tell me when new mail arrives. For one thing, I > usually have a different workspace active. So I display it in an xmobar > section, and use this ruby script to test for new mail in each mbox file: > I don't really want to know when new mail arrives, what I want is the ability to quickly go to all the mailboxes which have new incoming mail when I'm running mutt. I don't have any need to respond quickly to messages, just a need to be able to find them. Mutt usually sits running in a dedicated terminal on one of my workspaces with the 'main' inbox displayed so I just need to glance at that to see any non-list E-Mails. -- Chris Green
A wish for the mailboxes command
After all the recent discussion of detecting new mail etc. it occurs to me that it would be very useful to be able to tell mutt that it should scan all files in a particular directory for new mail. If one does have more than one (and non-standard) incoming mail destinations then it's almost inevitable that they will be in one place, or at most two or three places. In my case I have:- ~/Mail/In with inbox, junk and bcs in it ~/Mail/Li with all my mailing list incoming mail, each to its own file/folder If I could just say:- mailboxes ~/Mail/In ~/Mail/Li it would make my life a whole lot simpler. (I guess I might want to unmailboxes ~/Mail/In/junk) -- Chris Green
Re: Message save causes erroneous "New" mail detection.
On Thu, Jun 24, 2010 at 02:48:15PM +0100, Chris G wrote: > > > Getting back to your problem I have just realised something, when you > > > copy a mail message to another mailbox it *is* a new message in that > > > mailbox. I have just tried it and I get exactly the same symptoms that > > > you report. > > > > I can't reproduce this, neither with $check_mbox_size set or > > unser. Unless, of course, I copy a message that is flagged as > > New. > > > I have just tried it again and I definitely *do* see the bug/problem. > > I have a message from amazon.co.uk in my inbox which I have read but > not deleted, it has no flags by it. I s[ave] it to > ~/Mail/shopping/books and it's deleted from my inbox. I then either > s[ave] it or C[opy] it back to my inbox and mutt *immediately* tells > me there's new mail in my inbox. However when I go and look the mail > from amazon is there but not marked 'N'. > When you think about it this is inevitable isn't it? If one writes a message to an mbox file then the size changes and (if atime is enabled) the modification time will be after the access time. So mutt *has* to say there's new mail in the mailbox. It gets it right to the extent that the 'new' mail isn't marked as such in the index if it's not really new but I can see no way that mutt could act otherwise regarding seeing the mailbox as having new mail in it. -- Chris Green
Re: Message save causes erroneous "New" mail detection.
On Thu, Jun 24, 2010 at 03:05:14PM +0200, Christian Ebert wrote: > * Chris G on Thursday, June 24, 2010 at 13:45:26 +0100 > > On Thu, Jun 24, 2010 at 10:29:25PM +1000, Erik Christiansen wrote: > >> On Thu, Jun 24, 2010 at 01:08:07PM +0100, Chris G wrote: > >>> I'm getting the feeling that, maybe, very few people are now using > >>> mutt with mbox so that an 'out of the box' installation of mutt on > >>> Linux works fine with maildir but if you switch to mbox it all goes > >>> very much awry. > >> > >> Oh-oh, that's not good news. I have 710 mbox mail files, with more than > >> 3000 posts in some of them. I suppose I could convert each mbox to a > >> directory of the same name, but then I'd have to muck for days tuning my > >> .muttrc, I fear. :-( > >> > >> Is mbox actively deprecated by the developers, or has it just become a > >> corner case? > > Neither, I'd say. > > > I wasn't saying I was *sure* of this (mbox not getting tested too well > > because it's not used much now) but it's just a feeling I am getting > > as I too had problems moving from 1.4.x to 1.5.x which, at the time, I > > fixed by moving to maildir. > > > > I am now setting up a new system and decided to move back to mbox > > (hence my recent posts on this subject) as the advantages *still* > > outweigh the disadvantages for me. Since my mail delivery goes > > through a filter script of my own I can 'fiddle' things so that new > > mail is recognised by mutt. > > > > Getting back to your problem I have just realised something, when you > > copy a mail message to another mailbox it *is* a new message in that > > mailbox. I have just tried it and I get exactly the same symptoms that > > you report. > > I can't reproduce this, neither with $check_mbox_size set or > unser. Unless, of course, I copy a message that is flagged as > New. > I have just tried it again and I definitely *do* see the bug/problem. I have a message from amazon.co.uk in my inbox which I have read but not deleted, it has no flags by it. I s[ave] it to ~/Mail/shopping/books and it's deleted from my inbox. I then either s[ave] it or C[opy] it back to my inbox and mutt *immediately* tells me there's new mail in my inbox. However when I go and look the mail from amazon is there but not marked 'N'. -- Chris Green
Re: Detecting new mail and read mail in 1.4 and 1.5
On Thu, Jun 24, 2010 at 03:02:40PM +0200, Michael Ludwig wrote: > Michael Ludwig schrieb am 23.06.2010 um 14:23 (+0200): > > Christian Ebert schrieb am 22.06.2010 um 23:16 (+0200): > > > * Michael Ludwig on Tuesday, June 22, 2010 at 22:27:06 +0200 > > > > > > How can new mail detection be repaired for 1.5? > > > > > > I'm using Maildir, but > > > > > > set check_mbox_size=yes > > > > I presume the underlying issue is that atime (access time) is turned off > > or otherwise unavailable on some filesystems, so Mutt cannot use it to > > detect new mail in a box. Is that correct? > > Yes, appears to be correct: > > http://wiki.mutt.org/?MuttFaq/Folder > > Why are "new" flags of mbox folders wrong in folder-list view? > > Bottom line: > > * $check_mbox_size option for mutt 1.5.15 or later > * --enable-buffy-size option to "configure" for mutt < 1.5.15 > Presumably this can only work when mail is added to an existing mailbox? If so it would be close to useless for my situation:- Lots of incoming mailboxes, one for each mailing list I'm subscribed to. I have 'set save_empty=no' so that empty mailboxes disappear, it means I don't have to clear up after I unsubscribe from a list. (and it's one of the reasons I want to stay with mbox) I don't keep mailing list mail in the incoming mailboxes, anything I want to keep is moved elsewhere, so even active mailing list inboxes get empty (and thus removed) fairly regularly. Anyway my fix in the filter program of setting the modified time a few seconds in the future seems to work a treat. -- Chris Green
Re: Message save causes erroneous "New" mail detection.
On Thu, Jun 24, 2010 at 10:29:25PM +1000, Erik Christiansen wrote: > On Thu, Jun 24, 2010 at 01:08:07PM +0100, Chris G wrote: > > > > > I'm getting the feeling that, maybe, very few people are now using > > mutt with mbox so that an 'out of the box' installation of mutt on > > Linux works fine with maildir but if you switch to mbox it all goes > > very much awry. > > Oh-oh, that's not good news. I have 710 mbox mail files, with more than > 3000 posts in some of them. I suppose I could convert each mbox to a > directory of the same name, but then I'd have to muck for days tuning my > .muttrc, I fear. :-( > > Is mbox actively deprecated by the developers, or has it just become a > corner case? > I wasn't saying I was *sure* of this (mbox not getting tested too well because it's not used much now) but it's just a feeling I am getting as I too had problems moving from 1.4.x to 1.5.x which, at the time, I fixed by moving to maildir. I am now setting up a new system and decided to move back to mbox (hence my recent posts on this subject) as the advantages *still* outweigh the disadvantages for me. Since my mail delivery goes through a filter script of my own I can 'fiddle' things so that new mail is recognised by mutt. Getting back to your problem I have just realised something, when you copy a mail message to another mailbox it *is* a new message in that mailbox. I have just tried it and I get exactly the same symptoms that you report. However, in my case I never see it because the mailboxes to which I copy mail are not in the 'mailboxes' line in my muttrc. I have just tried the same on my (old) maildir setup and there it *doesn't* seem to think old mail saved in a different mailbox is new mail. -- Chris Green
Re: Message save causes erroneous "New" mail detection.
On Thu, Jun 24, 2010 at 09:32:38PM +1000, Erik Christiansen wrote: > On Thu, Jun 24, 2010 at 12:28:24PM +0200, Michael Ludwig wrote: > > Erik Christiansen schrieb am 24.06.2010 um 19:18 (+1000): > > > Since upgrading to ubuntu 10.04, and therefore Mutt 1.5.20, saving a > > > read mail to another mailbox immediately causes that mailbox to be > > > flagged as containing new mail. Since I'm using the same .muttrc, > > > something has changed between mutt versions, to cause the erroneous > > > behaviour. (Prior mutt version was from 3 years ago, or so.) > > > > > > Does anyone know of a fix for this problem? > > > > You could give the following line a try, which has helped me with a > > similar (if not actually the same) problem: > > > > set check_mbox_size=yes > > Oooof! That was worse. Now twenty old mailboxes, which haven't received > mail in years, also "have New mail", despite being unchanged for years. > And, yes, saving from my mailbox for this list to another caused that > mailbox to be flagged as having "New" mail. > > There is a failure to distinguish between genuine mail arrival, and > simple transfer of old (read) mail between mailboxes. > > If it were a bug, I'd expect others would share the problem, so I > suspect that there's some setting which 1.5.20 needs, but 1.4.? didn't. > > My reading of the problem you solved with check_mbox_size=yes was that > it is more or less the opposite of the one I'm experiencing. > But thanks for the suggestion. Anything is worth a try. > I'm getting the feeling that, maybe, very few people are now using mutt with mbox so that an 'out of the box' installation of mutt on Linux works fine with maildir but if you switch to mbox it all goes very much awry. -- Chris Green
Re: Trying mutt out again with mbox and atime set
On Wed, Jun 23, 2010 at 09:40:42PM +0100, Chris G wrote: > I'm confused, what is going on, surely mutt should recognise a *new* > file as one that has new mail in it. > ... but maybe it doesn't. In fact how would it recognise a newly created file as one having new mail in it, it typically looks like:- Times for file mutt 2010-06-23 21:41:40.00 Modifed 2010-06-23 21:41:40.00 Accessed 2010-06-23 22:20:35.07 Status changed So the access time is the same as the modified time and mutt doesn't see it as having new mail. Since I rarely leave any mail in these mbox files (I save mail I want to keep elsewhere) and I have save_empty=no much of my new mail is in fact a completely new mailbox. Maybe this is the problem I have seen in the past. Since I have control of the writing process (my python filtering script) I can set the modified time for the mbox file a few seconds in the future, can anyone see any problem with doing this. I have modified the script to do it and it *seems* to be working but I may have overlooked something. -- Chris Green
Re: Trying mutt out again with mbox and atime set
On Wed, Jun 23, 2010 at 09:21:39PM +0100, Chris G wrote: > I have now got my new server running and I'm testing out mutt with > mbox mail storage and with atime set. > > This message is really just a test message to myself, sorry for the > noise. > > I will however report if it all works or not. > ..., and it *doesn't* work. :-( I now have two nearly identical Ubuntu 10.04 servers running. I'm delivering mail by SMTP to both of them by using the forwarding at my hosting site so both of my servers receive identical mail by SMTP. Both servers run postfix and that delivers mail to 'me' (user chris), there is a .forward file that passes the mail on to a python script that delivers the mail to the appropriate mailbox - maildir on one system and mbox on the other. My previous mail to the list has been delivered back to both systems and has arrived in the mailbox ~/Mail/Li/mutt in both cases. On the maildir system mutt sees the new mail and I can 'c' to the mailbox and see the mail. On the mbox system mutt doesn't see the mail as new and I can't use 'c' to get to it. However if I navigate to the mutt mailbox on the mbox system the message is marked as new with an 'N' by it. I have the following in muttrc:- mailboxes /var/mail/chris ~/Mail/In/inbox `echo ~/Mail/Li/*` `echo ~/Mail/In/*` So I need to reread my muttrc file to see new mailboxes in Li or In but I have done that and mutt *still* doesn't see new mail on the mbox system. I'm confused, what is going on, surely mutt should recognise a *new* file as one that has new mail in it. -- Chris Green
Trying mutt out again with mbox and atime set
I have now got my new server running and I'm testing out mutt with mbox mail storage and with atime set. This message is really just a test message to myself, sorry for the noise. I will however report if it all works or not. -- Chris Green
Re: Detecting new mail and read mail in 1.4 and 1.5
On Wed, Jun 23, 2010 at 02:23:10PM +0200, Michael Ludwig wrote: > Christian Ebert schrieb am 22.06.2010 um 23:16 (+0200): > > * Michael Ludwig on Tuesday, June 22, 2010 at 22:27:06 +0200 > > > > How can new mail detection be repaired for 1.5? > > > > I'm using Maildir, but > > > > set check_mbox_size=yes > > I presume the underlying issue is that atime (access time) is turned off > or otherwise unavailable on some filesystems, so Mutt cannot use it to > detect new mail in a box. Is that correct? > I have relatime explicitly set on my linux box and I'm pretty sure mutt still doesn't see incoming E-Mail. I know I spent a *long* time a year or so ago trying to get it to work but it just wouldn't. As I said though I'm about to rearrange things quite significantly and I'll maybe look at it all again. -- Chris Green
Re: Detecting new mail and read mail in 1.4 and 1.5
On Wed, Jun 23, 2010 at 11:22:53AM +0200, Christian Ebert wrote: > * Chris G on Wednesday, June 23, 2010 at 09:31:26 +0100 > > On Wed, Jun 23, 2010 at 09:28:48AM +0100, Chris G wrote: > >>> set check_mbox_size=yes > >>> > >>> looks like a good candidate. > >>> > >>> Look in man(5) muttrc whether it is available for your version. > >>> > >> When I moved from mutt 1.4 to 1.5 (quite a while ago) I found that new > >> mail detection in mbox stopped working. > >> > >> I never worked out why and eventually gave up and moved to maildir for > >> my incoming mailboxes but I'd move back to mbox immediately if I know > >> how to fix the new mail issue. > >> > >> ... oh, this is on an Ubuntu Linux system. > >> > > I'm doing a big change to my mail system at the moment so I may well > > try check_mbox_size and see if it works for me. > > Strange. It is supposed to work on Linux out of the box. > > Maildir vs. mbox: I found that Maildir with header_cache is way > faster than mbox in opening large mailboxes, even though I'm on a > Mac where HFS+ is supposedly not good at handling a lot of small > files. YMMV. > I don't have any large mailboxes really, the biggest is my sentmail which has around 3000 messages, all others are at the most a few tens of messages. Why is mbox slow at reading large mailboxes though, it doesn't make much sense as it's only got to open one file as opposed to maildir opening at least one file per message. , thinks, I *believe* my problem with mutt not seeing new incoming mail is because of my delivery mechanism. I use a custom python script to deliver my mail to multiple mailboxes (split basically by mailing lists) and it's that which doesn't play nicely with mutt for some reason. -- Chris Green
Re: Detecting new mail and read mail in 1.4 and 1.5
On Wed, Jun 23, 2010 at 09:28:48AM +0100, Chris G wrote: > > set check_mbox_size=yes > > > > looks like a good candidate. > > > > Look in man(5) muttrc whether it is available for your version. > > > When I moved from mutt 1.4 to 1.5 (quite a while ago) I found that new > mail detection in mbox stopped working. > > I never worked out why and eventually gave up and moved to maildir for > my incoming mailboxes but I'd move back to mbox immediately if I know > how to fix the new mail issue. > > ... oh, this is on an Ubuntu Linux system. > I'm doing a big change to my mail system at the moment so I may well try check_mbox_size and see if it works for me. -- Chris Green
Re: Detecting new mail and read mail in 1.4 and 1.5
On Tue, Jun 22, 2010 at 11:16:32PM +0200, Christian Ebert wrote: > * Michael Ludwig on Tuesday, June 22, 2010 at 22:27:06 +0200 > > Yesterday I built Mutt 1.5 on Cygwin, which worked fine; and today I > > discovered the Cygwin maintainers have done so as well. So Cygwin 1.7 > > now has Mutt 1.5. > > > > One problem that comes with the update is Mutt's notion of what is new > > mail and what is read mail. In 1.4, it worked as it should: mailboxes > > containing new mail were flagged, and reading it unset the flag. Now in > > 1.5, every mailbox is flagged as containing new mail each time I start > > Mutt. > > > > When building Mutt 1.5, I noticed that the --enable-buffy-size configure > > script flag has disappeared. > > > > When building 1.4, it seemed to me that this flag is needed to make mutt > > remember having read new mail in a box so it isn't flagged as new any > > more. > > > > Is that also the cause of the now dysfunctional new mail detection in > > 1.5, broken at least in my configuration and on Cygwin? > > > > How can new mail detection be repaired for 1.5? > > I'm using Maildir, but > > set check_mbox_size=yes > > looks like a good candidate. > > Look in man(5) muttrc whether it is available for your version. > When I moved from mutt 1.4 to 1.5 (quite a while ago) I found that new mail detection in mbox stopped working. I never worked out why and eventually gave up and moved to maildir for my incoming mailboxes but I'd move back to mbox immediately if I know how to fix the new mail issue. ... oh, this is on an Ubuntu Linux system. -- Chris Green
Re: folder permissions - where are they set?
On Thu, May 06, 2010 at 01:23:15AM +0200, Michael Tatge wrote: > * On Wed, May 05, 2010 01:11PM +0100 Chris G (c...@isbd.net) muttered: > > Is there a mutt variable to set default folder (directory and file) > > permissions when saving/copying messages? > > In short - no except you patch mutt. As a workaround you could run a > cron job to set the permissions as you like them. > Yes, having read through the thread about this (as pointed out by a previous message) I think that a cron job to relax the permissions on the folders I want to be world readable is probably the way to go. -- Chris Green
Re: folder permissions - where are they set?
On Wed, May 05, 2010 at 10:18:14AM -0500, David Champion wrote: > * On 05 May 2010, Michael Elkins wrote: > > > > Mutt currently doesn't have a way to change the umask (I guess > > nobody has asked for this before :-). It is hardcoded to 077 when > > Mutt initializes. If you can recompile, the appropriate line t > > change is main.c line 569, at least for unix mbox format. > > This thread has a patch with some discussion of pros and cons: > > http://www.mail-archive.com/mutt-...@mutt.org/msg00382.html > Goodness gracious, what a can of worms! :-) All I wanted to relax the permissions for is to allow a Web application (running as user www-data) to access and display some of my E-Mail messages. I guess I can just do it 'manually' using chmod on the specific folders in question. -- Chris Green
folder permissions - where are they set?
Is there a mutt variable to set default folder (directory and file) permissions when saving/copying messages? My umask is 022 so files and directories created outside of mutt are mostly readable by any user (which is what I want). However mail folders created by mutt are only readable by me - how can I change this? I've searched through the documentation for words like 'permission' and 'chmod' but can't find anything relevant. -- Chris Green
Re: Can I set Return-Path: somehow in a message?
On Fri, Mar 05, 2010 at 02:17:04PM +0100, Christoph Ludwig wrote: > Hi, > > On Fri, Mar 05, 2010 at 11:37:15AM +0000, Chris G wrote: > > I subscribe to mailing lists as c...@isbd.net rather than my real local > > E-Mail, mail for that address is auto-forwarded from the server where > > it arrives to my local mailbox. This allows me to easily transfer all > > my mailing list mail to another delivery address if I need to. > > > > However I have a problem with one mailing list I'm trying to > > unsubscribe from, it's one where you send a messages to an unsubscribe > > address and then a confirmation. The trouble is that it insists on > > using my Return-Path: rather than either the From: or Reply-To: > > address so I can't get it to unsibscribe c...@isbd.net. > > > > Is there any way that I can get mutt to set Return-Path: so that the > > mailing list software talks sense to me? Or is Return-Path: set by > > the SMTP server somewhere? I.e. if I *do* set Return-Path: with mutt > > by editing the outgoing mail will it survive? > > > > (N.B. this is the *only* mailing list where I have ever had this > > problem, in addition it doesn't have a web interface so I can't do it > > that way either) > > I had a similar issue with the Apache Axis mailing lists. It worked as > soon as I set the envelope sender [1] to match the From: address. Of > course, this may be affected by the way you hand over your emails to > your MTA. I use mutt's built-in smtp submission client. > Aha, thank you, that may well be what I need. -- Chris Green
Can I set Return-Path: somehow in a message?
I subscribe to mailing lists as c...@isbd.net rather than my real local E-Mail, mail for that address is auto-forwarded from the server where it arrives to my local mailbox. This allows me to easily transfer all my mailing list mail to another delivery address if I need to. However I have a problem with one mailing list I'm trying to unsubscribe from, it's one where you send a messages to an unsubscribe address and then a confirmation. The trouble is that it insists on using my Return-Path: rather than either the From: or Reply-To: address so I can't get it to unsibscribe c...@isbd.net. Is there any way that I can get mutt to set Return-Path: so that the mailing list software talks sense to me? Or is Return-Path: set by the SMTP server somewhere? I.e. if I *do* set Return-Path: with mutt by editing the outgoing mail will it survive? (N.B. this is the *only* mailing list where I have ever had this problem, in addition it doesn't have a web interface so I can't do it that way either) -- Chris Green
Re: Bounce message from a different from address.
On Tue, Feb 23, 2010 at 09:34:51AM +0900, Horacio Sanson wrote: > > I send a long email to a mailing list but after sending it I realized I > send the email using the wrong from: address. Of course the message got > bounced > back because that address is not registered in the mailing list. > > Now this should be easy to do but I have not found a simple way to > resend the message with a different from: address. The message is stored > in my Sent folder but using the bounce function on it asks me to input a > new destination (to:) address but what I want is to change the from: > address and resend the message intact as it is. > > How to achieve this feat? > I sometimes do this and haven't found an easy answer. What I usually do is forward the mail (either the bounce or from my sentmail folder) and E[dit] it to remove the unwanted bits resulting from forwarding. A b[ounce] command with the ability to change the From: address would be really useful. -- Chris Green
Re: Strange Characters
On Tue, Feb 16, 2010 at 05:46:58PM -0500, Chuck Smith wrote: > This is my first week of using MUtt and so far I love it! I have been doing a > lot of reading and configuring and clearly can see the power of the Mutt. > > I have a interesting displying issue that I would like to sort out but it > appears to only come from my one persons e-mail address from MS Exchange 6.5 > Mailer. For some reason, other than its Microsoft, the is a character ( ^M ) > at the end of each line. I am assuming it is a hard return. I have saved the > message in a text file (US-ASCII) and the characters do not exist. > > I am curious where this character comes from and if there is any way to have > Mutt hide it or filter it out. > The character that shows up as ^M is a Carriage Return, Microsoft's conventional line ending is Carriage Return *and* Linefeed whereas Unix/Linux and all related systems use only Linefeed to terminate lines. Usually the ^M characters get filtered out along the way but obviously in this one case that's not happening. I seem to remember there is a mutt workaround to make the ^M disappear but someone else will have to enlighten you on that front. -- Chris Green
Re: Is there a command line way to open a specific mail message?
On Thu, Feb 04, 2010 at 08:23:07PM +0100, Christian Brabandt wrote: > Hi Chris! > > On Do, 04 Feb 2010, Chris G wrote: > > > One can go straight to a specific mailbox with something like:- > > > > mutt -f =boating/buyOurBoat/fredMolina > > > > but is there a way to open a specific mail message in that mailbox > > (from the command line)? > > This should work and should open the second message: > mutt -f ~/mailbox -e 'push 2' -e 'exec display-message' > Ah, 'push' some CRs, makes sense, thanks. -- Chris Green
Is there a command line way to open a specific mail message?
One can go straight to a specific mailbox with something like:- mutt -f =boating/buyOurBoat/fredMolina but is there a way to open a specific mail message in that mailbox (from the command line)? -- Chris Green
Re: How to save 'what you see' as a file?
On Tue, Feb 02, 2010 at 10:37:35AM +, Toby Cubitt wrote:
> On Tue, Feb 02, 2010 at 09:34:17AM +0100, Christian Brabandt wrote:
> > On So, 31 Jan 2010, Chris G wrote:
> >
> > > Is there any fairly straightforward way to save what you see in the
> > > mutt pager as a file? I want to record some E-Mail as files for
> > > another application and what I need to do basically is save what I can
> > > see on the screen as a file which I can name.
> >
> > Besides decode-copy -C, I sometimes simply pipe the message through
> > cat. You should set pipe_decode for that.
>
> Perhaps I'm misunderstanding the original question, but as no one's yet
> pointed it out...
>
> If you want to save the text of a message (i.e. the part displayed in the
> mutt pager), you can hit "v" to view a list of message parts, then "s" to
> save the part containing the message itself to file. (Assuming default
> key bindings.)
>
That still includes all the headers though doesn't it? Ah, no it
doesn't it includes *no* headers, not quite what I want, I *do*
want what ignore/unignore show me.
> Despite what you might think from the name of the command bound to "v"
> ("view-attachments"), this command displays all message parts, including
> the message itself. (I recommend reading up on mutt's mime handling if
> you want to understand this in more depth.)
>
> HTH,
>
> Toby
> --
> Dr T. S. Cubitt
> Quantum Information Theory group
> Department of Mathematics
> University of Bristol
> United Kingdom
>
> email: ts...@cantab.net
> web: www.dr-qubit.org
--
Chris Green
Re: How to save 'what you see' as a file?
On Tue, Feb 02, 2010 at 09:34:17AM +0100, Christian Brabandt wrote: > Hi Chris! > > On So, 31 Jan 2010, Chris G wrote: > > > Is there any fairly straightforward way to save what you see in the > > mutt pager as a file? I want to record some E-Mail as files for > > another application and what I need to do basically is save what I can > > see on the screen as a file which I can name. > > Besides decode-copy -C, I sometimes simply pipe the message through > cat. You should set pipe_decode for that. > I didn't know about decode-copy, that might well be useful. -- Chris Green
Re: How to save 'what you see' as a file?
On Mon, Feb 01, 2010 at 04:45:16AM +0800, Jostein Berntsen wrote: > On 31.01.10,17:12, Chris G wrote: > > Is there any fairly straightforward way to save what you see in the > > mutt pager as a file? I want to record some E-Mail as files for > > another application and what I need to do basically is save what I can > > see on the screen as a file which I can name. > > > > > > If you use screen, you can use the hardcopy function. Very convenient > and quick. > Thanks, I'd sort of forgotten about 'screen'. -- Chris Green
Re: How to save 'what you see' as a file?
On Sun, Jan 31, 2010 at 06:26:01PM +0100, René Clerc wrote: > * Chris G [31-01-2010 17:12]: > > > Is there any fairly straightforward way to save what you see in the > > mutt pager as a file? I want to record some E-Mail as files for > > another application and what I need to do basically is save what I can > > see on the screen as a file which I can name. > > If you want to save only what you can see on the screen, I would > suggest using straightforward copy/paste functionality. > That is one approach but it feels like there should be easier ones. -- Chris Green
How to save 'what you see' as a file?
Is there any fairly straightforward way to save what you see in the mutt pager as a file? I want to record some E-Mail as files for another application and what I need to do basically is save what I can see on the screen as a file which I can name. -- Chris Green
Re: Mutt doesn't write change to local maildir automatically?
On Fri, Jan 29, 2010 at 11:54:21AM +, chombee wrote: > On Sat, Jan 23, 2010 at 05:23:42PM +0100, Michael Tatge wrote: > > * On Sat, Jan 23, 2010 02:20PM + chombee (chom...@lavabit.com) muttered: > > > I've noticed that mutt doesn't seem to write changes to my local > > > maildirs until I hit $ or change maildirs. Is there a way to get it to > > > automatically write changes to a local maildir? > > > > Simply put - no. > > You could write macros that do [someaction] eg. > > but that's obviously dangerous. > > Ah well, I'll just have to get used to pressing $. I'm kind of surprised > that mutt doesn't automatically save changes after a timeout, as in the > autosave feature of most text editors, although come to think of it only > GUI text editors do that. > I prefer the way it is, in fact I sometimes depend on it, I delete a mail and then (before leaving the mailbox) decide I want to save it. -- Chris Green
Re: subscribe
On Wed, Jan 20, 2010 at 03:05:29PM +, Chris G wrote: > Will the mutt list allow attachments - I'll try, they're not very big > so I'm sure they won't hit any size restrictions. > It does allow attachments! :-) Just a bit more information, the format of the filter file, here's the top of the file:- # # # Mail filterfile, used to generate Mutt aliases and for filtering mail into mailboxes # # The mutt aliases are the 'Name' in the first column, mail to the 'Name' will # be sent to the "To/CC matching string". # # Any mail received which has a To: or Cc: which matches the "To/CC matching string" # will be put in a mailbox 'Name' in directory 'Dir' under ~/Mail. To allow for a # couple of awkward mailing lists (one is ixion) which seem to use two different # To: addresses there are second entries with the same 'Name', only the first will # work as the mutt alias but both entries will put mail in the right list mailbox. # # Name Dir To/CC matching string Strip from subject alugLi m...@lists.alug.org.ukALUG audacityLi audacity-us...@lists.sourceforge.net Audacity-users BHS Li bhs-suff...@yahoogroups.co.uk BHS-Suffolk campug Li cam...@googlegroups.com daboLi dabo-us...@leafe.com dabo-users dbamain 7d dbam...@lists.shire.net dbamatters Li dbaassociationmatt...@lists.shire.net digikam Li digikam-us...@kde.org Digikam-users -- Chris Green
Re: subscribe
On Wed, Jan 20, 2010 at 09:44:25AM -0500, Tim Gray wrote:
> On Wed 20, Jan'10 at 2:11 PM +0000, Chris G wrote:
> >I can upload/attach the scripts if anyone is interested, getAliases.py
> >and getLists.py are trivial but there's a bit more to the mail
> >filtering one.
>
> I wouldn't turn down the chance to see them, but they should be easy
> to implement.
>
> However, what does your filtering one do that procmail doesn't? I
> guess it saves you from editing your procmail setup every time you
> add a mailing list as well... I'd be interested in seeing that one
> for sure.
You've hit the nail on the head! :-) It's like procmail but driven
from the same 'configuration' file as getAliases.py and getLists.py.
Will the mutt list allow attachments - I'll try, they're not very big
so I'm sure they won't hit any size restrictions.
--
Chris Green
#!/usr/bin/python
import sys
#
#
#
#
home = "/home/chris"
filtfile = home + "/.mutt/filter"
#
#
# Get mailing lists from filter file
#
f = open(filtfile, 'r')
for ln in f:
if ln[0] == '#':# ignore comments
continue
#
#
# split the line into fields
#
fld = ln.split()
tocc = fld[2]
if ("/" in tocc): # / in field indicates there's a subject match too
x = tocc.split("/")
tocc = x[0]
sys.stdout.write("alias ")
sys.stdout.write(fld[0] + " ")
sys.stdout.write(tocc + "\n")
#!/usr/bin/python
import sys
#
#
#
#
home = "/home/chris"
filtfile = home + "/.mutt/filter"
lastNm = ""
#
#
# Get mailing lists from filter file
#
f = open(filtfile, 'r')
for ln in f:
if ln[0] == '#':# ignore comments
continue
#
#
# split the line into fields
#
fld = ln.split()
tocc = fld[2]
if ("/" in tocc): # / in field indicates there's a subject match too
x = tocc.split("/")
tocc = x[0]
#
#
# If it's a mailing list (destination directory is "Li") and it isn't
# a second address for the same mailing list then output the address
#
if fld[1] == "Li" and fld[0] != lastNm:
sys.stdout.write(tocc + " ")
lastNm = fld[0]
#!/usr/bin/python
#
#
# Mail filtering script, replacement for the perl version
#
import email
import mailbox
import os
import sys
import time
#
#
# Redirect any exceptions to a file
#
sys.stderr = open("/home/chris/tmp/mail.err", 'a')
#
#
# Some constants (i.e. configuration)
#
home = "/home/chris"
logfile = home + "/tmp/mail.log"
filtfile = home + "/.mutt/filter"
mldir = home + "/Mail/"
indir = mldir + "In/"
def log(s):
lf = open(logfile, 'a')
lf.write(s + "\n")
lf.close()
#
#
#
#
mbName = ""
#
#
# Get the message from standard input and extract the To:, Cc: and
# Subject: headers
#
m = email.message_from_file(sys.stdin)
msgcc = m.get("Cc", "unknown").lower()
msgto = m.get("To", "unknown").lower()
msgsb = m.get("Subject", "unknown")
#
#
# See if it's in our filter file
#
f = open(filtfile, 'r')
for ln in f:
if ln[0] == '#':# ignore comments
continue
#
#
# split the line into fields
#
fld = ln.split()
nm = fld[0] # name/alias
dd = fld[1] + "/" # destination directory
if ("/" in fld[2]): # / in field indicates there's a subject match too
x = fld[2].split("/")
tocc = x[0].lower()
sb = x[1].lower()
else:
tocc = fld[2].lower()
sb = ""
#
#
# see if the filter line matches the message
#
if (tocc in msgcc or tocc in msgto) and (sb in msgsb.lower()):
mbName = mldir + dd + nm
if len(fld) > 3:
m.replace_header("Subject", msgsb.replace('[' + fld[3] + ']', ''))
break
log("From: " + m.get("From", "unknown"))
log("Destination is: " + mbName)
log("\n\n")
#
#
# if destination mb name hasn't been set yet then set to the default
# inbox
#
if mbName == "":
mbName = indir + "inbox"
#
#
# set up the mb for adding the new message, will create if it doesn't exist
#
dest = mailbox.Maildir(mbName, factory=None)
dest.add(m) # add the new message
dest.flush()
Re: subscribe
On Wed, Jan 20, 2010 at 08:29:11AM -0500, Tim Gray wrote: > On Wed 20, Jan'10 at 10:09 AM +0000, Chris G wrote: > >You need to set up an alias for the list in order to be able to use a > >shorted name for it when composing new mail. > > Yeah, I just never bothered with that step since I usually only > reply to lists. > > >I have a simple text file where I keep a list of all the mailing lists > >... > >All this means that when I subscribe to a new mailing list I just add > >it to the text file rather than having to edit three or four different > >places. > > Brilliant bit with the scripts. I use some scripts to automatically > generate some other bits of my muttrc, but didn't think of this way. > Thanks! I can upload/attach the scripts if anyone is interested, getAliases.py and getLists.py are trivial but there's a bit more to the mail filtering one. -- Chris Green
Re: Simple Mutt with Eee PC 701.
On Wed, Jan 20, 2010 at 11:18:54AM +0900, Horacio Sanson wrote: > On Sun, Jan 17, 2010 at 12:57:29PM +0100, Brian Durant wrote: > > Dale A. Raby wrote: > > >I'm no expert, but I'm pretty sure you need the following in your .muttrc > > >file in order to access a gmail account via IMAP: > > > > > >set folder = "imaps://imap.gmail.com:993" > > >set spoolfile = "+INBOX" > > >set postponed="+[Gmail]/Drafts" > > > > > >set header_cache= /home/dale/.mutt/cache/headers > > >set message_cachedir= /home/dale/.mutt/cache/bodies > > >set certificate_file= /etc/pki/tls/certs/ca-bundle.crt > > And I also need to add an instance of the following for each of my > > IMAP accounts? > > > > Managing multiple accounts with Mutt can be a little daunting... some people > simply use a different Mutt instance for each account in a screen window or > implement some very obscure macros to switch between accounts. > It's easier if you use some sort of 'intermediary' - either someting like fetchmail on the machine where mutt runs or a mail collection service (Gradwell for example can do it). -- Chris Green
Re: subscribe
On Wed, Jan 20, 2010 at 01:05:27AM -0500, Tim Gray wrote: > On Tue 19, Jan'10 at 9:41 PM -0800, Freeman wrote: > >Then "mutt users" is a subscribed lists *and* a known list. > > > >Should not I therefore be able to type a distinct part of the mailing list > >in a To field? > > I think it affects the status display of a message in the index AND > lets you type 'L' to respond to the list. > > As far as calling up a list's address while composing from scratch, > I don't know how to do that. I query lbdb which is set up to add > any address which I've sent mail to, so most of my mailing list > address are already there. You need to set up an alias for the list in order to be able to use a shorted name for it when composing new mail. I have a simple text file where I keep a list of all the mailing lists I'm subscribed to. Each mailing list has an alias which becomes the mutt alias for sending *and* the destination mailbox for mail from the list. A couple of scripts use the contents of the text file to actually provide what mutt needs in .muttrc and to do the sorting of incoming mail. So the section of the file with the mutt list in it is:- leafnodeLi leafnode-l...@dt.e-technik.uni-dortmund.de linux-usb Li linux-...@vger.kernel.org muttLi mutt-users@mutt.org palmLi p...@copilotconsulting.comPalm Column 1 is the alias and the destination mailbox, column 2 is a destination directory, column 3 is the mailing list address and column 4 is an otional string to be removed from the Subject:. In my muttrc I have:- source getAliases.py| lists `getLists.py` subscribe `getLists.py` Where getAliases.py and getLists.py are simple python scripts for extracting the required information from the text file. There is a third (more complex) python script called from my .forward which routes incoming mail to the appropriate places. All this means that when I subscribe to a new mailing list I just add it to the text file rather than having to edit three or four different places. -- Chris Green
Re: mutt inside emacs (was color configuration setup)
On Sun, Jan 17, 2010 at 07:01:03PM -0400, Monte Stevens wrote: > On Sun, Jan 17, 2010 at 10:42:48PM +0100, Jeffrey Ratcliffe wrote: > > > > What is the advantage of running mutt within emacs? > > Short answer: > You don't have to navigate to Emacs (server) when editing a message. > > Longer answer: > I have my Mutt editor set to "emacsclient" and I have Emacs' server > running. If I were to edit a message in a non-Emacs environment I'd > have to travel to Emacs to modify the message. So, if I run screen I > would change to the screen that Emacs was running on, if I am in a GUI > environment I'd need to switch to a different window. > > If you have your mutt editor set to "emacs" then there's no need to do > any of this, Emacs should pop up when you edit a message. But then, you > could have multiple copies of Emacs running, whereas with the > server/client arrangement there is only one instance of Emacs. There > should also be a time savings in opening a client versus a new instance > of Emacs. > By the way, and *just* for information, you can do the same with a vi look alike too - [x]vile. So if (like me) you're a died in the wool vi person you can run a 'vi server'. The one I use is (as I said) [x]vile but I *think* you can do it with vim as well. -- Chris Green
Re: Wanted, tool for copying/deleting old messages through a
On Fri, Sep 25, 2009 at 06:12:53PM +0200, Jan-Herbert Damm wrote: > Hello Chris, > > Chris G wrote on 25.09.09: > > Are there any obvious ways either within mutt or using some sort of > > external tool which would allow archiving and/or deletion of messages > > older than a certain date? > > since you are a regular poster this might be old news but are you aware of the > thread named "Archiving" we had in Febuary? Kyle presented a hook that could > possibly help you. > > folder-hook =mutt-users 'push "~r>3m\ > =Archive.mutt-users\ > ~A"' > > Kyle explains how it works in that thread in great detail. > Thanks, I remember that thread now and I've gone and had another look. It too doesn't address the hierarchy that I want to archive (at least if I understand what it's doing it doesn't). I need something like a 'find' but which acts on message dates rather than file dates. I suppose I can use find to negotiate the hierarchy and then use archivemail in the exec part of find but it seems rather clumsy somehow. Maybe I'll just write something in python to do what I want, I already have a little collection of python mail utilities. -- Chris Green
Re: Wanted, tool for copying/deleting old messages through a
On Fri, Sep 25, 2009 at 04:35:46PM +0100, Arthur Dent wrote: > On Fri, Sep 25, 2009 at 04:25:55PM +0100, Chris G wrote: > > On Fri, Sep 25, 2009 at 04:17:58PM +0100, Arthur Dent wrote: > > > On Fri, Sep 25, 2009 at 04:01:28PM +0100, Chris G wrote: > > > > Are there any obvious ways either within mutt or using some sort of > > > > external tool which would allow archiving and/or deletion of messages > > > > older than a certain date? > > > > > > > > My ideal would be a tool that I could run either manually (or maybe > > > > from cron, but that might be a bit daring) which would select all > > > > messages in my ~/Mail hierarchy older than a specified date and move > > > > them to an archive area with the same hierarchy. > > > > > > > > Second best would be a tool which would simply delete such messages as > > > > one could copy the whole hierarchy first. > > > > > > > > It's fairly easy (?) to do such a thing for one mailbox/folder but I > > > > really need to do it for a fairly deep hierachy of messages. Doing it > > > > folder by folder would be painful. > > > > > > I use Archivemail (http://archivemail.sourceforge.net/) to do exactly > > > what you > > > describe. > > > > > > It runs from a nightly cronjob and archives mail older than (in my case) > > > 180 > > > days (roughly 6 months). > > > > > > I use mbox format - I'm not sure about maildir but it works just fine for > > > me! > > > > > I looked at Archivemail but it only archives specified mailboxes > > doesn't it, it won't run down through a hierarchy of mailboxes. My > > hierarchy has 3293 mailboxes in it (even I didn't realise there are > > *that* many until I looked!), I'm not going to archive that lot by > > hand! > > Well I set it up so long ago (we're talking years!) that I've forgotten the > details... > This is my crontab entry: (mind the linewrap) > 50 3 * * * archivemail -o ~/Mail/Archive/ ~/Mail/* ~/Mail/Malware/* > ~/Mail/MLists/* ~/Mail/Admin/* ~/Mail/Misc/* > > Now as it happens none of those top level directories go down beyond 1 level, > but each of them does have several sub-directories, each of which gets > archived as expected. > I guess it's archiving all the folders/mailboxes that are addressed by ~/Mail/MLists/* and similar. I suppose I could do something like that because my hierarchy isn't all *that* deep. I could even use things like ~/Mail/*/* though I'm not sure if that wouldn't catch too much in some cases. > I'll have to look at, or experiment with, deeper levels - sorry I don't know > the answer of the top of my head... > > Regards > > Mark > -- Chris Green
Re: Wanted, tool for copying/deleting old messages through a
On Fri, Sep 25, 2009 at 04:17:58PM +0100, Arthur Dent wrote: > On Fri, Sep 25, 2009 at 04:01:28PM +0100, Chris G wrote: > > Are there any obvious ways either within mutt or using some sort of > > external tool which would allow archiving and/or deletion of messages > > older than a certain date? > > > > My ideal would be a tool that I could run either manually (or maybe > > from cron, but that might be a bit daring) which would select all > > messages in my ~/Mail hierarchy older than a specified date and move > > them to an archive area with the same hierarchy. > > > > Second best would be a tool which would simply delete such messages as > > one could copy the whole hierarchy first. > > > > It's fairly easy (?) to do such a thing for one mailbox/folder but I > > really need to do it for a fairly deep hierachy of messages. Doing it > > folder by folder would be painful. > > I use Archivemail (http://archivemail.sourceforge.net/) to do exactly what you > describe. > > It runs from a nightly cronjob and archives mail older than (in my case) 180 > days (roughly 6 months). > > I use mbox format - I'm not sure about maildir but it works just fine for me! > I looked at Archivemail but it only archives specified mailboxes doesn't it, it won't run down through a hierarchy of mailboxes. My hierarchy has 3293 mailboxes in it (even I didn't realise there are *that* many until I looked!), I'm not going to archive that lot by hand! -- Chris Green
Wanted, tool for copying/deleting old messages through a hierarchy
Are there any obvious ways either within mutt or using some sort of external tool which would allow archiving and/or deletion of messages older than a certain date? My ideal would be a tool that I could run either manually (or maybe from cron, but that might be a bit daring) which would select all messages in my ~/Mail hierarchy older than a specified date and move them to an archive area with the same hierarchy. Second best would be a tool which would simply delete such messages as one could copy the whole hierarchy first. It's fairly easy (?) to do such a thing for one mailbox/folder but I really need to do it for a fairly deep hierachy of messages. Doing it folder by folder would be painful. -- Chris Green
Re: How to remove empty maildir?
On Wed, Sep 23, 2009 at 04:50:56PM +0200, Ionel Mugurel Ciobica wrote: > On 23-09-2009, at 15h 21'53", Chris G wrote about "Re: How to remove empty > maildir?" > > > > > There's no atomic way of checking if all three sub-directories are > > empty so, in the general case, some other process may come along > > and put something in one of the sub-directories after you have > > checked it but before you do the removal. > > Not if you rename them before you do the check (not tested): > The the 'other' application will either recreate them or fall in a heap, neither of which is particularly helpful. > for A in all-mailboxes ; do > cd $A > mv new new-$$ > mv tmp tmp-$$ > mv cur cur-$$ > if [ `find ???-$$ -type f | wc -l` -eq '0' ]; then >if [ -e new ] && [ -e tmp ] && [ -e cur ] ; then > echo "$A was empty but just right now some e-mail arrived." > rmdir ???-$$ >else > echo "$A is empty." > rm -fr ../$A > echo "Ups, $A was empty! Now is gone..." >fi > else > echo "$A has mail." > mv new-$$ new > mv tmp-$$ tmp > mv cur-$$ cur > fi > done > > > > You can also turn off $sendmail when you do the check :-)) > I doubt if it's just sendmail you need to turn off. -- Chris Green
Re: How to remove empty maildir?
On Wed, Sep 23, 2009 at 11:08:52AM -0300, Monte Stevens wrote: > On Wed, Sep 23, 2009 at 09:45:47PM +0800, Wu, Yue wrote: > > The logic I need is: > > > > if maildir A has no mails(new/ tmp/ cur/ are empty) > > rm -r A > > endif > > From http://www.google.com/search?q=bash+test+empty+directory : > > http://www.cyberciti.biz/faq/linux-unix-shell-check-if-directory-empty/ > There's no atomic way of checking if all three sub-directories are empty so, in the general case, some other process may come along and put something in one of the sub-directories after you have checked it but before you do the removal. OK, as long as you know no mail deliveries are going to happen you *can* check new/ tmp/ cur/ are empty and *then* remove the whole maildir. There is also, of course, the possibility that the hierarchy has maildirs within maildirs (is it allowed in 'classic' maildir?) and that adds a whole new set of problems and issues. It's easy with mbox! :-) -- Chris Green
Re: How to remove empty maildir?
On Wed, Sep 23, 2009 at 08:21:35AM -0500, Kyle Wheeler wrote: > On Wednesday, September 23 at 08:16 PM, quoth Wu, Yue: > >Hi, list, question is how to use some commands(i.g. shell commands) to remove > >the empty maildirs, i.e. no any file in maildirs' new/ cur/ and tmp/? > > If you know it won't be re-created or delivered to while you're > fussing with it, you can just use `rm -r maildirname` or even `rmdir > maildirname/new maildirname/cur maildirname/tmp maildirname` > That assumes you know its name, with maildir it's quite possible that it *won't* have the name you expect, it could well be a long name with the whole virtual directory/folder hierarchy prepended. -- Chris Green
Re: Storing mbox inside of maildirs
On Mon, Sep 21, 2009 at 02:46:47AM -0400, James Michael Fultz wrote: > What are opinions on using a maildir for both $spoolfile and > $folder with extended maildir subfolders *and* storing mbox > folders inside? Does this seem to be a Really Bad Idea or, does > anyone else see an appeal in having a single storage point for > folders? > I've certainly used mixed maildir and mbox in the same hierarchy at times and it seems to work OK. > A little testing has found a configuration like the following to > work. I'm curious if anyone thinks that problems may arise with > such a setup. > > # $spoolfile is a maildir > set spoolfile=~/.maildir > set folder=~/.maildir > # $mbox, $record, and $postponed are to be mbox format > set mbox=+mbox > set record=+sent > set postponed=+drafts > > # create mbox > set mbox_type=mbox > > # makes folder browser neater > set mask="!^\\.[^.]|^(cur|new|tmp)$" > > # these would be maildir folders > mailboxes ! > mailboxes =.some-list > mailboxes =.another-list > > # these would be mbox folders > fcc-save-hook myfriend =myfriend > save-hook otherstuff =otherstuff > -- Chris Green
Re: The MBOX file paradigm
On Fri, Sep 04, 2009 at 04:09:56PM -0400, Dave Dodge wrote: > On Fri, Sep 04, 2009 at 06:27:09PM +0100, Chris G wrote: > > anyway when does one want to edit messages, it's not something I've > > ever wanted to do. > > I used to have the same opinion before I had a mailer that made it so > easy. With mutt I do occasionally edit messages: > > - to use a message in my inbox as a primitive to-do list, or for > notes, or to hold a list of URLs that I want to remember to view > at some later time. > > - to remove uneeded attachments when archiving a discussion thread. > For example a co-worker produces some software my own project > depends on, and has lately been mailing me prerelease versions for > testing. I want to keep the discussion itself, but I don't need > all of the attachments since most of them have been superceded by > later versions. > I too have *occasionally* edited messages but it's really so infrequently that I'd not use it as a criterion for choosing a mailox format! :-) -- Chris Green
