Re: Problem with MBX INBOX
Does mailutil check comes back reporting no errors and the correct number of messages? John Landamore School of Mathematics & Computer Science University of Leicester University Road, LEICESTER, LE1 7RH [EMAIL PROTECTED] Phone: +44 (0)116 2523410 Fax: +44 (0)116 2523604 > >Folks, > >I have a strange problem with an MBX format INBOX. It contains 6618 messages but only the most recent 33 are being displayed by >PINE or any other clients I've tried. Connecting to the INBOX does not result in any error messages so I don't really have >anything to go on to make a manual repair. There doesn't appear to be a problem with the message immediately prior to the first >one being displayed. Any advice on how to proceed will be gratefully received. > >Thanks, > > Clive McDowell > >Information Services >The Queen's University of Belfast > >-- >-- > For information about this mailing list, and its archives, see: > http://www.washington.edu/imap/c-client-list.html >-- >
rsync for backup
I'd be interested in comments on/flaws in the following. We run a "warm standby" mailsystem, i.e. one that is fully configured and "ready to go" if the main hub fails. The only thing is that the user mail files are always at least a day out of date, having been created from the previous days backup. What problems am I likely to encounter if: I run rsync on the standby with the main hub as the source. I then run mailutil check against the mail files on the standby and re-rsync any that don't check clean. We're talking 6GB+ of mail files, a large part of which don't change (e.g. a 30Mb mailbox which has only 1 or 2 messages added to it), so I'm trying to avoid doing a mailutil transfer which I believe will duplicate the whole tree. For info; all mail input is handled by postfix/dmail and all mail reading is via UW imap/pop and a c-client based webmailer (prayer from U. Cambridge) Mail is held in mbx format files. Thanks for any insight John Landamore School of Mathematics & Computer Science University of Leicester University Road, LEICESTER, LE1 7RH [EMAIL PROTECTED] Phone: +44 (0)116 2523410 Fax: +44 (0)116 2523604 -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: question about dmail when mailbox over quota
Mark replied: > >On Thu, 18 Dec 2003, J. A. Landamore wrote: >> Many thanks for the information, and apologies for my confusing >> mail. The mail is silently dropped. I thought dmail was hanging from >> the way the log just stopped part way through the attempt by dmail to >> deliver the mail and there was no debug info about it cleaning up. >> However there is no dmail process running and the mailfile is left in an >> intact state. > >Something is suspicious. After the "appending to" message there >should have been either a "delivered to" or a "message delivery failed to" >message, both to stderr and to syslog. I get a "delivered to" message in my syslogs, but not the "message delivery failed to" > >> Also subsequent writes that don't take it over-quota are >> successful. So it's a procmail problem, thanks for the insight. > >Good luck in finding this! The problem has been solved. As Mark said procmail just silently drops mail that isn't delivered successfully unless you tell it to wait. This is done with the w flag on the first line of the recipe i.e :0 becomes :0 w Thanks for all the guidance John Landamore School of Mathematics & Computer Science University of Leicester University Road, LEICESTER, LE1 7RH [EMAIL PROTECTED] Phone: +44 (0)116 2523410 Fax: +44 (0)116 2523604
Re: question about dmail when mailbox over quota
Mark, Many thanks for the information, and apologies for my confusing mail. The mail is silently dropped. I thought dmail was hanging from the way the log just stopped part way through the attempt by dmail to deliver the mail and there was no debug info about it cleaning up. However there is no dmail process running and the mailfile is left in an intact state. Also subsequent writes that don't take it over-quota are successful. So it's a procmail problem, thanks for the insight. I take your point about quotas, but this really is the last line of defense for some very uncooperative users. Hopefully having lost mail and been inconvenienced by this for several days might help him see the light. Thanks again for your help Season's greeting John John Landamore School of Mathematics & Computer Science University of Leicester University Road, LEICESTER, LE1 7RH [EMAIL PROTECTED] Phone: +44 (0)116 2523410 Fax: +44 (0)116 2523604 > >I'm confused. First you say that the mail "is silently dropped" when it >would take the user over quota, then you say that "dmail hangs". Which is >it? > >"Silently dropped" is a known behavior of procmail. You have to do >something to cause an error from the delivery program to be passed back up >to the mail delivery system. I don't know what it is, since I am not a >procmail expert, but it apparently is more than just piping. > >"Hanging" is a different matter. c-client reacts to an appending write() >error (including over-quota) by revoking the append and putting the >mailbox file back to the way it was before. > >Unfortunately, it seems some UNIX variants, once it decides that the file >is in "write error" status, keeps the file descriptor in that status even >after the condition which caused it is corrected. The result is that the >write() to put things back fails again. dmail doesn't know what to do >other than try again, because it doesn't want to leave the file in a >corrupted state. > >So that may be the cause of the hang; dmail is trying to revert the file >back to the way it was before it started the append, but the operating >system keeps on returning error. > >Note that this is supposition based upon empirical observations from third >parties; I have never seen this behavior on any operating system that I >use. > >If this is what is happening, then I don't know of anything (that I am not >already doing) that would make the system let me write into the file >again. > >In my humble opinion,... > >Hard disk quotas are a mistake. Historically, operating systems (all >operating systems, not just UNIX) have *always* made hard disk quotas >problematic for applications. It's not such much that a quota exceeded >error can happen, but rather the variance in operating system behavior >(even in different releases of the same OS) that make it difficult for an >application to recover. > >It is a much more productive strategy to buy enough disk for user's needs. >As the Dilbert cartoon says, "here's a quarter; now you can afford to >double my disk quota." > >To check abusive behavior, soft disk quotas are preferable; allow the mail >to be delivered, but then flag the account to start nagging the user to >get under quota. It may be necessary to have a second level of flagging >that stops mail delivery when if the user defies the nags and stays over >quota, but never use hard disk quota. > >-- Mark -- > >http://staff.washington.edu/mrc >Science does not emerge from voting, party politics, or public debate. >Si vis pacem, para bellum. >
question about dmail when mailbox over quota
I am using dmail with postfix and procmail to deliver to mbx format mailboxes. There is a maximum mailbox size set in postfix, and before that is reached everything is fine. However when dmail tries to deliver a mail to an INBOX that would take it overquota the mail just gets silently dropped. By switching on debugging for dmail I get: for an INBOX with plenty of space procmail: Notified comsat: "testfred@:/usr/local/bin/dmail -D" >From [EMAIL PROTECTED] Wed Dec 17 16:25:18 2003 Subject: test number 2 Folder: /usr/local/bin/dmail -D 718 procmail: Executing "/usr/local/bin/dmail,-D" delivering to testfred+INBOX Verifying safe delivery to /home/testfred/INBOX mbx appending to #driver.mbx/INBOX (file /home/testfred/INBOX) delivered to /home/testfred/INBOX Verifying safe delivery to /home/testfred/INBOX for an INBOX where the message will take it over quota procmail: Notified comsat: "testfred@:/usr/local/bin/dmail -D" >From [EMAIL PROTECTED] Wed Dec 17 16:28:00 2003 Subject: What happens now Folder: /usr/local/bin/dmail -D 747 procmail: Executing "/usr/local/bin/dmail,-D" delivering to testfred+INBOX Verifying safe delivery to /home/testfred/INBOX mbx appending to #driver.mbx/INBOX (file /home/testfred/INBOX) and there it hangs. Any ideas anyone? Thanks in advance John Landamore School of Mathematics & Computer Science University of Leicester University Road, LEICESTER, LE1 7RH [EMAIL PROTECTED] Phone: +44 (0)116 2523410 Fax: +44 (0)116 2523604 -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
dmail
Sorry if this has been answered in previous mails but I cannot get into the archives either thru anon ftp or anon imap. What is the reason why "dmail +" will create INBOX if doesn't exist but won't create ? Thanks John Landamore Univeristy of Leicester -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
