>-----Original Message----- >From: Jeremy Kitchen [mailto:[EMAIL PROTECTED] >Sent: Friday, July 01, 2005 9:40 AM >To: vchkpw@inter7.com >Subject: Re: [vchkpw] qmail-tap patch + spamcontrol > >On Thursday 30 June 2005 06:14 pm, Brian Lanier wrote: >> >> My understanding was that the when addressed to someone on the BCC line >it >> simply existed as roughly [EMAIL PROTECTED] I thought each message only had >one >> envelope recipient so that to have the message go to multiple parties you >> got multiple messages in the queue each with a different envelope >> recipient. > >no, qmail stores multi-recipient messages in the queue as one message, with >multiple recipients. >
Everyday I learn more about how much I don't know... Its great. :-) >> Am I way off on my "understanding" here? If so, is there an >> environment variable that stores the BCC field or are we saying the same >> thing only different. > >no, there is no way to get the entire contents of the envelope in a .qmail >file. This would pose a privacy issue. Say I sent bob an email and BCC'ed >it to Jane. There is no evidence in my email that jane received it, but if >the entire envelope information was available in an environment variable, >or >some other fashion, to all local recipients, then the BCC recipients could >be >leaked. > Which was how I knew it to work, I just didn't understand where or how. >The only recipient you will get with [EMAIL PROTECTED] in a .qmail file is the >recipient that is currently being delivered to. > >> Currently I am migrating my logging down into my >> maildrop file to catch the envelope recipients due to fact that >queue_extra >> changes what I know as the envelope recipient to log, which is set up as >a >> an alias that runs maildrop with a special filter file. If I can do it >all >> at once and at the queue level that would be great. My method doesn't >seem >> to be the most efficient yet it does work. > >maildrop still will not have information about the *entire* contents of the >envelope. Correct, which is why I have to worry about caching message id's to prevent duplicate deliveries of messages due to the fact that I am checking the "same" message multiple times. I went back and read a bunch of the qmail man pages just now. Amazing how differently I understand qmail now. Thanks for your patience and helping me out on this. I think I get it now. The tap patch does the checking at the queue level and only t's off a copy when needed. That's great and really cuts down on my efficiency. Next question based on functionality. I thought I read somewhere that as soon as qmail-tap finds a match it stops processing. Is that per domain or for the whole list? I want to assume that its per domain, i.e. as soon as it finds a match for one line in the control file, it stops logging for that entry but continues checking the rest of the list for other matches and possible deliveries. Is that the case? The only thing I have left is maybe a feature request. If I knew enough C to submit a patch I would. Is it possible to set up different delivery addresses for the archive user based on direction? Inbound messages could be logged to a separate user from the outbound. Kind of like the distinction for the mysql setup in vpopmail. If only one line exists it is used for both read and write, otherwise use one for read and the second line for write. Something like: [EMAIL PROTECTED]:[EMAIL PROTECTED]:[EMAIL PROTECTED] Where the format was item_to_log:if_to_matches_deliver_here:if_from_matches_deliver_here and done in such a way so that if the third field didn't exist it used the second field to provide backwards compatibility or for those that only want one final deliver. I believe the side effect of this would be two copies for each line in the control file if it hit the regex in both the to and from addresses, which is desirable by me but I am only one fish in the big pond... My concern is that if I have multiple domains using logging sending to each other, they all get the appropriate messages logged accordingly. Some of our clients have also requested the split of direction to more easily track down something. So far, all the attention into all the products mentioned and used by this list have not let me down, but I still need to ask. Any thoughts on any of this.... Is it time to go learn C and start breaking things? :-)
