Alex:
Hi,
$ postfix check
postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after
attribute name: warn_if_reject reject_maps_rbl
backscatter.spameatingmonkey.net
Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf,
line 700: missing '=' after attribute name:
On 4/20/2010 10:47 PM, Alex wrote:
Hi,
$ postfix check
postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after
attribute name: warn_if_reject reject_maps_rbl
backscatter.spameatingmonkey.net
Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf,
line 700: missing '='
Hi,
You're still using warn_if_reject wrong; that's why you're getting an error.
If you post your postconf -n we can show you exactly what to change to use
warn_if_reject.
Thanks so much for your help. I've included it below. Ideally I'd like
to have support for smtpd_restriction_classes and
On 4/21/2010 9:31 AM, Alex wrote:
Hi,
You're still using warn_if_reject wrong; that's why you're getting an error.
If you post your postconf -n we can show you exactly what to change to use
warn_if_reject.
Thanks so much for your help. I've included it below. Ideally I'd like
to have
Hi,
$ postfix check
postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after
attribute name: warn_if_reject reject_maps_rbl
backscatter.spameatingmonkey.net
Apr 19 02:35:33 smtp01 postfix[13351]: fatal: /etc/postfix/main.cf,
line 700: missing '=' after attribute name:
Hi,
I'm trying to do:
warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net
wrong syntax. it's
warn_if_reject reject_rbl_client $yourlist
There's no 'equal' sign.
$ postfix check
postfix: fatal: /etc/postfix/main.cf, line 700: missing '=' after
attribute name:
Noel Jones put forth on 4/18/2010 10:55 PM:
Yes, reject_unknown_client_hostname is still too strict for us. And
we're very strict!
I ran with this for a short while. Had problems with it rejecting Hotmail
connections. And these weren't Hotmail user mails beings delivered, but
responses to
Alex put forth on 4/19/2010 12:11 AM:
It looks like I have a big project ahead of me to upgrade. What kind
of process is involved with going from such an old version to the
current, independent of all the other software?
Not much. Just create/modify the new main.cf and any other config files
On 4/19/2010 12:11 AM, Alex wrote:
The warn_if_reject feature predates reject_unauth_pipelining, which you
seem to be using successfully. I strongly suspect there was some other
error -- probably a simple typo in your config -- that kept warn_if_reject
from working for you.
I'm trying to
On Sun, Apr 18, 2010 at 10:38:46PM -0500, Noel Jones wrote:
On 4/18/2010 9:56 PM, /dev/rob0 wrote:
reject_unauth_pipelining,
Might catch some zombies.
Note that with older postfix (postfix 2.6 IIRC)
reject_unauth_pipelining must be used in smtpd_data_restrictions
to be
Alex a écrit :
Hi,
I'm trying to do:
warn_if_reject = reject_rbl_client backscatter.spameatingmonkey.net
wrong syntax. it's
warn_if_reject reject_rbl_client $yourlist
There's no 'equal' sign.
$ postfix check
postfix: fatal: /etc/postfix/main.cf, line 700: missing '='
Hi,
I'm wondering about some messages with Received headers such as this:
Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
spam site), which resolves back to 65.182.186.12. Is this where the
problem is?
I'm
Alex:
Hi,
I'm wondering about some messages with Received headers such as this:
Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
spam site), which resolves back to 65.182.186.12. Is this where the
Hi,
Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
spam site), which resolves back to 65.182.186.12. Is this where the
problem is?
The definition of an unknown client hostname is given in
Alex:
Hi,
? ? Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
spam site), which resolves back to 65.182.186.12. Is this where the
problem is?
The definition of an unknown client hostname is given
Alex a écrit :
Hi,
Received: from zaphod.chipchaps.com (unknown [65.182.186.13])
It says 'unknown', but 65.182.186.13 does resolve, to chipchaps.com (a
spam site), which resolves back to 65.182.186.12. Is this where the
problem is?
The definition of an unknown client hostname is given
Hi,
Is it common practice to have that restriction in a production environment?
It appears to be the third case here, that the name-address mapping
does not match the client IP address. Could this be from a legitimate
cause, or typically intentionally to be evasive?
since they put their
Alex put forth on 4/18/2010 4:45 PM:
Is it possible to use maps_rbl_domains instead of reject_rbl_client
here? It appears this machine has a version of postfix that doesn't
understand reject_rbl_client.
maps_rbl_domains (default: empty)
Obsolete feature: use the reject_rbl_client feature
Hi,
maps_rbl_domains (default: empty)
Obsolete feature: use the reject_rbl_client feature instead.
Yes, that was why I was asking. It's a really old version of postfix
I'm still using on this host for now, until I can migrate to an
entirely new server and at the same time keep this one
Alex:
Hi,
maps_rbl_domains (default: empty)
? ?Obsolete feature: use the reject_rbl_client feature instead.
Yes, that was why I was asking. It's a really old version of postfix
I'm still using on this host for now, until I can migrate to an
entirely new server and at the same time
Note: just before sending this I went back to read the rest of
the thread, wherein I see that you're using a pre-2.0 Postfix. Some
of my advice below is thereby not relevant to this host, namely, the
suggestion to use newer syntax and the newer restriction,
Hi,
reject_unknown_client_hostname :
Is it common practice to have that restriction in a production
environment?
[...]
Note, from the documentation suggested for you, that there are
different conditions which trigger reject_unknown_client_hostname.
Mine was lack of PTR, which also
On 4/18/2010 9:56 PM, /dev/rob0 wrote:
reject_unauth_pipelining,
Might catch some zombies.
Note that with older postfix (postfix 2.6 IIRC)
reject_unauth_pipelining must be used in
smtpd_data_restrictions to be effective. It won't break
anything in
Hi,
Note that with older postfix (postfix 2.6 IIRC) reject_unauth_pipelining
must be used in smtpd_data_restrictions to be effective. It won't break
anything in smtpd_recipient_restrictions, but it won't block anything
either.
Ah, great. I've moved it and it appears to be working (at least
Hi,
http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html
It was only from a few users, but wonder what their experience is
almost a year later.
Yes, reject_unknown_client_hostname is still too strict for us. And we're
very strict!
Good to know. I also don't think I can
Alex(mysqlstud...@gmail.com)@Mon, Apr 19, 2010 at 01:11:01AM -0400:
Hi,
http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html
It was only from a few users, but wonder what their experience is
almost a year later.
Yes, reject_unknown_client_hostname is still too strict
Alex a écrit :
Hi,
Is it common practice to have that restriction in a production environment?
It appears to be the third case here, that the name-address mapping
does not match the client IP address. Could this be from a legitimate
cause, or typically intentionally to be evasive?
since
Alex a écrit :
Hi,
http://www.mail-archive.com/postfix-users@postfix.org/msg12683.html
It was only from a few users, but wonder what their experience is
almost a year later.
Yes, reject_unknown_client_hostname is still too strict for us. And we're
very strict!
Good to know. I also
28 matches
Mail list logo
