Hey Adam. We are draggin this a little off topic, but I guess it is slightly relavent as when tmda integrates maildir support, the issues will probably be relavent....
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Adam Morley > Sent: Wednesday, February 25, 2004 2:26 PM > To: [EMAIL PROTECTED] > Subject: Re: View and release pending messages through an IMAP server? > > > On Tue, Feb 24, 2004 at 10:11:16PM -0800, Mitch (WebCob) wrote: > > I think what he's after is the auto whitelist angle, in which > case, a simple > > way to do it would be to implement an approved folder with a > cron job that > > scans the folder and adds the from addresses - perhaps dumping > the mail to > > inbox on completion... if you want to be efficient, make your program a > > daemon tied into FAM, so that it doesn't have to scan, just add > watches for > > the folders. > > > > FAM seems to be pretty common for imap maildir support (courier does it > > quite nicely) so it would already be there and potentially not > even increase > > load as the folders may already be actively watched. > > I am after an auto-whitelist function. Something along these lines: > > create_pending_msg() runs with PENDING_DIR set to > ~/.Maildir/.TMDA.pending/cur/ > User "flags" a pending message to signal release and whitelist of > message (flags defined in next line) > FAM watches ~/.Maildir/.TMDA.pending/cur/ for changes, > specifically "\Flagged" being set (RFC2060, 2.3.2) > FAM calls tmda-pending -b -r -W <message> when > ~/.Maildir/.TMDA.pending/cur/<flagged message> occurs > Maildir programs such as courier IMAP MAY object to non-standard naming conventions for the files - there are flags and statuses encoded there... also, you should deliver to new, the client reading the info triggers the move to cur. The client may fail to notice the new mail if they are dropped into cur unless you force it to change folders. > - I haven't looked seriously at FAM, all I know is that it > watches dirs/files, so I don't know if it will do what I want. > This is rough thinking about how I think it should work > - I know I shold wait for Maildir enabled pending dir to be > "safe," but I think when TMDA gets pending as Maildir, I won't > have to change anything (I think) FAM is a daemon and a library to register watches and receive notifications from that daemon. On Linux it is tied into a kernel notification system. On FreeBSD, the process is emulated as the developers of FAM haven't got around to adding kqueue (FreeBSD) support. When NOT tied to the kernel, FAM is still more efficient that manual scans, as they are centralized and serialized... Adding FAM support to courier and enabling enhanced idle allows instant detection of new mail or modified message files especially useful when multiple users access a maildir. > I have three questions: > > 1. is the code for create_pending_msg() safe enough to deliver > straight to cur/ ? I know a Maildir delivery method is in the > works, but I'm not up to speed on how important it is to have > "safe" maildir deliveries. Ie: system crash during delivery is > the only time it would matter to me or are there other times? > 2. Is my plan bad? Do I need to modify it to stay in line with > TMDA's planned implementation of pending as Maildir? (I take it > that such a feature would come out in 1.1 and eventually make it > into 1.2?) > 3. Do I need FAM compiled into courier-imap? I haven't played > with FAM, so I thought I would ask. adding FAM will speed up new message notification, but isn't nessecary for all programs to have FAM so one program (yours) can benefit. > And one statement: > > I looked at the python docs and it doesn't look like there are > maildir functions in python 2.2 or 2.3 (I could be wrong, its the > first time I've looked at python docs) so the added maildir > support would require writing something. Maildir's are pretty simple, even the quota management files, etc. > ---slightly ot--- > How much overhead is there in this FAM thing? Not that I care > much practically (six users on a dual pIV 3ghz, SAN attach), but > more curious about its performance. > ---slightly ot--- None if you need it - having one process monitor file changes vs. many should in theory always be better. If it has the benefit of kernel notification it involves no polling. > Thanks! no worries. m/ _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
