Re: [vchkpw] qmailtap question
On 2006-02-07, at 0214, Adam Ossenford wrote: I was able to integrate your qmail-1.03-jms1.6c patch and the qmail tap patch successfully. did you do mine first and then qmailtap, or the other way around? did the patch apply cleanly or were there any rejects which had to be handled manually? It compiled and ran with the tap functionality. However, I could not give any testimonial about performance loss due to QUEUE_EXTRA because the test server never reached production. I understand you have released an updated version of your combined patch. I haven't had an opportunity to attempt combining the two once again. If the server isn't high volume would the functionality outweigh the performance loss due to the drawbacks with QUEUE_EXTRA? if the QUEUE_EXTRA recipient is local, and the .qmail file controlling it simply delivers to a maildir, then there shouldn't be much of a performance hit at all. however, my question isn't so much about performance as it is about whether or not it's safe to integrate the qmailtap patch into my combined patch, knowing that this will dump it on a lot of qmailrocks users. i know it's going to cause questions, i was hoping that somebody would tell me that it won't kill servers by setting up an endless loop when somebody sets up a tap whose target causes the tapped copy of the message to match the same rule again. there's also the fact that i haven't actually compiled the qmailtap stuff, i honestly don't know if it's a bigger badder QUEUE_EXTRA patch or if it's the same QUEUE_EXTRA idea, pointing to a .qmail file that runs an external qmailtap program which forwards the message if it finds a matching rule, or drops it if no match is found. i haven't had the time to play with it myself, i was hoping somebody here had used it and could answer the question without my having to build a test server and try to break it. thanks for letting me know it works with 6c... this was the first version to include the EXT_TODO patch. i had somebody on the qmailrocks list tell me that he had compiled it, but couldn't use it because it was apparently causing qmail-send to segfault. now i know that it should work, maybe he did something funky when combining the patches or something... -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] qmailtap question
did you do mine first and then qmailtap, or the other way around? did the patch apply cleanly or were there any rejects which had to be handled manually? Actually, I had tried do install both patches one after the other and was not able to ever get it to work. The two patches had a couple files in common, one of which was qregex.c. The combined patch touched so many files that it seemed to throw the line count for the qmailtap patch off just enough to cause compile errors. Unfortunately, I am not a C or C++ programmer and did things here the hard way. I now have a much better understanding of the patchfile syntax due to the fact that I integrated the qmailtap patch into your combined patch 1.6c one line at a time. The qmailtap patch modifies qmailqueue under the makefile section and your combine patch did not. The tap patch also modifies qmail-queue.8 which your combined patch did not alter. One of my biggest concerns with using both of these patches was when I combine the modifications that both files performed on error.h. Within your combined patch it seems to comment out the errno by moving it to /* extern int errno; */ The tap patch seems to need this to be declared for it to run correctly. I added that line back into the patch for qmailtaps functionality to not be broken. My concern had risen out of the fact that I now had extern int error_intr, extern int error_nomem, extern int errno. Since I only have enough C/C++ knowledge to follow general program structure, trying to track down the functions and files that use these integers would be a tail chasing nightmare. Personally, I don't think running one patch and then the other is possible due to the changes in line counts within the files being patched. Having said that, there is probably an easier way to accomplish what I had without reading line for line and modifying the @@ 's.To get both patches applied correctly one has to understand the changes that these files perform. Due to this fact, releasing something like this onto the qmailrocks list would be an absolute nightmare. I am amazed at some of the questions that are asked by some members of that list. They should just put I have absolutely no actual understanding of what's going on here... is there some kind of wizard I could click on inside thier signatures. As I stated previously, the server I performed these actions on was never put into production so I only tested the supercombined tappatch using local accounts. I was able to $personal_knowledge++ by working on these two patches and making them into one file. That is a much larger benefit to me than being able to block spam tap accounts. That is one of the biggest problems with qmr the lack of understanding the lack of wanting to understand. I've started to ramble now but that was the way I accomplished applying both patches. Sincerely, Adam Ossenford
Re: [vchkpw] qmailtap question
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. pgpgBldi0DEpM.pgp Description: PGP signature
Re: [vchkpw] qmailtap question
On Saturday 04 February 2006 23:47, John Simpson wrote: just a quick question. i'm maintaining the monster combined patch that qmailrocks has adopted, and over the past few months i've been hammered with questions about using QUEUE_EXTRA. apparently it works with older versions of my combined patch, but since i added the ext_todo patch (which solves the silly qmail syndrome by splitting qmail-send into two programs- qmail-todo which classifies messages as local or remote, and qmail-send which schedules deliveries) people are saying that it doesn't work. I don't see why it wouldn't. the QUEUE_EXTRA just modifies the qmail.c interface (which is used by all qmail programs that queue mail, including ezmlm and fastforward, etc.) to add an extra recipient to the message. 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. -Jeremy -- Jeremy Kitchen ++ [EMAIL PROTECTED] In the beginning was The Word and The Word was Content-type: text/plain -- The Word of Bob. pgpZrECZK8OT7.pgp Description: PGP signature
Re: [vchkpw] qmailtap question
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. 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... 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. 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. 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... -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] qmailtap question
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... -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- I was able to integrate your qmail-1.03-jms1.6c patch and the qmail tap patch successfully. It compiled and ran with the tap functionality. However, I could not give any testimonial about performance loss due to QUEUE_EXTRA because the test server never reached production. I understand you have released an updated version of your combined patch. I haven't had an opportunity to attempt combining the two once again. If the server isn't high volume would the functionality outweigh the performance loss due to the drawbacks with QUEUE_EXTRA? Sincerely, Adam Ossenford
[vchkpw] qmailtap question
just a quick question. i'm maintaining the monster combined patch that qmailrocks has adopted, and over the past few months i've been hammered with questions about using QUEUE_EXTRA. apparently it works with older versions of my combined patch, but since i added the ext_todo patch (which solves the silly qmail syndrome by splitting qmail-send into two programs- qmail-todo which classifies messages as local or remote, and qmail-send which schedules deliveries) people are saying that it doesn't work. 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... eventually the server runs out of disk space and spews all over itself, and the recipient of the monitored messages gets flooded by literally endless copies of every message going through the server. my question is this: does inter7's qmailtap patch include some kind of loop detection code, in order to prevent this kind of thing from happening? if so, how does the loop detection work? for those who may be curious, here's the web page for my combined patch. http://qmail.jms1.net/patches/combined.shtml -- -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | --
