Hi Matt
How about putting it on Github? Then anybody can look and decide if they
want to continue work on it and perhaps make it cpan -ready.
To be fair I don't do perl coding any more, so I'm happy for someone
to take over ParaDNS maintainence.
ParaDNS-XS is in my SVN server. Happy to
To be fair I don't do perl coding any more, so I'm happy for someone
to take over ParaDNS maintainence.
ParaDNS-XS is in my SVN server. Happy to share that with anyone who wants
it. It's basically ParaDNS using adns backend rather than Net::DNS. It's a
bit hacky and probably doesn't work 100%
Matt Sergeant wrote:
Do you have ParaDNS::XS installed? If not, try installing it. It's
generally likely to be better than plain ParaDNS (and will be used
automatically if it's installed).
There is no ParaDNS::XS on cpan... At least nothing returned for...
Do you have ParaDNS::XS installed? If not, try installing it. It's
generally likely to be better than plain ParaDNS (and will be used
automatically if it's installed).
On Thu, 17 Jul 2014, David Favor wrote:
I've been running qpsmtpd-async for years on all sorts of servers.
Likely I have
On Fri, 18 Jul 2014, David Favor wrote:
What's the actual problem you are trying to solve though?
Problem is ParaDNS is failing on all lookups for this server.
...
Notice the there lines with prepended '' which show ParaDNS failing.
Perhaps you should be looking for assistance on a
: qpsmtpd qpsmtpd@perl.org
Subject: Re: qpsmtpd-async weird ParaDNS lookup problem
Ed McLain wrote:
If using dig you can either do:
dig -x 127.0.0.1
OR
dig 1.0.0.127.in-addr.arpa PTR
That is going to query the primary name server listed in
/etc/resolv.conf
- so unless it has a reverse zone
The symptom of this problem is qpsmtpd-async just hangs
forever in the HELO part of SMTP transaction.
After putting reams of debug code in ParaDNS.pm + qpsmtpd,
the fix I came up with is a minor change to...
lib/Qpsmtpd/PollServer.pm
In start_conversation() no nameserver list specified. I
Ed McLain wrote:
If using dig you can either do:
dig -x 127.0.0.1
OR
dig 1.0.0.127.in-addr.arpa PTR
That is going to query the primary name server listed in /etc/resolv.conf
- so unless it has a reverse zone setup for the l27.x block you will not
get an answer back or you will get an answer
I've been running qpsmtpd-async for years on all sorts of servers.
Likely I have something in DNS setup slightly wrong on a new server
I'm setting up + what's wrong escapes me.
The symptom is qpsmtpd-async hanging forever in the HELO sequence.
Both forkserver + prefork work fine + async works
all support questions to our support team at
host...@teklinks.com http://mailto:host...@teklinks.com/ or 205.314.6634.
-Original Message-
From: David Favor da...@davidfavor.com
Date: Thursday, July 17, 2014 at 9:18 AM
To: qpsmtpd qpsmtpd@perl.org
Subject: qpsmtpd-async weird ParaDNS
Ed McLain wrote:
For an IP you need to lookup the PTR in reverse notation
(1.0.0.127.in-addr.arpa) vs an A record which is name to IP. PTR is IP to
Name.
Oops... Hit reply rather than reply-all...
Resending via reply-all...
___
If I understand correctly, you're asking about this...
://mailto:host...@teklinks.com/ or 205.314.6634.
-Original Message-
From: David Favor da...@davidfavor.com
Date: Thursday, July 17, 2014 at 10:58 AM
To: Edward McLain emcl...@teklinks.com
Cc: qpsmtpd qpsmtpd@perl.org
Subject: Re: qpsmtpd-async weird ParaDNS lookup problem
Ed McLain wrote
12 matches
Mail list logo