On 5 Sep 2004, at 13:52, John Peacock wrote:
Matt Sergeant wrote:
I think that may be my fault, by moving the global hooks hash into
the qpsmtpd object. But I think we definitely want to keep that
change, so we'll fix it if its broken instead of backing it out.
Yeah, those are the changes I
On 5 Sep 2004, at 15:08, Matt Sergeant wrote:
On 5 Sep 2004, at 13:52, John Peacock wrote:
Matt Sergeant wrote:
I think that may be my fault, by moving the global hooks hash into
the qpsmtpd object. But I think we definitely want to keep that
change, so we'll fix it if its broken instead
On 7 Sep 2004, at 06:19, Robert Spier wrote:
it might make more sense to just use inheritance. (Matt/Ask,
feelings?)
Then we can do things like:
@ISA = (@ISA,$parent_plugin);
I was thinking about this the other day. It would be a simple matter of
having a function that plugins can call:
On 7 Sep 2004, at 06:56, Robert Spier wrote:
Other things I committed tonight:
- We were calling load_plugins twice. This meant that plugins got
registered twice and therefore called twice.
I wonder if we should protect against this with a flag. Or if the
following:
sub load_plugins {
my
OK, my first stab at plugin tests is now checked in. To make a plugin test
you create a file of the same name in t/plugin_tests/ and add to that
file:
sub register_tests {
my $self = shift;
my $num_tests = 1;
$self-register_test(test_name, $num_tests);
}
sub test_name {
my $plugin =
On 14 Sep 2004, at 03:43, Robert Spier wrote:
Today I was supposed to do my expenses. Instead I did this.
http://www.sergeant.org/Apache-Qpsmtpd/
You rock!
So, how does it perform compared to forkserver?
I have no idea :-) I haven't had any chance to do benchmarking, in fact
I'm not entirely sure
On Tue, 14 Sep 2004, Robert Spier wrote:
So, how does it perform compared to forkserver?
I have no idea :-) I haven't had any chance to do benchmarking, in
fact I'm not entirely sure it'll fully work.
You'd better get cracking. ;)
What I do know is that check_earlytalker definitely
On Thu, 16 Sep 2004, Mark Powell wrote:
Hi,
I want to provide SMTP AUTH, but only on the encrypted connections i.e.
on ports 465 587, but not port 25.
Under normal qpsmtpd the only way to do this seems to be a port check in
the auth plugin sub register and not registering the handlers
On Thu, 16 Sep 2004, Mark Powell wrote:
Incidentally I've gone back to using PPerl from SpeedyCGI. One of our
relays stopped accepting connections early last week with SpeedyCGI after
only 3 days of real traffic, with no obvious reason. Since then PPerl has
been great so far, fingers
On 19 Sep 2004, at 06:12, Michael Holzt wrote:
- a plugin check_relayclient which should be called as the very
first one in rcpt-chain. It will always return DECLINED, but
will set transaction-relaying if either $ENV{RELAYCLIENT} is
set, or client ip appears in relayclients or
On 19 Sep 2004, at 11:40, Michael Holzt wrote:
1: Why call the first one in the rcpt chain at all? Just make it a
connect plugin.
I could do this, and in fact i have attached an modified version of
'check_relay' which just does that. As it has otherwise the complete
same functionality as
On 19 Sep 2004, at 13:16, Michael Holzt wrote:
I added the same logging functionality to dnsbl and rhsbl to see
rejected
mails by this plugins as well (i use this to check for false positives,
it gives me a better feeling to have logged this rejects). I also
slightly
fine-tuned the format
On 19 Sep 2004, at 14:35, Michael Holzt wrote:
Looks like you could do this a bit cleaner with a deny hook.
Sound like a good idea, but when trying to register a plugin:
Sep 19 15:33:45 mir qpsmtp: denylog : Invalid hook: deny at
lib/Qpsmtpd/Plugin.pm line 19.
Something broken?
Yep. Bug created
On 19 Sep 2004, at 14:21, Michael Holzt wrote:
After SMTP AUTH has been completed successfully, the client becomes an
relayclient of the rest of the connection. Currently we do this by
setting $ENV{RELAYCLIENT}. Same is true for allowing relaying by IP
(is connection) or by other means like for
On 21 Sep 2004, at 02:56, John Peacock wrote:
OK, this is what I have working and I think I will check it in
tomorrow morning after some more testing:
1) plugins/check_relay is now a check plugin and should run just after
early_talker (or so); it sets the $connection-{_relay_client}
variable
OK, so bounce_verp is actually quite broken. It can't work for outbound in
qpsmtpd - it has to be in qmail-remote. Maybe we'll have to look into
re-writing qmail-remote in perl :-)
I'll remove it from the repository so that people don't use it.
--
!-- Matt --
:-get a SMart net/:-
I am Jack's
FYI: Since starting to run the bounce_verp plugin yesterday I've blocked
over 2000 bogus bounces.
I have some more changes to it, but it's very definitely useful.
--
!-- Matt --
:-get a SMart net/:-
I am Jack's broken heart.
On 22 Sep 2004, at 16:35, Robert Spier wrote:
Robert Spier already started implementing this:
You'll have to check out from CVS to get these two...
I've been sidetracked, but my future plans are to use my plugin
wrapper/inheritance stuff to put greylisting[1] in place for windows
boxes.
I haven't
On 22 Sep 2004, at 19:28, John Peacock wrote:
Thinking it over, I'd actually prefer to just go ahead and deprecate
the $transaction-relaying() flag entirely, rather than try and paper
over the issue. There is no core code (lib's or plugins) which
reference the old flag any more.
I'm +1 on
On 24 Sep 2004, at 17:00, John Peacock wrote:
So, what I was thinking was taking the 'denylog' idea to it's natural
conclusion and wrap _all_ logging operations.
This should be easy - make logging a hook, like config is, then you can
handle logging exactly the way you want to. We can hook into
On 24 Sep 2004, at 17:30, John Peacock wrote:
Michael Holzt wrote:
Server SMTP systems SHOULD NOT reject messages based on perceived
^^
Failure of 2822 (which is the son of 822) is specifically NOT an
reason
for rejection as stated in 2821 (and quoted above).
That's
On 25 Sep 2004, at 09:21, Michael Holzt wrote:
This is what my proposed conf hook would allow.
And like magic, there already is a config hook :-)
(Hmm, must check it still works...)
On 25 Sep 2004, at 15:16, [EMAIL PROTECTED] wrote:
I'd like to hear a valid reason you actually want these messages. And
a
serious example of when you might, not just quoting RFCs again.
Since it breaks legitimate mail, I'll probably not implement
something that blocks empty messages.
On 11 Oct 2004, at 19:53, John Peacock wrote:
Michael Holzt wrote:
I'm very certain that nobody right now uses the bug/feature that
old X-Spam-Status lines are not getting removed.
Reread the comment here:
news://nntp.perl.org:119/[EMAIL PROTECTED]
which is largely why I reverted the previous
Would it be worth adding Apache::Qpsmtpd to the base distro?
http://www.sergeant.org/Apache-Qpsmtpd/
On 11 Oct 2004, at 20:26, John Peacock wrote:
Matt Sergeant wrote:
As an ex spamassassin developer, I support the change. However I
don't use the plugin (SA isn't aggressive enough for me), so don't
take my word as gospel.
That's what's funny - I don't use SA any more either! I'm using dspam
On 11 Oct 2004, at 21:06, John Peacock wrote:
Block anything without a Message-ID header.
Block anything without any Received headers.
Block anything found in CBL, SBL and SORBS.
Block anything HELOing with a string matching \d+[\.-]\d+
Block anything marked bulk in DCC.
I'm managing a corporate
be possible with the next release of mod_perl
to do a Cpoll() on the socket though, so we can hopefully get
that working in the future.
Other operations that perform directly on the STDIN/STDOUT filehandles
will not work.
=head1 AUTHOR
Matt Sergeant, [EMAIL PROTECTED]
Some credit
On 12 Oct 2004, at 21:09, Brian Grossman wrote:
On Mon, 11 Oct 2004 20:50:12 +0100
Matt Sergeant [EMAIL PROTECTED] wrote:
My top tips:
Block anything without a Message-ID header.
Block anything without any Received headers.
Block anything found in CBL, SBL and SORBS.
Block anything HELOing
On 7 Oct 2004, at 03:59, Keith C. Ivey wrote:
Ed McLain [EMAIL PROTECTED] wrote:
Now the one that is giving me hell is the:
if ( /^$date $hour:$mf[$ms-$me]/ ) {
You're not using strict, are you? Unfortunately, $mf[$ms-$me]
is an element of @mf, and writing ${mf}[$ms-$me] won't save you
from the
On 2 Nov 2004, at 16:48, Anthony R. J. Ball wrote:
Hi, I run a host on a comcast cable modem and am subsequently
on the mail.abuse.com's DUL (Dynamic User List). I want to set
up qpsmtpd to try direct smtp first, and on failure, use comcast's
smtp (they rate limit pretty tightly, so I can't send
On 4 Nov 2004, at 22:44, Ed McLain wrote:
On a side note, is it normal to only be able to get 20-25 connections
per
machine? Our machines are spec'd as follows:
P4 3.0Ghz, 1GB Ram, 40GB ATA 133
Running: FC 2, SpamAssassin 3.0, ClamAV 0.80, qpsmtpd 0.29
SA is running with 13 .cf files including
On 16 Nov 2004, at 02:29, Ask Bjørn Hansen wrote:
Hi everyone,
Any objections to move qpsmtpd to Subversion (from the CVS repository)
after we release the next version?
No real objections. It won't buy us much, and I'd rather move to darcs,
but feel free :-)
Matt.
On 16 Nov 2004, at 20:55, Skaag Argonius wrote:
I want my qpsmtpd server to accept mail for a certain domain, clean up
spam
and viruses, and then transfer everything that managed to pass through
to a
different server.
You just want queue/smtp_forward.
Matt.
On 18 Nov 2004, at 01:57, Robin Bowes wrote:
Hi,
Whilst debugging my clamav problems (see separate post) I had the
loglevel up at 8. I noticed loads of these messages:
2004-11-18 01:36:24.373353500 26704 trying to get config for timeout
2004-11-18 01:36:24.373992500 26704 trying to get config
On 18 Nov 2004, at 02:45, Carlos Andrés Paz wrote:
Hi there!
I've been reading a lot about qpsmtpd and want to give it a try as an
exclusive spam and virus gateway, but I'm concerned about it's
performance... could anyone point me some information about memory
footprint/cpu
On Thu, 18 Nov 2004, Robin Bowes wrote:
Matt Sergeant wrote:
On 18 Nov 2004, at 08:22, Robin Bowes wrote:
I'm actually using a very recent CVS version - checkecd out on 17th
November 2004 at about 17;40 GMT. In fact, I've just run a cvs update
and I'm totally up-to-date
On 19 Nov 2004, at 08:14, Robin Bowes wrote:
Ah, I see. Letme know when you check in the updated code and I'll give
it a whirl.
Done.
On 22 Nov 2004, at 12:57, John Peacock wrote:
In addition, using DNS for user validation would make dictionary
attacks practical again, since DNS is a public service by default.
Only in the same way that a RCPT TO check is. i.e. a DNS database
doesn't automatically mean you can freely download
On 28 Nov 2004, at 05:33, Robert Spier wrote:
I can pull head, port, test and diff
it sooner than later if there's any interest. I know some use
multilog, but
I've been running with stdout piped to logger until I patched for
it.
This wouldn't be a bad thing to have.
How about logging going
On 28 Nov 2004, at 20:46, Peter Eisch wrote:
If you run with qpsmtpd-forkerver there are no native logging
entry-points
if the logging set up happens inside a transaction. I guess
-forkserver
could create an instance of Qpsmtpd, -load_plugins() and use it for
logging.
Forkserver already does
On 2 Dec 2004, at 16:36, John Peacock wrote:
I am setting up a second e-mail server to eventually move all of my
mailboxes onto. For testing purposes, specifically of dspam, I want
to mirror all messages that come in for a while. I don't want to
rsync the message store because I need the
On 2 Dec 2004, at 20:47, John Peacock wrote:
Matt Sergeant wrote:
How about a plugin that does this?
# in config/plugins
queue/runall queue/qmail-queue queue/qmqpc-queue
Should be fairly easy to just call the appropriate methods in those
plugins.
Except that you need to actually capture
On 10 Dec 2004, at 22:18, Brian Grossman wrote:
What is the status of SelectServer?
It's pretty much in limbo right now. The problem is that the design of
qpsmtpd is kind of fundamentally designed around reading from STDIN and
writing to STDOUT, or at least designed around doing blocking reads.
On 13 Dec 2004, at 18:03, Anthony R. J. Ball wrote:
qpsmtpd is kind of fundamentally designed around reading from STDIN
and
writing to STDOUT, or at least designed around doing blocking reads.
As
...
It's unfortunate, because the end result would be a server capable of
processing thousands of
On 13 Dec 2004, at 22:27, Brian Grossman wrote:
Then there's scaling to multiple CPUs. I suppose, start by relying on
linuxvirtualserver then move to a configurable number of worker
threads.
Is perl's ithreads up for this?
I do this by just forking 2 x NumCPUs children off in my code at work.
On 14 Dec 2004, at 15:38, Anthony R. J. Ball wrote:
I do this by just forking 2 x NumCPUs children off in my code at work.
That's the most stable way to do things. Perl's ithreads is still a
rather undiscovered territory :-)
It's also easy, and in a loaded system will most likely balance
about
On 21 Dec 2004, at 00:09, Robert Spier wrote:
my ($space, $from) = ($from_parameter =~
m/^from:(\s*)([^]*)/i)[0];
$self-transaction-notes(extra_space_in_mail_from, $space ne
$self-transaction-);
I'd prefer to see something similar to the 'cautious' above. But
instead of encoding the
On 26 Dec 2004, at 06:16, Fred Moyer wrote:
I was playing around with Apache::Qpsmtpd today with mod_perl 1.99_17,
and
I needed to patch the source as follows. One other thing I had to do
was
to symbolically link all files in /var/qmail/control to
/home/httpd/qpsmtpd/config/. I don't know if
On 29 Dec 2004, at 05:28, Jeremy OReilly wrote:
I'm not a proficient Perl programmer but I've been coding in PHP since
version 2. And so I'm curious if there is a way to write PHP based
plugins and call them from qpsmtpd. I'm guessing that the answer here
will be no but thought I'd throw it
On 10 Feb 2005, at 13:34, Justin Mason wrote:
it's pretty basic -- e.g. it would be handier if the headers were
passed
as metadata, and it requires the SVN trunk version of DQ, but it Works
For
Me. (At least, it will once I figure out a way to deliver to postfix
for certain RCPT TO addresses.)
On 22 Feb 2005, at 10:50, Peter Eisch wrote:
I have a new server config assembled that I'm going to slide into
testing
today, finally, that uses the logging via a logging hook I submitted
back in
Dec. This is also my first rollup of using apache as the connection
manager.
Does anyone have any
On 27 Feb 2005, at 08:29, John Peacock wrote:
Since I can't leave well enough alone, I have started to write a new
clamav plugin along the following lines:
1) communicate directly with the clamd daemon (via TCP/IP or unix
domain socket), much like the spamassassin plugin does with spamd;
2)
On 27 Feb 2005, at 13:15, Peter Eisch wrote:
One of the biggest problems will be what the AV scanners actually want
to see - do they want to scan filenames or do they want to scan a
bytestream, or what? I guess we can get around that using temporary
files either way though, but for high
On 28 Feb 2005, at 07:52, John Peacock wrote:
Hanno Hecker wrote:
On Sun, 27 Feb 2005 23:17:59 -0800
Hmm... no, just use everything else as before, feed the headers to the
queue and to other plugins from memory. Just change the position where
the body starts in the temp file.
Hmmm, that's an
On 3 Mar 2005, at 05:04, Nick Leverton wrote:
No, all bounces always come from .
Unfortunately this is wishful thinking.
Matt.
On 5 Mar 2005, at 10:48, [EMAIL PROTECTED] wrote:
Is there a way to pull a complete (envelope) sender address into a
plugin as a single pointer/variable?
Not without upgrading. If you upgrade you can use
connection-notes('original_string') to do whatever you need.
Matt.
Folks,
I have a major set of patches pending which migrate our current setup
to use async I/O (a bit like what I tried to do with SelectServer, but
better). They support the current spawn and fork models too by some
clever use of the the polling class.
The big thing they change though is the
On 5 Mar 2005, at 15:09, John Peacock wrote:
It also merges all the different scripts into one server script, which
auto-detects INETd/TcpServer mode by looking for ENV{REMOTE_HOST},
and takes
a flag to switch to forkserver mode.
I run my copies out of djb-style env/ directories, so as long as
On 6 Mar 2005, at 04:06, Bob wrote:
Would this mean any change for pperling plugins?
It shouldn't do.
I'd like to have qpsmtpd and gatling and tinydns
running faster than wire speed, beat the ddossing
maggots that way.
Not sure how you have things running faster than wire speed, but
whatever
OK, the work on the initial phase of this is complete, on the high_perf
branch.
Points to note:
- I've left Qpsmtpd::TcpServer in there - it's now only used by
Apache::Qpsmtpd. I hope to nuke that use of it eventually so everything
can be unified.
- Some of the plugins work slightly
On 10 Mar 2005, at 01:13, Don O'Neill wrote:
I'm of the opinion that the name is just fine as is. Why come up with
another name when one exists already?
I've now done two 45m talks on qpsmtpd. It's not fun.
On 9 Mar 2005, at 22:31, David Sparks wrote:
As it usually turns out, I was mistaken. After firing up tcpdump on
both the local and remote sides it because obvious that the problem is
that the remote MTA (sendmail in this case) is the one doing the DNS
lookups and timing out (after 56
Pokea. It's swahili for receive.
Matt.
On 10 Mar 2005, at 11:04, Keith Ivey wrote:
Matt Sergeant wrote:
Pokea. It's swahili for receive.
Also some New Age psychologist, apparently.
And it does look like pokey -- could subconsciously make people
think it's slow.
Interestingly when talking about cars in the UK that would mean quick
On 14 Mar 2005, at 17:22, Ask Bjørn Hansen wrote:
On Mar 14, 2005, at 14:15, John Peacock wrote:
This means I can intellegently segregate the log lines (if I want to
collect them prior to outputting them), or just print them out
(current behavior).
Thoughts?
I don't think I like putting so much
On 15 Mar 2005, at 06:42, John Peacock wrote:
I'm sorry, I should have made clear that from the caller's
perspective, nothing changes, so we don't have to change any call to
$self-log(). See the attached patch for an example implementation
(which nicely indents the related log entries as a
On 19 Mar 2005, at 15:25, Bob wrote:
Until plugins are compatible with your asymetrical server.
They all are. Though some will block, but how busy is your server and
which plugins do you want to run?
Can't locate object method new in lib/Qpsmtpd.pm line 190
didn't happen just now if I rebooted,
I'll only comment on those that may have issues:
On 19 Mar 2005, at 17:01, Bob wrote:
check_earlytalker
count_unrecognized_commands
check_relay
require_resolvable_fromhost
# rhsbl let spamassassin do bl's fuzzily so not ban yahoo etc
# dnsbl
check_badmailfrom
check_badrcptto
check_spamhelo
I've just added a rudimentary config server to the high_perf branch.
This allows you to connect on localhost to check number of concurrent
connections and the number of pending dns queries.
I have a few thoughts on other things that can be done, but I'd also
like feedback on what people would
On 26 Apr 2005, at 13:50, Bob wrote:
Pause/Continue, not so simple. I can appreciate that there would
be lots of state issues to handle to deliver a simple sounding feature.
Well it would be more like stop accepting connections and then
resume accepting. It's really trivial to do that :-)
Matt.
On 26 Apr 2005, at 16:56, Brian Grossman wrote:
Erm, could you point one out to me for an example? I'm hoping in
particular to implement booting a connection when it doesn't say
anything
for several minutes. I do this in forkserver with SIG{ALRM}, for
example.
It just does it. It times out
LIST - lists current sessions sorted by time connected, with a limit if
required (specify 10 to get oldest 10, specify -10 to get newest 10).
KILL - kill a session
STATUS - dumps the following style info:
Current Status as of Fri Apr 29 02:10:20 2005 GMT
Uptime: 22746.75 sec
Mails
On 4 May 2005, at 10:45, John Peacock wrote:
This would seem to suggest that you should be running the high-perf
branch if possible (but I don't think the AV plugins have been
re-implemented on that branch yet).
The AV plugins don't need converting since they use system() so we
can't do
On 3 May 2005, at 13:28, Justin Erenkrantz wrote:
We've been seeing a spike in segmentation faults with
qpsmtpd-forkserver in the last few days (nothing changed on our end).
Has anyone else seen this behavior? Our master qpsmtpd perl process
segfaults (i.e. not the children; but the parent) -
On 4 May 2005, at 17:16, Justin Erenkrantz wrote:
--On Wednesday, May 4, 2005 5:05 PM -0400 Matt Sergeant
[EMAIL PROTECTED] wrote:
Time to switch to Apache::Qpsmtpd.
Seriously? My impression from this list was that Apache::Qpsmtpd was
largely untested. Has that changed? -- justin
I believe
On 4 May 2005, at 18:22, Brian Grossman wrote:
On Wed, 4 May 2005 16:22:53 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
I'd love to hear of a larger scale rollout of high_perf. We've been
pretty happy with it so far (except for ip_conntrack tables filling up
- if anyone knows why that is - I
Yeah I'm not so sure about the workings I have of pause/continue.
There's a major issue in that if you pause/quit/telnet/continue then
it'll never start again!
On 5 May 2005, at 23:58, Brian Grossman wrote:
Here's a patch to make the high_perf ConfigServer's PAUSE and CONTINUE
commands work.
On 7 May 2005, at 18:08, Brian Grossman wrote:
PostLoopCallback was a global and would be overwritten by anyone with
an
interest. This caused a race condition. For example,
check_earlytalker
would fail horribly if there was more than one connection.
Although I applied this patch I'm confused
On 10 May 2005, at 16:21, Elliot F wrote:
I'm looking at moving to the high_perf branch, or at least doing dev
on it, as it looks promising and educational. I have used some of my
plugins for normal qpsmtpd with high_perf, but blocking occurs.
While this isn't an issue for a smaller server, I
On 10 May 2005, at 20:33, Michael Holzt wrote:
Because the current qpsmtpd implementation uses stdin and stdout for
network
communication i need to retransform stdin/stdout into an ssl-capable
socket
by using IO::Socket::SSL-new_from_fd. If qpsmtpd would directly use an
IO::Socket::INET socket,
On 11 May 2005, at 13:05, Brian Grossman wrote:
The biggest slow down though was the per-object post-loop-callbacks.
Iterating through each object every time through our event loop was a
killer. I have a patch for that where I use an external variable to
keep
track of whether there are any PLCs
On 11 May 2005, at 13:19, Brian Grossman wrote:
Is anyone else who's using high_perf seeing error messages like this:
Deep recursion on subroutine Qpsmtpd::run_hooks at \
.../lib/Qpsmtpd.pm line 54.
For me, line 54 is the line in Qpsmptd::config() that calls
run_hooks(config). I
On 12 May 2005, at 17:28, Brian Grossman wrote:
On Thu, 12 May 2005 20:06:26 + (UTC)
[EMAIL PROTECTED] wrote:
entirely. BTW, my biggest cpu load is when pollserver accepts
connections.
Ah, this was my fault. Get latest SVN. What was happening was I only
accepted one connection per
On 12 May 2005, at 17:35, Brian Grossman wrote:
I have a fix for _load_plugins, but not peer_ip_string - I got around
that slowness by turning off the max per IP code.
Here's both then.
I'll apply your peer_ip cache (using the key name peer_ip instead of
rem_ip), but my patch for hook caching is
On 12 May 2005, at 19:01, Brian Grossman wrote:
Ah fair enough. I wonder if it wouldn't be faster to have an external
hash of PLCs that gets cleared on DESTROY. Then we don't have to
iterate
through every single connection.
That's definitely an improvement for me. Patch attached.
Super.
On 13 May 2005, at 15:33, Brian Grossman wrote:
This caused a memory leak, so I've had to go back to one connection per
accept_handler.
If we use check_earlytalker, each new connection goes into EventLoop()
for N seconds (via Client:can_read()), delaying the continuation of the
accept_handler
On 13 May 2005, at 16:12, Matt Sergeant wrote:
I'm also wondering if there's a better way to do can_read than going
back into the event loop...
Correction to what I wrote in the previous email... There's no other
way to do it than figure out the above...
The good news is that if I can figure
On 18 May 2005, at 17:52, John Peacock wrote:
Now if only I could track down where these Plugins already loaded
messages are coming from.
It comes from load_plugins() being called in Qpsmtpd::TcpServer::run()
for each connection. It's harmless (in that the plugins are only ever
actually
On 24 May 2005, at 13:02, John Peacock wrote:
Thoughts?
To be honest John I missed all the adaptive logging stuff due to
working on high_perf. I'm confused as to why you buffer up the log
lines like this. Can you explain? Feel free to point me to a list
archive entry if it's been explained
We currently don't use strict for plugins. Anyone object to me making
it so?
On 25 May 2005, at 11:28, John Peacock wrote:
Matt Sergeant wrote:
We currently don't use strict for plugins. Anyone object to me
making it so?
Did you just add it to the wrapper code to see whether it would break
anything (at least for the most common plugins)? I just did
On 25 May 2005, at 11:37, Elliot F wrote:
Speaking of which (sort of), it looks like the high_perf branch does
not have
taint turned on.. Is this for performance reasons, or is this a
choice?
[EMAIL PROTECTED] $ /usr/bin/perl -Tw ./qpsmtpd
Insecure dependency in require while running with
On 8 Jun 2005, at 07:04, Michael Holzt wrote:
A more generic approach which should probably be done with the stock
plugins
is to add a parameter which allows one to turn off this plugin for
relaying
and/or authenticated users.
Actually I was thinking of adding a new return code which would
On 8 Jun 2005, at 10:01, Michael Holzt wrote:
Actually I was thinking of adding a new return code which would skip
past everything to just queue the mail. Something like:
I would have no use for that, because i want some plugins to run for
all users, e.g. a plugin checking if a mail address
On 17 Jun 2005, at 00:35, Joe Schaefer wrote:
[EMAIL PROTECTED] (Justin Erenkrantz) writes:
On Thu, Jun 16, 2005 at 11:28:43AM -0400, Matt Sergeant wrote:
On 15 Jun 2005, at 14:47, Justin Erenkrantz wrote:
As I've mentioned before, we (apache.org) are seeing our qpsmtpd
processes stuck
On 18 Jun 2005, at 12:08, Peter Eisch wrote:
Ok, my turn to learn, where I have:
while (!$bb-is_empty) {
my $b = $bb-first;
$b-remove;
$b-read(my $newdata);
$data .= $newdata;
return $data if index($data, \n) = 0;
}
I've checked in support for a rudimentary form of continuations.
The basic idea is that previously you had to rely on the following
sequence of events:
(((
hook_connect : dnsbl - fire off dns query and turn off read mode on
socket.
callback : get dns response - turn on read mode on
On 20 Jun 2005, at 09:31, Keith Ivey wrote:
I've attached a plugin that duplicates the loop-checking in
qmail-smtpd.
Added to svn. Thanks.
On 20 Jun 2005, at 12:49, Joe Schaefer wrote:
So we don't need to delete/remove the bucket at all? Sweet - that
should be even faster :-)
I don't think it's correct though- how will $bb-is_empty ever be
false without something like $b-delete? Hmm, maybe it's time to
start using Apache::Test
101 - 200 of 611 matches
Mail list logo
