Re: [vchkpw] qmailtap for mail archive

[dhaval thakar]

On Mon, Feb 23, 2009 at 5:58 PM, Jukka Kurkela  wrote:

> dhaval thakar wrote:
>
>> 
>> /var/qmail/control/taps contains
>> us...@test.com:us...@arch.test.com 
>> us...@test.com:us...@arch.test.com 
>> us...@test.com:us...@arch.test.com 
>>
>> in above config mails for remote domains gets copied to relevant archive
>> id.
>> But if us...@test.com  have sent mail to
>> us...@test.com , copy of sent mail is there on
>> us...@arch.test.com  but there is no received
>> copy on te...@arch.test.com 
>>
>
> this is a feature of the tap patch. it first checks  address against
> taps and then if that didn't match it checks  address.
>
> you could try replacing the ( tapped == 0 && tapcheck()==1 ) checks with (
> tapcheck()==1 ) in qmail-queue.c and see if it works then.
>


> thanks

I have done necessary changes & its working fine.

thank you very much.


!DSPAM:49a29ee132681928970407!

Re: [vchkpw] qmailtap for mail archive

[Jukka Kurkela]

dhaval thakar wrote:


/var/qmail/control/taps contains
us...@test.com:us...@arch.test.com 
us...@test.com:us...@arch.test.com 
us...@test.com:us...@arch.test.com 

in above config mails for remote domains gets copied to relevant archive 
id.
But if us...@test.com  have sent mail to 
us...@test.com , copy of sent mail is there on 
us...@arch.test.com  but there is no 
received copy on te...@arch.test.com 


this is a feature of the tap patch. it first checks  address 
against taps and then if that didn't match it checks  address.


you could try replacing the ( tapped == 0 && tapcheck()==1 ) checks with 
( tapcheck()==1 ) in qmail-queue.c and see if it works then.



regards,
Jukka Kurkela

!DSPAM:49a2964f32681413795890!

[vchkpw] qmailtap for mail archive

[dhaval thakar]

Hi,


As mentioned on http://www.inter7.com/?page=qmailtap I am trying to use
qmailtap for mail archive.
I am using http://qmail.jms1.net/patches/qmail-1.03-jms1.7.06.patch.

I am testing this patch on test.com & for archive arch.test.com
Few users are created on test.com, same users are created on arch.test.com

/var/qmail/control/taps contains
us...@test.com:us...@arch.test.com

In above config whatever mail sent / received using us...@test.com is
forwarded to us...@arch.test.com


/var/qmail/control/taps contains
us...@test.com:us...@arch.test.com
us...@test.com:us...@arch.test.com
us...@test.com:us...@arch.test.com

in above config mails for remote domains gets copied to relevant archive id.

But if us...@test.com have sent mail to us...@test.com, copy of sent mail is
there on us...@arch.test.com but there is no received copy on
te...@arch.test.com

I am unable to find any solution for this, if anyone has faced this issue
kindly guide me to solve it.



Thanks & Regards
Dhaval


!DSPAM:49a28df532681057618500!

Re: [vchkpw] qmailtap.

[Abdul Rehman Gani]

On 12 Apr 2006, at 8:23 PM, Ken Jones wrote:


N0K wrote:

   Hello.
   Im using qmail-tap for backup mails, but i dont want backup  
from/to root user, how can i exclude this accound from qmail-tap?

   This is my /var/qmail/control/taps
   [EMAIL PROTECTED]:[EMAIL PROTECTED]
   I have test:
   [EMAIL PROTECTED]
   without any results. Any idea?
   Thanks.
   N0K.



There is nothing currently in the code to exclude accounts.
But it sounds technically feasible.


I have a need for an exception list as well. Any idea if/when this  
will be implemented?


Abdul



Ken Jones
inter7

Re: [vchkpw] qmailtap.

[N0K]

There is nothing currently in the code to exclude accounts.
But it sounds technically feasible.



   Thanks, ill wait the update :)

   Regards,
   N0K.

Re: [vchkpw] qmailtap.

[Ken Jones]

N0K wrote:

   Hello.
   Im using qmail-tap for backup mails, but i dont want backup from/to 
root user, how can i exclude this accound from qmail-tap?


   This is my /var/qmail/control/taps

   [EMAIL PROTECTED]:[EMAIL PROTECTED]

   I have test:

   [EMAIL PROTECTED]

   without any results. Any idea?

   Thanks.
   N0K.



There is nothing currently in the code to exclude accounts.
But it sounds technically feasible.

Ken Jones
inter7

[vchkpw] qmailtap.

[N0K]

   Hello.
   Im using qmail-tap for backup mails, but i dont want backup from/to 
root user, how can i exclude this accound from qmail-tap?


   This is my /var/qmail/control/taps

   [EMAIL PROTECTED]:[EMAIL PROTECTED]

   I have test:

   [EMAIL PROTECTED]

   without any results. Any idea?

   Thanks.
   N0K.

Re: [vchkpw] qmailtap question

[Jeremy Kitchen]

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

[Adam Ossenford]

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

[John Simpson]

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

[Adam Ossenford]

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 

Re: [vchkpw] qmailtap question

[John Simpson]

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

[Jeremy Kitchen]

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

[vchkpw] qmailtap question

[John Simpson]

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.  |
--

Re: [vchkpw] qmailtap making duplicate copies and looping

[Ken Jones]

[EMAIL PROTECTED] wrote:

 Something very strange : when a user (being tapped) sends a mail to a
 forward (defined via qmailadmin) the mailbox where the tap points receives
 two copies of the mail. The destination mailbox where the forward points,
 is NOT being tapped and receives only one copy. I can´t understand why
 this is happening.

 Also, if I via qmailadmin forward the mailbox receiving the taps to
 another mailbox, this one NOT being tapped, leaving a local copy (I didn't
 try not leaving a copy yet), the server enters an endless loop with these
 two last mailboxes being filled with the mail thousands of times.

 Did anyone see this problem before ?


The tap is applied to each email going through the queue.
Normally forwards cause the email to go back through the queue.
That is probably why you are getting a second copy.

You can create a mail loop. I suggest your tap address not be forwarded.

Ken Jones

[vchkpw] qmailtap making duplicate copies and looping

[info123]

 Something very strange : when a user (being tapped) sends a mail to a
 forward (defined via qmailadmin) the mailbox where the tap points receives
 two copies of the mail. The destination mailbox where the forward points,
 is NOT being tapped and receives only one copy. I can´t understand why
 this is happening.

 Also, if I via qmailadmin forward the mailbox receiving the taps to
 another mailbox, this one NOT being tapped, leaving a local copy (I didn't
 try not leaving a copy yet), the server enters an endless loop with these
 two last mailboxes being filled with the mail thousands of times.

 Did anyone see this problem before ?