On Wed, 14 Jan 2004, Mitch \(WebCob\) wrote: > 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?
Yes, you did. And here's my thoughts on the matter: leave maildrop as-is. maildrop's manpage is very clear that it "delivers" to a: a mailbox (a file) b: a Maildir (a special set of directories) c: a process When writing maildrop stuff, you need to ask yourself: am I writing to a mailbox, a Maildir, or a process? If it is none of these things, use the tools available on every 'nix box to make it so, or give up. I routinely use socat (a do-everything tool that kicks netcat all over the floor) to "tie" different types of I/O together, files, processes, sockets, FIFOs, tty's, you name it. If you need to write to a process, use the | (pipe) command. I can certainly see where you might want maildrop to be a bit "smarter", but a) you can't possibly cover all of the cases where maildrop needs more, special smarts (block vs. char devices, sockets, FIFOs, blah blah blah) b) knowing ahead of time that maildrop *only* delivers to one of 3 types (MBox, Maildir, or Process) makes things *much* simpler. Sometimes, choice is bad. c) using processes to form your delivery, you can do just about anything. This is probably not what you wanted to hear, but it's how I feel. -- 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
