I have only seen examples of opening and closing the connections inside of
filter_sender or filter_end. Is it possible to open a connection in
mimedefang when it starts up and close it on exit. I would like to insert
some information in a table from filter_relay, filter_sender and
On Thu, Dec 14, 2006 at 07:13:56AM -0500, David F. Skoll wrote:
You can do anything you want, as long as you open the connection in
filter_initialize(), and close it in filter_cleanup()
That's one strategy. I prefer to lazily open and close the connection.
That is, have a wrapper function
Jan-Pieter Cornet wrote:
so... something like DBI-connect_cached
Exactly! :-) I never even knew that existed. Thanks!
Regards,
David.
___
NOTE: If there is a disclaimer or other legal boilerplate in the above
message, it is NULL AND VOID. You may
-Original Message-
From: Whit Blauvelt
Alternately you could use $RelayAddr to recognize what's come
in by the secondary MX and segregate it somehow - assuming
that that system's not also sending you stuff as a normal
relay from the ISP or whatever - and then only go through
Mack wrote:
Be very careful with connect_cached though, as I have noticed that you get a
SQL server has gone away when you try to use the connection, even though the
connect cached still thinks it is open and pings (after maybe 6-12hrs
inactivity - so shouldn't be a prob on a busy site
Be very careful with connect_cached though, as I have noticed that you get a
SQL server has gone away when you try to use the connection, even though the
connect cached still thinks it is open and pings (after maybe 6-12hrs
inactivity - so shouldn't be a prob on a busy site though!)
Mack [EMAIL PROTECTED] 14/12/2006 16:36
Be very careful with connect_cached though, as I have noticed that you get a
SQL server has gone away when you try to use the connection, even though the
connect cached still thinks it is open and pings (after maybe 6-12hrs
inactivity - so shouldn't
If you put a dbh-prepare statement immediately before each execute(), it
should work...bearing in mind that I haven't been able to test this.
Only advantage gained here is the persistant connection, as the prep
statements (or prep_cached) seem to have their own large overheads..
My guess is
If you put a dbh-prepare statement immediately before each execute(), it
should work...bearing in mind that I
haven't been able to test this.
Only advantage gained here is the persistant connection, as the prep
statements (or prep_cached) seem to have their own large overheads..
So write a
So write a new connect_cached() which also re-prepares the statements on a
reconnect...
Too lazy ! Lol
Alternatively, have filter_tick defined, and make it run a query on the
database, then configure the
multiplexor to use the tick function, which will stop the connection
timeout.
Nice idea
Paul Murphy wrote:
Alternatively, have filter_tick defined, and make it run a query on
the database, then configure the multiplexor to use the tick
function, which will stop the connection timeout.
That won't work, because you have no idea which slave will run the tick.
All the ticks might
Hello Kenneth,
Tuesday, December 5, 2006, 4:14:20 AM, you wrote:
Given the recent run of messages that contain just a short number, I'm
inclined to reject any message that contains a body of less than 20-40
bytes as being a nuisance. Does anyone have a piece of code that does that?
(I'll
Off-topic post but we use McAfee with MIMEDefang so hopefully people won't
mind. And since McAfee is end of lifing the 4400 product at the end of
January, others might benefit.
In short, we have some older but perfectly good boxes running that we want
to upgrade with the Linux version of
On Thu, Dec 14, 2006 at 08:54:53AM -0600, Damrose, Mark wrote:
There is no practical way to know of transient connection problems
between you and all potential senders at all times. Just because your
primary is up and has an Internet connection doesn't mean it is
reachable from all hosts
14 matches
Mail list logo