Okey dokey - from the top ;-) I first was trying to simply do "to /dev/null".
I realized this didn't work, but to "|cat >/dev/null" did The reason (from the logs) was that maildrop was treating /dev/null like an mbox file. iirc, procmail doesn't lock unless you force it to (at least it didn't a while back) - which meant it could deliver to /dev/null no problem, and could do an mbox file without conflict IF you remembered to add the lock call (failing to do so seems to work but can result in mail loss during simultaneous deliveries, so kudos to Sam for eliminating that problem... What I realized from this is that how maildrop flock's everything is what prevents it from delivering to a file socket or a character device. If a test were done prior to the lock call to see if the handle points to a socket or a device, and if so skip the lock, then maildrop could communicate with filter daemons directly with no need to have a calling stub (like spamc) run interferance. So what started as a search for a way to sh!tcan mail, has lead me to a curiousity about what some of the more experienced users might think about enhancing the locking smarts in procmail to allow direct connection to file sockets & character devices - could open some doors... Did I explain that better? m/ > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jon > Nelson > Sent: Wednesday, January 14, 2004 1:18 PM > Cc: Courier Users List > Subject: RE: [courier-users] deleting messages reviewed... > > > On Wed, 14 Jan 2004, Mitch \(WebCob\) wrote: > > ... > > > You were against a "special case" patch for dev-null - which I > agree is not > > needed now that I know the "one true way"(tm) > > > > What I was pondering was a general patch which would make > communicating with > > filter daemons (listening on file sockets or char devices) > possible - and > > that would be to skip the locking in these cases where it has > no point - it > > would have the side effect of allowing /dev/null to work, but > that's not my > > point here... It would allow direct delivery to things like > spamd without a > > stub spamc program to manage the socket. > > And maildrop does some kind of locking (flock?)? > I apologize, I'm coming into this discussion at the end. > Please describe what you are trying to do (specifically), what you > think the problem is, what maildrop's behavior is, etc... > > -- > Ensign Walnut approaches Dr. Crusher with caution... > > Jon Nelson <[EMAIL PROTECTED]> > C and Python Code Gardener > > > ------------------------------------------------------- > This SF.net email is sponsored by: Perforce Software. > Perforce is the Fast Software Configuration Management System offering > advanced branching capabilities and atomic changes on 50+ platforms. > Free Eval! http://www.perforce.com/perforce/loadprog.html > _______________________________________________ > courier-users mailing list > [EMAIL PROTECTED] > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users > ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
