Ansgar Wiechers a écrit :
On 2009-10-29 Phillip Smith wrote:
Tell the admin of the remote domain to fix their PTR records and/or
MX helo configuration because in the meantime, you're going to have
to implement a dirty hack to make their server work.
But the PTR needs no fix.
The IP resolves
On 2009-10-31 mouss wrote:
Ansgar Wiechers a écrit :
On 2009-10-29 Phillip Smith wrote:
Then a) it doesn't resolve perfectly -- it should resolve both ways.
And b) any given IP address should only have *one* corresponding PTR
record, not multiple PTR's. For one, it causes problems like this.
On 10/31/2009 10:36 AM, Ansgar Wiechers wrote:
There's also nothing wrong with a setup like this:
192.0.2.1 PTR uranus.example.com.
192.0.2.1 PTR www.example.com.
192.0.2.1 PTR ftp.example.com.
192.0.2.1 PTR blog.example.com.
192.0.2.1
On 2009-10-31 Noel Jones wrote:
On 10/31/2009 10:36 AM, Ansgar Wiechers wrote:
There's also nothing wrong with a setup like this:
192.0.2.1 PTR uranus.example.com.
192.0.2.1 PTR www.example.com.
192.0.2.1 PTR ftp.example.com.
192.0.2.1 PTR
Thanks. I owe you one. That seems to have fixed it.
On Oct 29, 2009, at 2:41 PM, Victor Duchovni wrote:
On Thu, Oct 29, 2009 at 02:35:56PM -0400, Dennis Putnam wrote:
That is a relief when I get to the new version.
In the mean time I am still having trouble with the workaround. My
config
On Wed, 2009-10-28 at 08:45 +1100, Phillip Smith wrote:
2009/10/28 Dennis Putnam dennis.put...@aimaudit.com
Thanks or the reply. That sucks. Is there a way around this,
short of turning that off or whitelisting?
Tell the admin of the remote domain to fix their PTR records
Tell the admin of the remote domain to fix their PTR records and/or MX
helo configuration because in the meantime, you're going to have to
implement a dirty hack to make their server work.
But the PTR needs no fix.
The IP resolves to a hostname perfectly fine , only that the hostname
On 2009-10-29 Phillip Smith wrote:
Tell the admin of the remote domain to fix their PTR records and/or
MX helo configuration because in the meantime, you're going to have
to implement a dirty hack to make their server work.
But the PTR needs no fix.
The IP resolves to a hostname perfectly
Quoting ram r...@netcore.co.in:
On Wed, 2009-10-28 at 08:45 +1100, Phillip Smith wrote:
2009/10/28 Dennis Putnam dennis.put...@aimaudit.com
Thanks or the reply. That sucks. Is there a way around this,
short of turning that off or whitelisting?
Tell the admin of the remote
That is a relief when I get to the new version.
In the mean time I am still having trouble with the workaround. My
config now says:
smtpd_helo_restrictions =
check_client_access cidr:/etc/postfix/heloaccept.cidr
That got rid of the dictionary error however it does not work as I
It is beginning to appear this is my only alternative. However,
maintaining a whilelist will require some special approvals by our
security auditors. In any case, assuming I can get approval, is the
syntax for this the same as the other hash files (ie. IP address
followed by REJECT, OK,
Dennis Putnam:
It is beginning to appear this is my only alternative. However,
maintaining a whilelist will require some special approvals by our
security auditors. In any case, assuming I can get approval, is the
syntax for this the same as the other hash files (ie. IP address
Thanks for the reply. It appears this is not supported with my version
of Postfix (2.1.5). When I try this syntax:
smtpd_helo_restrictions =
check_client_access pcre:/etc/postfix/heloaccept.pcre
I get this error:
fatal: unsupported dictionary type: pcre
On Oct 28, 2009, at 8:16 AM,
Dennis Putnam wrote:
Thanks for the reply. It appears this is not supported with my version
of Postfix (2.1.5). When I try this syntax:
smtpd_helo_restrictions =
check_client_access pcre:/etc/postfix/heloaccept.pcre
I get this error:
fatal: unsupported dictionary type: pcre
Yes. However, that is the version Apple provides with OS X 10.4. OS X
10.6, which has the latest version of Postfix, will not run on PPC
servers so we are in the process of acquiring Intel servers (dictated
by budget issues beyond my control). Unfortunately, I have to deal
with this
Dennis Putnam kirjoitti:
Yes. However, that is the version Apple provides with OS X 10.4. OS X
10.6, which has the latest version of Postfix, will not run on PPC
servers so we are in the process of acquiring Intel servers (dictated by
budget issues beyond my control). Unfortunately, I have to
Management doesn't want me to spend the time doing that since we are
upgrading the servers. Welcome to my world between a rock and a hard
place. :-)
The really bad part is all this configuration stuff will need to be
migrated to the new version of Postfix anyway.
On Oct 28, 2009, at
Dennis Putnam put forth on 10/28/2009 10:53 AM:
Yes. However, that is the version Apple provides with OS X 10.4. OS X
10.6, which has the latest version of Postfix, will not run on PPC
servers so we are in the process of acquiring Intel servers (dictated by
budget issues beyond my control).
Paul Beard put forth on 10/28/2009 11:48 AM:
On Oct 28, 2009, at 9:13 AM, Stan Hoeppner s...@hardwarefreak.com wrote:
Debian GNU/Linux isn't OSX (it's better). Dunno if this is a
possibility for you, but it is an option if you want to keep that PPC
hardware humming away with fully up to
On 10/27/2009, Dennis Putnam (dennis.put...@aimaudit.com) wrote:
I have my Postfix configured to require proper DNS resolution in both
directions. However, I have a situation that is giving me problems
perhaps due to multiple PTR records for the IP address. I am getting the
error:
450
Thanks or the reply. That sucks. Is there a way around this, short of
turning that off or whitelisting?
On Oct 27, 2009, at 11:34 AM, Wietse Venema wrote:
Dennis Putnam:
I have my Postfix configured to require proper DNS resolution in both
directions. However, I have a situation that is
On Tue, Oct 27, 2009 at 01:14:05PM -0400, Dennis Putnam wrote:
Thanks or the reply. That sucks. Is there a way around this, short of
turning that off or whitelisting?
Don't use reject_unknown_client uncondionally. Use it selectively
in a
check_client_access
That is not much different than whitelisting, right? I still have to
maintain a list of permitted networks, do I not?
On Oct 27, 2009, at 1:24 PM, Victor Duchovni wrote:
On Tue, Oct 27, 2009 at 01:14:05PM -0400, Dennis Putnam wrote:
Thanks or the reply. That sucks. Is there a way around
2009/10/28 Dennis Putnam dennis.put...@aimaudit.com
Thanks or the reply. That sucks. Is there a way around this, short of
turning that off or whitelisting?
Tell the admin of the remote domain to fix their PTR records and/or MX helo
configuration because in the meantime, you're going to have
24 matches
Mail list logo