On Sat, 24 Feb 2007 15:57:54 +1100
Gavin Carr [EMAIL PROTECTED] wrote:
On Fri, Feb 23, 2007 at 09:51:27PM -0500, m. allan noah wrote:
i have been running qpsmtpd for a little while now, and love it. but,
i am getting questions from users about missing email. no one is
actually able to
On Wed, 21 Feb 2007 23:24:29 +0100
Michael Holzt [EMAIL PROTECTED] wrote:
Is there interest?
Absolutely.
Here it is as two attachments. One attachment is a patch to
trunk/lib/Qpsmtpd.pm. The other is a file explaining how to use
the new feature.
What do you think of it conceptually? Is
I've been mostly ignoring qpsmtpd development for awhile, and upon a recent
svn update I see it's changed a bit. I have a few questions.
1) Is high_perf now called async?
2) Have 0.3x and trunk merged? with async in trunk?
3) Is async considered stable now?
Brian
As a total noob and a future potential user of this, I'm curious if
there's a way to specify $ID on the command-line, in an environment
variable or something like that? Or if it would be relatively painless
to add support for this? Overwriting a config file seems a little
hackish, especially
On Fri, 23 Feb 2007 09:34:35 +1100
Gavin Carr [EMAIL PROTECTED] wrote:
On Thu, Feb 22, 2007 at 02:19:54PM -0700, Brian Grossman wrote:
I anticipate a suggestion to turn it into a plugin, but the config
hook is designed for replacing the config storage, not the naming
scheme. Is it even
On Wed, 21 Feb 2007 08:21:51 +0100, Jens Weibler [EMAIL PROTECTED] wrote:
My wish would be: I can configure inside the plugins-config which
plugins where used normally and which are used while relaying.
I have a patch to lib/Qpsmtpd.pm (not a plugin) that
allows configs per-host, per-role and
On Tue, 03 Oct 2006 15:56:44 -0400
John Peacock [EMAIL PROTECTED] wrote:
Matt Sergeant wrote:
At this point, I think we should go back to the original plan of
moving the trunk back onto a branch and move branches/0.3x back to
trunk (thus making the revision history completely fubar).
What I do for per-user spam config is to record the result of the various
tests, then have one plugin make the decision at the end of the rcpt-to
stage (and also set flags for the data stage plugins). This requires
a change to each plugin that you want to have operate this way, but it
doesn't
Four possible solutions:
There is a different set of expectations for MSA and for MTA, so I use a
separate smtp server on a separate hostname for submission. That way, the
config can be completely different for these two classes of messages. For
MX I can be BOFH and for submission I can be a
This patch adds --listen-queue, in case somebody wants to use something
other than SOMAXCONN.
It's purely optional. I kind of doubt anyone would ever care.
Brian
=== qpsmtpd
==
--- qpsmtpd (revision 2227)
+++ qpsmtpd
This patch cleans up a bit, now that there's no forkserver builtin to
the qpsmtpd file.
Brian
=== qpsmtpd
==
--- qpsmtpd (revision 2227)
+++ qpsmtpd (local)
@@ -58,9 +58,8 @@
-h, --help: this page
On Wed, 21 Jun 2006 09:36:03 -0700
Robert Spier [EMAIL PROTECTED] wrote:
It also makes the code a bit harder to read. Unless there's actually
a tangible performance benefit, I'm not sure it's worth it.
It's a rather performance sensitive part of the code, and it reduces
the number
Here's a patch to make ConfigServer.pm in trunk understand that the stats
plugin no longer has a register function.
Brian
--- trunk/lib/Qpsmtpd/ConfigServer.pm-orig 2006-06-17 14:39:11.0
-0600
+++ trunk/lib/Qpsmtpd/ConfigServer.pm 2006-06-19 09:40:51.0 -0600
@@ -155,7
This patch makes Danga::DNS::Resolver::Query use restricted hashes like
the other Danga classes. I assume it will also speed things up a small
amount.
Brian
=== Resolver.pm
==
--- Resolver.pm (revision 2197)
+++ Resolver.pm
On Fri, 16 Jun 2006 15:24:36 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
Yup. I have a feeling I stumbled across a perl bug or something. I
got very strange happenings in my server. I want to try again with a
more recent perl at some point, but as with everyone else, no time to
play with
Thanks both of you. I'll rebase mine to trunk.
Yup. I have a feeling I stumbled across a perl bug or something. I
got very strange happenings in my server. I want to try again with a
more recent perl at some point, but as with everyone else, no time to
play with it.
Which version of
On Sun, 2 Apr 2006 19:28:50 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
On 2-Apr-06, at 7:09 PM, John Wang wrote:
On 4/1/06, Ask Bjørn Hansen wrote:
The danga version isn't entirely stable yet. We might move it back
to a
branch and the 0.3x code back to the trunk.
Thanks
With PollServer, I get several unrecognized commands before the disconnect
from plugins/count_unrecognized_commands kicks in.
Several buffered lines are read and processed by
Danga::Client::process_read_buf() without checking if the socket was
closed. The attached patch seems to fix it.
On Fri, 11 Nov 2005 18:21:10 -0500
Matt Sergeant [EMAIL PROTECTED] wrote:
On 11 Nov 2005, at 16:09, Brian Grossman wrote:
A plugin can emit several unrelated queries before calling for
a CONTINUATION (mine does), so I think changing the Danga::DNS
callback API will be necessary
On Fri, 11 Nov 2005 11:31:45 -0500
Matt Sergeant [EMAIL PROTECTED] wrote:
A plugin can emit several unrelated queries before calling for a
CONTINUATION (mine does), so I think changing the Danga::DNS callback
API will be necessary.
Actually I don't think it's that hard. Patch coming.
On Thu, 10 Nov 2005 10:52:29 -0500
Matt Sergeant [EMAIL PROTECTED] wrote:
Why? You should just get the callback called twice.
But that makes notes('pending_dns_queries') (in trunk/plugins/dnsbl) go
negative, revealing a race between receiving the rest of the answers
and going on to the
On Sat, 5 Nov 2005 08:41:59 -0500
Matt Sergeant [EMAIL PROTECTED] wrote:
On 4 Nov 2005, at 20:02, Brian Grossman wrote:
I was thinking about implementing dnsbl return codes and a brief
perusal of lib/Danga/DNS/Resolver.pm makes me think that resolver is a
bit hostile to the idea
On Sat, 5 Nov 2005 08:41:59 -0500
Matt Sergeant [EMAIL PROTECTED] wrote:
On 4 Nov 2005, at 20:02, Brian Grossman wrote:
I was thinking about implementing dnsbl return codes and a brief
perusal of lib/Danga/DNS/Resolver.pm makes me think that resolver is a
bit hostile to the idea
Matt,
I was thinking about implementing dnsbl return codes and a brief perusal of
lib/Danga/DNS/Resolver.pm makes me think that resolver is a bit hostile to
the idea of multiple returns to a lookup.
Am I missing something? Can you think of a way to do it that doesn't
involve heavy lib/Danga/DNS
On Fri, 04 Nov 2005 22:53:57 -0500
Bob Dodds [EMAIL PROTECTED] wrote:
I was thinking about implementing dnsbl return codes and a brief
perusal of lib/Danga/DNS/Resolver.pm makes me think that resolver is a
bit hostile to the idea of multiple returns to a lookup.
Am I missing something?
On Mon, 10 Oct 2005 11:32:21 -0400
John Peacock [EMAIL PROTECTED] wrote:
Since we're talking 10's of thousands of concurrency here in some
cases, the memory savings for [] vs {} may be worthwhile.
But by that argument, there is no point in using an array at all. The
original
On Mon, 4 Jul 2005 10:19:14 +0200
Peter J. Holzer [EMAIL PROTECTED] wrote:
On 2005-07-03 19:11:16 -0700, Robert Spier wrote:
Forkserver tends to die with segmentation faults in the signal
handler as several people on the list noticed. It also sometimes
misses the death of a child. This
On Tue, 28 Jun 2005 11:34:27 -0400
John Peacock [EMAIL PROTECTED] wrote:
What is far more likely is that spammer will find the lazy
administrators who set up an SPF record with '-all' and use those
domains exclusively to forge their return addresses. Of course, that in
itself will lead to
Here's a port of require_resolvable_fromhost to continuations.
Brian--- require_resolvable_fromhost-orig2005-05-18 16:11:31.0 -0600
+++ require_resolvable_fromhost 2005-06-22 23:41:30.0 -0600
@@ -11,9 +11,9 @@
sub mail_handler {
my ($self, $transaction, $sender) = @_;
If a client pipelined commands, process_read_buf would rush right through
all of them (ignoring disable_read), forcing the later commands to (try to)
execute even through we're waiting for a continuation.
I'm not sure whether this patch is the best way to fix this, but it
does seem to work.
Is
After a continuation where the next called hook didn't provide a second arg
to return, the corresponding respond method would get confused.
Brian=== lib/Qpsmtpd.pm
==
--- lib/Qpsmtpd.pm (revision 1670)
+++ lib/Qpsmtpd.pm (revision
On Thu, 23 Jun 2005 08:36:33 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
On 23 Jun 2005, at 04:13, Brian Grossman wrote:
After a continuation where the next called hook didn't provide a
second arg
to return, the corresponding respond method would get confused.
Can you explain a bit
There are six patches attached.
Two of them supersede the patches in my earlier message subject: PATCH:
high_perf: fixes for accept optimizing. Newer versions of both patches
from that message are included here.
Summaries in alphabetical order:
== client.pm.patch ==
First, since EventLoop
The first attached file turns off SIG{ALRM} when processing mode=command.
If check_earlytalker is called inside alarm(2), it will almost be
definition trip the alarm. When it trips the alarm, the mode doesn't get
set back to cmd.
The second attached file hangles a case where $PushBackSet{$fd}
The sender_permitted_from plugin uses Mail::SPF::Query uses IO::Select by
way of a call to IO::Select::can_read with a relatively large timeout.
This causes a SIG{ALRM} to trip. Is there anything that can be done about
this besides rewriting Mail::SPF::Query to use Danga::DNS?
Here's the call
On Tue, 17 May 2005 12:28:47 + (UTC)
[EMAIL PROTECTED] wrote:
The way I see it, the check_early talker is going to have to work like
Could we avoid the issue by having start_conversation run not call
run_hooks(connect)? Is there a place in the event loop run_hooks(connect)
could be called
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 notification of there being incoming
On Wed, 11 May 2005 14:00:15 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
Deep recursion on subroutine Qpsmtpd::run_hooks at \
.../lib/Qpsmtpd.pm line 54.
It only happens with 150 or so simultaneous connections. It gets
worse,
but I think less than linearly, up to
On Wed, 11 May 2005 14:03:41 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
On 11 May 2005, at 13:05, Brian Grossman wrote:
What are you using for profiling? Are you using Devel::DProf? I've
been
having trouble getting enough real data while getting info from
dprofpp -F
that I
On Thu, 12 May 2005 20:08:46 + (UTC)
[EMAIL PROTECTED] wrote:
My profiling results named peer_ip_string() and _load_plugins() as the
main culprits. I don't entirely trust that now, but I do have
optimizations for both if you want them.
I have a fix for _load_plugins, but not
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 notification of there being incoming
On Thu, 12 May 2005 20:35:04 + (UTC)
[EMAIL PROTECTED] wrote:
On Thu, 12 May 2005, Brian Grossman wrote:
OK, here it is. Let me know how it runs for you now. I think high CPU
load may be inherent although to be fair my spamtrap may not exactly
be the best test bed for seeing
On Wed, 11 May 2005 12:31:53 + (UTC)
[EMAIL PROTECTED] wrote:
On Tue, 10 May 2005, Brian Grossman wrote:
I'm running without the closing=0 line right now and I don't see any
ill effects. I'd say revert it and I'll send in another patch with an
explanation if it crops up again.
OK
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 don't have any plugins registering the config
On Tue, 10 May 2005 17:04:20 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
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
On Mon, 9 May 2005 09:35:26 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
On 9 May 2005, at 00:29, Brian Grossman wrote:
Attached is a patch implementing a kludge to fix this. Does anyone
see a
cleaner way to do this?
Yup, I'm applying a patch now for this (along with all your other
Attached is a patch for high_perf branch:
make can_read quieter so it doesn't pollute the log when not debugging
Brianmake can_read quieter so it doesn't pollute the log when not debugging
--- old/lib/Danga/Client.pm 2005-05-05 03:32:07.0 -0600
+++ new/lib/Danga/Client.pm
Attached is a patch for high_perf branch:
the resolver kept complaining about NOERROR lookups
Brianthe resolver kept complaining about NOERROR lookups
--- old/lib/Danga/DNS/Resolver.pm 2005-05-05 03:32:07.0 -0600
+++ new/lib/Danga/DNS/Resolver.pm 2005-05-07
Attached is a patch for high_perf branch:
Remote_info can be used (in greeting, after check_earlytalker) before the
callback gets around to setting it.
BrianRemote_info can be used (in greeting, after check_earlytalker) before the
callback gets around to setting it.
---
Attached is a patch for high_perf branch:
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.
Includes a revert on my earlier check_earlytalker
Attached is a patch for high_perf branch:
remote_host can be undef, which provokes an error in log
Brianremote_host can be undef, which provokes an error in log
--- old/lib/Qpsmtpd/ConfigServer.pm 2005-05-05 21:53:30.0 -0600
+++ new/lib/Qpsmtpd/ConfigServer.pm 2005-05-07
Attached is a patch for high_perf branch:
makes configserver status command report #connections as ratio
Brianmakes configserver status command report #connections as ratio
--- old/lib/Qpsmtpd/ConfigServer.pm 2005-05-05 21:53:30.0 -0600
+++ new/lib/Qpsmtpd/ConfigServer.pm
Attached is a patch for high_perf branch:
make this alarm more descriptive
Brianmake this alarm more descriptive
--- old/lib/Qpsmtpd/PollServer.pm 2005-05-05 03:32:07.0 -0600
+++ new/lib/Qpsmtpd/PollServer.pm 2005-05-07 03:47:14.0 -0600
@@ -91,7 +91,7 @@
if
On Thu, 5 May 2005 00:46:15 -0700
Ask Bjørn Hansen [EMAIL PROTECTED] wrote:
On May 4, 2005, at 5:56 PM, Brian Grossman wrote:
The attached patch sets the line number to be correct when setting
up a
plugin coderef. (The \n adds an extra line.)
Didn't you get the offset change
Here's a patch to make the high_perf ConfigServer's PAUSE and CONTINUE
commands work.
Pause was getting the error 'Command Error: No such pseudo-hash field
other_fds at .../lib/Qpsmtpd/ConfigServer.pm line 128.'
Continue was just not implemented: command 'continue' unrecognised ().
Brian
---
In the high_perf branch, check_earlytalker doesn't work for me.
This patch makes check_earlytalker work in high_perf.
There are two parts to this patch. The first patch, to
plugins/check_earlytalker, makes check_earlytalker work when there are
other connections generating events. (For testing,
On Tue, 26 Apr 2005 11:55:07 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
What else would you like to see me add to this?
List of current connections with whatever information about the connection
is handy, especially time of connect and remote ip. Like ps. Since there
are likely to be
Is anyone else seeing this in high_perf?
The log message would look something like this:
Can't call method log on an undefined value at
.../lib/Qpsmtpd/Plugin.pm line 47.
(That line number will be off because I've modified Plugin.pm.)
When a Danga callback is called, a call to Plugin's
On Tue, 26 Apr 2005 14:51:21 -0400
Bob [EMAIL PROTECTED] wrote:
Mainly wishing they would timeout? If they're hanging on
long enough to come to your attention, maybe a timeout
watchdog would work. Doesn't forkserver have one?
I was thinking in general, since there's other things I'd like to
On Tue, 26 Apr 2005 16:14:00 -0400
Matt Sergeant [EMAIL PROTECTED] wrote:
On 26 Apr 2005, at 14:51, Bob wrote:
Mainly wishing they would timeout? If they're hanging on
long enough to come to your attention, maybe a timeout
watchdog would work. Doesn't forkserver have one?
high_perf
Included inline are patches for two bugs in trunk. Not sure whether they
are needed for 0.29.
First, now that body_start() is read-only, the body_start($size) in
SMTP::data() needs to become set_body_start().
Second, Transaction::body_write() needs to update _body_current_pos for
array-backed
On Sat, 5 Mar 2005 13:10:54 -0800
Matt Sergeant [EMAIL PROTECTED] wrote:
I have a major set of patches pending which migrate our current setup
to use async I/O ...
Hallelujah! I'll be testing this, wherever you put it.
Should I just take the opportunity of the migration to SVN to just
On Mon, 13 Dec 2004 17:36:20 +
Matt Sergeant [EMAIL PROTECTED] 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
On Fri, 10 Dec 2004 17:03:36 -0800
Anthony D. Urso [EMAIL PROTECTED] wrote:
I sent in a patch several months ago that, although it made it into the
qpsmtpd-forkserver, has not been applied to SelectServer.pm.
Found it, thanks.
In addition to missing your patch, it looks like SelectServer.pm
On Fri, 15 Oct 2004 21:38:58 +0100
Matt Sergeant [EMAIL PROTECTED] wrote:
Block anything without a Message-ID header.
I tried this one out this week. It turns out earthlink doesn't bother
adding a message-id header. So rude! :(
It's not their responsibility - it's the MUA's.
In
On Tue, 12 Oct 2004 23:01:40 +0100
Matt Sergeant [EMAIL PROTECTED] wrote:
Block anything without a Message-ID header.
I tried this one out this week. It turns out earthlink doesn't bother
adding a message-id header. So rude! :(
Blocking on no Received headers seems to work well.
Matching
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 with a string matching \d+[\.-]\d+
Have you
On Sun, 8 Aug 2004 18:16:50 -0600
Brian Grossman [EMAIL PROTECTED] wrote:
When REAPER is called by SIGCHLD, it can start in the middle of the loop
over values %childstatus in the MAXCONNIP block. This can cause $rip to
be deleted by REAPER while we're using it. Perl will die saying Use
The SIG{CHLD} race in qpsmtpd-forkserver shows up in another way. The
process accounting in %childstatus can go out of sync with reality. I
think this is caused by SIG{CHLD} being raised while perl is processing
'delete $childstatus{$chld}'. The enclosed patch eliminates SIG{CHLD}
race
On Sat, 31 Jul 2004 18:40:56 +0100 (BST)
Mark Powell [EMAIL PROTECTED] wrote:
This plugin limits the null env sender to only one recipient. I believe
someone posted a similar pluging so time ago. However, it doesn't seem to
have made it into CVS.
That was me. I've wondered why too, since
Qpsmtpd currently has a hook for after all data is received (data_post).
Can we have a hook for responding to the DATA command immediately?
Brian
On Wed, 7 Jul 2004 15:51:37 +1000
Gavin Carr [EMAIL PROTECTED] wrote:
So it depends what you want, but you might try exe_filter at
http://www.openfusion.com.au/labs/qpsmtpd/, which does it based on
payload signatures.
Nice. I have a question about it, though. Why do you only process
The posted message 690 originally had both the then and the
else setting $self-{_nullsender1rcpt_count} to 1, but I think the
else condition should set it to 0.
You're right. A patch is at the bottom of this message.
This patch also makes it work for either the current handling or
Unfortunately, it looks like Mail::Address doesn't use angle
brackets in the format when the address is empty, even if
there's a phrase. So it's not clear what the proper way to
represent an empty address is.
Ugh. It looks like the way Mail::Address::format() uses it, new('','') is
most
74 matches
Mail list logo
