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 suppo
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_classe
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 '=' af
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 '='
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:
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
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
>
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
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 fil
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
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
attrib
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
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
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
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
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 l
On 4/18/2010 10:24 PM, Alex wrote:
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 triggers the less aggressive
reject_unknown_reverse_client_hostname restriction. This is fairly
co
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 smtpd_recipient_restrictions
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
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,
reject_unknown_reverse_client_hostnam
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 s
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 r
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 featur
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 th
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" clie
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" cli
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,
>
> 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
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
29 matches
Mail list logo
