On May 5, 2008, at 8:31 AM, Steve Kemp wrote:
I'll have to beat myself later, in the meantime here's a patch
against SVN trunk:
http://www.steve.org.uk/Software/tmp/qpsmtpd/qpsmtpd-txn-transaction.diff
Committed, thanks! (r885)
Might be worth removing the file "log/.cvsignore" from th
On May 5, 2008, at 8:22 AM, Steve Kemp wrote:
I'm not 100% familiar with the Makefile.PL in the source directory,
but I see that there is already a "perltidyrc" file, so it shouldn't
be a huge job to automate the invocation of perltidy.
For now if we just made a habit of running perltidy on
On Mon May 05, 2008 at 16:22:34 +0100, Steve Kemp wrote:
> I will submit a patch against the trunk hopefully tomorrow.
Hmm, that was actually a small job. It seems that I was being
inconsistent much more in my *own* plugins than the core is. Ahem.
I'll have to beat myself later, in the
On Mon May 05, 2008 at 11:06:18 -0400, Matt Sergeant wrote:
> Yes, it has been discussed before. We just need the tuits to make it so.
I'm not 100% familiar with the Makefile.PL in the source directory,
but I see that there is already a "perltidyrc" file, so it shouldn't
be a huge job to auto
On 5-May-08, at 10:45 AM, Steve Kemp wrote:
Seeing changes like this makes me wonder if we should consider
running
all source through perltidy at some point. Perhaps as part of a
"make update", or "make commit" target.
Yes, it has been discussed before. We just need the tuits to make it
On Sun May 04, 2008 at 21:21:03 -0400, Matt Sergeant wrote:
> --- plugins/tls (revision 876)
> +++ plugins/tls (working copy)
> @@ -150,7 +150,7 @@
> return DECLINED unless $local_port == 465; # SMTPS
>
> unless ( _convert_to_ssl($self) ) {
> - return (DENY_DISCONNECT, "Cannot esta
Matt Sergeant wrote:
On 4-May-08, at 7:28 PM, Matt Sergeant wrote:
Yeah this makes a lot more sense... Though I wonder if we shouldn't
modify Danga::Client to just have some sort of "reader" entry, so that
anything else (not just TLS) can hook into the event_read stream. I'll
have a poke.
C
On 4-May-08, at 7:28 PM, Matt Sergeant wrote:
Yeah this makes a lot more sense... Though I wonder if we shouldn't
modify Danga::Client to just have some sort of "reader" entry, so
that anything else (not just TLS) can hook into the event_read
stream. I'll have a poke.
Can you check if thi
Yeah this makes a lot more sense... Though I wonder if we shouldn't
modify Danga::Client to just have some sort of "reader" entry, so
that anything else (not just TLS) can hook into the event_read
stream. I'll have a poke.
On 4-May-08, at 12:59 PM, Douglas Hunter wrote:
Howdy all,
In the
Charlie Brady wrote:
>
> Having more concurrent connections than your server can confortably be
> able to handle should not result in bouncing mail. Why is mail being
> bounced?
I'll fill in for Douglas on this one... Simply, we bounce (some but not
all) mail because the number of concurrent connec
Charlie Brady wrote:
On Thu, 1 May 2008, Douglas Hunter wrote:
Yes, there are too many concurrent connections coming into our mail
server for the forkserver to handle given the iron it runs on, and
we're periodically bouncing mail.
Having more concurrent connections than your server can confo
On Thu, 1 May 2008, Douglas Hunter wrote:
Chris Babcock wrote:
Douglas Hunter wrote:
> I've recently been exploring using async for our production mail
> servers.
Why? Are you having issues with the other modes of operation?
Yes, there are too many concurrent connections coming into
Chris Lewis wrote:
As a FYI, TLS with async is also an issue for us. I'll be testing your
patch on a VERY large spamtrap in the next little while.
Very cool. As I understand the code in IO::Socket::SSL::start_SSL, the
patch I provided forces blocking on the socket being upgraded, which
co
Douglas Hunter wrote:
I only tested STARTTLS from the default port with the patch I supplied,
but that seemed to work well. I'm just not confident enough with my
async-fu to recommend that patch to other folks until it gets some more
action and community vetting. But the tls plugin isn't a p
Matt Sergeant wrote:
On 1-May-08, at 5:20 PM, Chris Babcock wrote:
Async (at this point) is best suited to systems with very high
performance and concurrency requirements. If your system can run
without using async, the other modes are simpler to implement and
better tested.
On the other h
Douglas Hunter wrote:
Chris Babcock wrote:
Douglas Hunter wrote:
Howdy,
First, thank you all for such a fantastic piece of software.
I've recently been exploring using async for our production mail
servers.
Why? Are you having issues with the other modes of operation?
Yes, there are
Chris Babcock wrote:
Douglas Hunter wrote:
Howdy,
First, thank you all for such a fantastic piece of software.
I've recently been exploring using async for our production mail servers.
Why? Are you having issues with the other modes of operation?
Yes, there are too many concurrent conne
On 1-May-08, at 5:20 PM, Chris Babcock wrote:
Douglas Hunter wrote:
Howdy,
First, thank you all for such a fantastic piece of software.
I've recently been exploring using async for our production mail
servers.
Why? Are you having issues with the other modes of operation?
Async (at this po
Douglas Hunter wrote:
Howdy,
First, thank you all for such a fantastic piece of software.
I've recently been exploring using async for our production mail servers.
Why? Are you having issues with the other modes of operation?
Async (at this point) is best suited to systems with very high
19 matches
Mail list logo
