On Monday 06 February 2006 19:22, John Simpson wrote: > On 2006-02-06, at 1620, Jeremy Kitchen wrote: > >> i'm thinking about possibly including the qmailtap patch in my > >> combined > >> patch file. however, the biggest problem i've seen from people using > >> QUEUE_EXTRA is that they set up loops when they try to send the > >> copies to > >> a remote address, and because the copy has to traverse the queue, > >> it gets > >> logged and sent to the monitor address... and THAT copy gets > >> logged, and > >> so forth... > > > > that's not a problem with QUEUE_EXTRA, that's a problem with the > > person not > > reading how to properly use QUEUE_EXTRA. Adding 'loop detection' > > code into > > this drastically complicates the process and doesn't add any real > > value. > > that's what i was afraid of. > > i understand the problem, you understand the problem, and i'm sure > anybody who thinks about it for more than ten seconds will understand > it as well... but because my combined patch has been adopted by > "qmailrocks", if i were to add inter7's qmailtap patch (or any other > QUEUE_EXTRA patch) i would be flooded with question from "typical > qmailrocks users" about why their server is sending multiple copies > of every message and killing their server.
So, instead of telling people to RTFM (which is what they should be doing anyways) we continue down the qmailrocks path and give the user even more stuff they have no clue about. > i'm sure you of all people know that qmailrocks has a reputation for > being "qmail for dummies". the only reason i joined their list is > because they're using my combined patch- before i joined their list i > was getting several messages per day from qmailrocks users who > couldn't figure something-or-other out, and emailed me directly > because i "wrote" the patch so i must be an expert who's willing to > offer free consulting services to every random person on the internet... I would have directed them either to the qmailrocks mailing list or to a webpage that outlines my support fees. > the question came up on the qmailrocks list, from a user in europe > somewhere, who is legally required to keep copies of every message > sent or received by every employee at their company. you and i know > that QUEUE_EXTRA is the core of how to make this happen, but trying > to explain all of the details to somebody who has no idea what a > queue is, let alone how to tell if a given delivery instruction will > result in another message being added to it... i'm sure you can > imagine the aggravation waiting along that road. that person isn't competent to run a mail server then, in my opinion. They should hire a consultant to set it up for them. > my hope was that inter7's "qmailtap" patch would have some kind of > loop detection built in, so that this doesn't happen and i can add it > to my combined patch, knowing that i'm not going to have people > setting up server-killing loops. if it does, then fine, but I don't think it's a useful feature. These are loops that the user should be avoiding from the beginning, it's not like we're talking about cross-server loop detection. > my answer to this question is usually "i'm not going to add it to my > combined patch- if you can add it, more power to you" but i figured > in the interest of fairness i would at least ask the inter7 guys > about it... the qmailtap web page lists this as one of the places to > discuss qmailtap, and i know several of the inter7 guys are on this > list. maybe one of them will have better news... I can't speak for Inter7, but I'm against it, personally. -Jeremy -- Jeremy Kitchen ++ [EMAIL PROTECTED] In the beginning was The Word and The Word was Content-type: text/plain -- The Word of Bob.
Description: PGP signature