Robert Spier wrote:
What's the point of this? If you need the hostname in the pre-connect
hook you can look it up there from the IP address which you already
have.
If you need to look up the hostname on every incoming connection, it
doesn't seem sensible to do so yourself in a plugin, and the
On Mon, Jan 12, 2009 at 9:52 AM, Jared Johnson wrote:
> Robert Spier wrote:
>>
>> What's the point of this? If you need the hostname in the pre-connect
>> hook you can look it up there from the IP address which you already
>> have.
>
> If you need to look up the hostname on every incoming connect
Does too. Looking up a hostname can take time, which will be wasted
if you turn out not to care. And duplicate lookups will be cached.
You know, you have a good point there. I recently reverted some custom
work I did on the RBL plugin that tried to cache positive results; it
didn't seem tha
I've been using qpsmtpd for a number of years, and without knowing very
much Perl, I have been able to customize all of the plugins and write
dozens of my own, without any problems understanding that 'DECLINED' means
that the plugin is exiting (returning) while declining to do anything.
It proba
David Nicol wrote:
On Mon, Jan 12, 2009 at 10:19 AM, Jared Johnson wrote:
Does too. Looking up a hostname can take time, which will be wasted
if you turn out not to care. And duplicate lookups will be cached.
You know, you have a good point there. I recently reverted some custom work
I did
On Mon, Jan 12, 2009 at 10:39 AM, Jared Johnson wrote:
> Was the name 'remote_hostname' as
> opposed to 'remote_host' intentional?
no. I wrote that without looking at any references at all.
> As an aside, I don't really
> understand why pre-connection hooks need the same information they could
For what it's worth, I like "NEXT" better than "DECLINED" too.
"DECLINED" brings to mind embarrassing failures to charge additional
purchases on maxed-out credit cards, or some other form of rejection.
"NEXT" carries no such nuance, being a familiar and functional flow
control directive.
On 1/12/09 1:39 PM, "David Nicol" wrote:
> For what it's worth, I like "NEXT" better than "DECLINED" too.
> "DECLINED" brings to mind embarrassing failures to charge additional
> purchases on maxed-out credit cards, or some other form of rejection.
> "NEXT" carries no such nuance, being a famili
David Nicol wrote:
> For what it's worth, I like "NEXT" better than "DECLINED" too.
> "DECLINED" brings to mind embarrassing failures to charge additional
> purchases on maxed-out credit cards, or some other form of rejection.
> "NEXT" carries no such nuance, being a familiar and functional flow
>
$ svn diff
Index: Qpsmtpd/Constants.pm
===
--- Qpsmtpd/Constants.pm(revision 967)
+++ Qpsmtpd/Constants.pm(working copy)
@@ -24,6 +24,7 @@
DENY_DISCONNECT=> 903, # 550 + disconnect
DENYSOFT_DIS
I consider this on the level of gratuitous changes that aren't worth
doing unless it's part of a much bigger overhaul/cleanup (eg: the
"Unifying QP" thread).
I consider this patch to be part of a much bigger overhaul/cleanup
effort; however I get the impression that QP upstream prefers to see
I can't say I agree with this patch, even though it would represent a
less significant change and satisfy more parties.. it would also make it
more likely for both terms to be used throughout the code, decreasing
readability and increasing the confusion (now the uninitiated reviewer
has to not
On Sun, 2009-11-01 at 15:14 -0800, Ask Bjørn Hansen wrote:
> Test repository (it will change!) -
>
> git clone git://git.develooper.com/qpsmtpd.git
>
> Please review and let me know if you see any mistakes.
I updated my repo at github from svn and then pulled your
git repo.
I discovered th
On Mon, 12 Jan 2009, Jared Johnson wrote:
I propose something like the following in the connection package
sub remote_hostname{
my $self = shift;
$self->{_remote_hostname} ||=
Net::DNS::get_name($self->{_remote_ip})
}
This seems reasonable to me on principal.
Except do
14 matches
Mail list logo
