On 10/04/23 16:52, tom--- via Postfix-users wrote:
The default_action here actually defines what action postfix will take
if the policyd errors out (e.g. not running). By default this is "451
4.3.5 Server configuration problem" which results in a deferral, so it
would not cause the message to
On April 10, 2023 4:52:04 AM UTC, tom--- via Postfix-users
wrote:
>On 2023-04-10 12:39, Peter via Postfix-users wrote:
>> On 10/04/23 14:21, tom--- via Postfix-users wrote:
>>> I have resolved the issue by:
>>>
>>> 1. install unbound as dns resolver locally
>>
>> This is good.
>>
>>> 2.
On 2023-04-10 12:39, Peter via Postfix-users wrote:
On 10/04/23 14:21, tom--- via Postfix-users wrote:
I have resolved the issue by:
1. install unbound as dns resolver locally
This is good.
2. change this statement:
check_policy_service unix:private/policyd-spf,
to this one:
On 10/04/23 14:21, tom--- via Postfix-users wrote:
I have resolved the issue by:
1. install unbound as dns resolver locally
This is good.
2. change this statement:
check_policy_service unix:private/policyd-spf,
to this one:
check_policy_service { unix:private/policyd-spf,
On 2023-04-09 10:02, t...@myposts.ovh wrote:
I have this setting in main.cf:
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_policy_service unix:private/policyd-spf,
reject_rbl_client zen.spamhaus.org
On 9/04/23 23:02, Peter via Postfix-users wrote:
On 9/04/23 21:23, tom--- via Postfix-users wrote:
I am using the policyd-spf by default configuration (never changed a
line), and this is the doc:
https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html
But the
,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net
When I sent message from a Spamhaus Zen listed IP (this IP not in my
whitelist), the message still came into system.
it seemsreject_rbl_client zen.spamhaus.org has no effect.
Where should i debug it?
By studying Postfix
tom--- via Postfix-users:
> I have this setting in main.cf:
>
> smtpd_recipient_restrictions =
> permit_mynetworks,
> permit_sasl_authenticated,
> reject_unauth_destination,
> check_policy_service unix:private/policyd-spf,
> reject_rbl
On 9/04/23 21:23, tom--- via Postfix-users wrote:
I am using the policyd-spf by default configuration (never changed a
line), and this is the doc:
https://manpages.debian.org/testing/postfix-policyd-spf-python/policyd-spf.conf.5.en.html
But the doc says noting about "OK" and "DUNNO". so how?
tom--- via Postfix-users skrev den 2023-04-09 09:51:
what action code policyd should return for passing the request to next
check?
DUNNO
as in https://doc.dovecot.org/configuration_manual/quota_plugin/
90-quota.conf example
___
Postfix-users
tom--- via Postfix-users skrev den 2023-04-09 08:18:
I was exactly using google DNS. Do u mean Google will block queries for
RBL?
incorrect questions gives incorrect answers
google does not block you, but the rbls is blocking google
we all live in a free world of unlimited problems to solve
unix:private/policyd-spf,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net
When I sent message from a Spamhaus Zen listed IP (this IP not in my
whitelist), the message still came into system.
it seemsreject_rbl_client zen.spamhaus.org has no effect.
Where should i debug
tom--- via Postfix-users skrev den 2023-04-09 04:02:
I have this setting in main.cf:
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_policy_service unix:private/policyd-spf,
reject_rbl_client zen.spamhaus.org
On 9/04/23 19:51, tom--- via Postfix-users wrote:
First off make sure that policyd isn't somehow returning an OK (or
equivalent) response, if you're not sure temporarily remove
"check_policy_service unix:private/policyd-spf," from your
restrictions above and see if it makes a difference.
On 9/04/23 18:18, tom--- via Postfix-users wrote:
Secondly, and this is *very* important, make certain you are not using
your ISP's or another public DNS resolver (such as 8.8.8.8). You
*must* run your own DNS resolver for DNSRBLs to work properly.
I was exactly using google DNS. Do u mean
> smtpd_recipient_restrictions =
>permit_mynetworks,
>permit_sasl_authenticated,
>reject_unauth_destination,
>check_policy_service unix:private/policyd-spf,
> reject_rbl_client zen.spamhaus.org,
>reject_rbl_client bl.spamcop.net
>
> When I sent
/policyd-spf,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net
When I sent message from a Spamhaus Zen listed IP (this IP not in my
whitelist), the message still came into system.
it seems reject_rbl_client zen.spamhaus.org has no effect.
Where should i debug it?
First
On 9 Apr 2023, at 08:18, tom--- via Postfix-users
wrote:
>
>> First off make sure that policyd isn't somehow returning an OK (or
>> equivalent) response, if you're not sure temporarily remove
>> "check_policy_service unix:private/policyd-spf," from your restrictions
>> above and see if it
/policyd-spf,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net
When I sent message from a Spamhaus Zen listed IP (this IP not in my
whitelist), the message still came into system.
it seems reject_rbl_client zen.spamhaus.org has no effect.
Where should i debug it?
First
On 9/04/23 14:02, tom--- via Postfix-users wrote:
I have this setting in main.cf:
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_policy_service unix:private/policyd-spf,
reject_rbl_client zen.spamhaus.org
rivate/policyd-spf,
> reject_rbl_client zen.spamhaus.org,
> reject_rbl_client bl.spamcop.net
> When I sent message from a Spamhaus Zen listed IP (this IP not in my
> whitelist), the message still came into system.
> it seemsreject_rbl_client zen.spamhaus.org has no effect.
> Wher
I have this setting in main.cf:
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
check_policy_service unix:private/policyd-spf,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net
When I sent message from
> Ok, we deal with access map file. That's the manual:
>
> http://www.postfix.org/access.5.html
>
> And it says about logical lines and continuation lines and avaliable
> lookup patterns and actions.
>
> But I can't clearly get :
>
> - How multiple actions (checks) works against one pattern
> > check_sender_access,
> > hash:/etc/postfix/dnsbl_checks
> > ...
> /etc/postfix/dnsbl_checks:
>
> > open-talk.ru reject_rbl_client rbl.rbldns.ru, reject_rbl_client
That applies 'reject_rbl_client b.barracudacentral.org' to op
> I have following configuration working on postfix 2.6, broken up on
> postfix 3.1:
>
> master.cf:
>
> > smtpd pass -- n - - smtpd
> > ...
> > -o { smtpd_recipient_restrictions =
> > ...
master.cf does not support "-o { name = value }" syntax before
...
/etc/postfix/per_recipient_rules:
# most example.com recipients are RBL protected, some are not.
example.comreject_rbl_client zen.spamhaus.org, reject_rbl_client
rbl.rbldns.ru, ...
some...@example.com dunno
...
Wietse
On 28.04.2016 13:28, Wietse Venema
; >>>>> permit_mynetworks
> >>>>> reject_unauth_destination
> >>>>> check_recipient_access hash:/etc/postfix/rbl_rules
> >>>>/etc/postfix/rbl_rules :
> >>>>>reject_rbl_client zen.spamhaus.org
> >>>>>r
eject_unauth_destination
> check_recipient_access hash:/etc/postfix/per_recipient_rules
> ...
>
> /etc/postfix/per_recipient_rules:
> # most example.com recipients are RBL protected, some are not.
> example.com reject_rbl_client zen.spamhaus.org, reject_rb
=
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/per_recipient_rules
...
/etc/postfix/per_recipient_rules:
# most example.com recipients are RBL protected, some are not.
example.comreject_rbl_client zen.spamhaus.org
ted, some are not.
example.com reject_rbl_client zen.spamhaus.org, reject_rbl_client
rbl.rbldns.ru, ...
some...@example.com dunno
...
Wietse
> On 28.04.2016 13:28, Wietse Venema wrote:
> > ? ?:
> >> Hi, list !
> >> I need to place rbl rules with do
something like this:
smtpd_recipient_restrictions =
permit_mynetworks
reject_unauth_destination
check_recipient_access hash:/etc/postfix/rbl_rules
/etc/postfix/rbl_rules :
reject_rbl_client zen.spamhaus.org
reject_rbl_client rbl.rbldns.ru
reject_rbl_client b.barracudacentral.org
t; >reject_unauth_destination
> >check_recipient_access hash:/etc/postfix/rbl_rules
>
> /etc/postfix/rbl_rules :
> > reject_rbl_client zen.spamhaus.org
> > reject_rbl_client rbl.rbldns.ru
> > reject_rbl_client b.barracudacentral.org
> > reject_rbl_client dnsbl.sorbs.net
&
/etc/postfix/rbl_rules :
reject_rbl_client zen.spamhaus.org
reject_rbl_client rbl.rbldns.ru
reject_rbl_client b.barracudacentral.org
reject_rbl_client dnsbl.sorbs.net
reject_rbl_client bl.spamcop.net
I need it to be highly flexible. To let people in my network configure
DNSBL server list whenever
On 1/7/2016 2:19 PM, Quanah Gibson-Mount wrote:
> --On Thursday, January 07, 2016 9:06 PM +0100 lutz.niede...@gmx.net
> wrote:
>
>>
>>
>> postfix version 2.9.3-2.1 on debian
>>
>> Hi!
>>
>> I found something really strange. Maybe someone can
--On Thursday, January 07, 2016 9:06 PM +0100 lutz.niede...@gmx.net wrote:
postfix version 2.9.3-2.1 on debian
Hi!
I found something really strange. Maybe someone can explain this to me.
reject_rbl_client docu says "... If no "=d.d.d.d" is specified, reject
the request wh
On 7/3/2015 10:04 PM, Jim Garrison wrote:
I use
reject_rbl_client zen.spamhaus.org,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client cbl.abuseat.org,
which I find catches about 98% of SPAM.
I also receive mail at an address that is a forwarding
I use
reject_rbl_client zen.spamhaus.org,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client cbl.abuseat.org,
which I find catches about 98% of SPAM.
I also receive mail at an address that is a forwarding mailbox and
sends mail to my Postfix server
Hi,
I recompiled postfix without -lpthread, same effect...
Steven
On Fri, Dec 12, 2014 at 09:38:51AM +0100, s.sm...@gmx.ch wrote:
I recompiled postfix without -lpthread, same effect...
Might not help if other libraries Postfix uses are linked
with -lpthread.
Post the output of ldd for $daemon_directory/smtpd.
And of course the problem might lie elsewhere,
Viktor Dukhovni:
On Fri, Dec 12, 2014 at 09:38:51AM +0100, s.sm...@gmx.ch wrote:
I recompiled postfix without -lpthread, same effect...
Might not help if other libraries Postfix uses are linked
with -lpthread.
Post the output of ldd for $daemon_directory/smtpd.
And of course the
Wietse Venema:
Are there enough OpenBSD Postfix users to warrant real effort to
tackle the problem? I thought that generally OpenBSD (or perhaps
at least Theo) was antagonistic to Postfix for some sort of licensing
reasons, or perhaps for some other convenient reason.
This would affect
config.
I guess this means that I have to ak openBSD?
cheers
Steven
-Ursprüngliche Nachricht-
From: Wietse Venema
Sent: Thursday, December 4, 2014 8:01 PM
To: A. Schulze
Cc: postfix-users@postfix.org
Subject: Re: Problem with reject_rbl_client when a wildcard entry for
mydomain exists
PM
To: A. Schulze
Cc: postfix-users@postfix.org
Subject: Re: Problem with reject_rbl_client when a wildcard entry for
mydomain exists
A. Schulze:
Viktor Dukhovni:
general advice: check your /etc/resolv.conf
usually there is no need for other lines then nameserver
On Mon, Dec 08, 2014 at 11:01:57AM -0500, Wietse Venema wrote:
/var/spool/postfix/etc/resolv.conf contains
lookup file bind
nameserver 172.16.161.2
Does the problem go away with:
lookup bind
i.e. remove file lookups.
I would expect not, though this is in /etc/resolv.conf (I
-users@postfix.org
Subject: Re: Problem with reject_rbl_client when a wildcard entry for
mydomain exists
A. Schulze:
Viktor Dukhovni:
general advice: check your /etc/resolv.conf
usually there is no need for other lines then nameserver
$NAMESERVER_IP
especially check
Hi,
We experience problems when using reject_rbl_client if a wildcard entry for
mydomain exists. It appears that a DNS lookup is first made with [ip].[rbl]
and than with [ip].[rbl].[mydomain] if no entry has been found.
This leads to false positives if a DNS wildcard entry for xxx.[mydomain
s.sm...@gmx.ch:
Hi,
We experience problems when using reject_rbl_client if a wildcard entry for
mydomain exists. It appears that a DNS lookup is first made with [ip].[rbl]
and than with [ip].[rbl].[mydomain] if no entry has been found.
This leads to false positives if a DNS wildcard entry
s.small:
It appears that a DNS lookup is first made with [ip].[rbl] and
than with [ip].[rbl].[mydomain] if no entry has been found.
general advise: check your /etc/resolv.conf
usually there is no need for other lines then nameserver $NAMESERVER_IP
especially check if searchdomain is present
On Thu, Dec 04, 2014 at 07:31:42PM +0100, A. Schulze wrote:
It appears that a DNS lookup is first made with [ip].[rbl] and
than with [ip].[rbl].[mydomain] if no entry has been found.
Postfix explicitly disables RES_DNSRCH | RES_DEFNAMES in the
resolver options when doing MX, rbl and other
Viktor Dukhovni:
general advice: check your /etc/resolv.conf
usually there is no need for other lines then nameserver $NAMESERVER_IP
especially check if searchdomain is present and needed and should be
removed.
This advice is not right, Postfix works ...
Yes, BUT:
I had not only postfix
A. Schulze:
Viktor Dukhovni:
general advice: check your /etc/resolv.conf
usually there is no need for other lines then nameserver $NAMESERVER_IP
especially check if searchdomain is present and needed and should be
removed.
This advice is not right, Postfix works ...
Yes, BUT:
On Mon, Feb 11, 2013 at 10:29:38PM +, Fabii Sangiovanni wrote:
Viktor Dukhovni postfix-users at dukhovni.org writes:
You're working too hard, the suggested settings should work just fine.
Would you be so kind to point me to some readings on the matter?
You don't want to explicitly
Noel Jones njones at megan.vbhcs.org writes:
Seems like the easiest solution is to put permit_sasl_authenticated
BEFORE reject_rbl_client. Then no whitelisting is needed.
-- Noel Jones
Hi, thanks for your answer.
Yes, that would be useful, except for malware that steals your credentials
On 2/11/2013 4:00 AM, Fabio Sangiovanni wrote:
Noel Jones njones at megan.vbhcs.org writes:
Seems like the easiest solution is to put permit_sasl_authenticated
BEFORE reject_rbl_client. Then no whitelisting is needed.
-- Noel Jones
Hi, thanks for your answer.
Yes, that would
Noel Jones njones at megan.vbhcs.org writes:
Your method of manually whitelisting any IP that happens to be
spamhaus listed doesn't scale very well. Every time some authorized
user travels somewhere, stops at a wifi hotspot, or their home IP
changes, will need to call you to get whitelisted
Viktor Dukhovni postfix-users at dukhovni.org writes:
Replace OK with:
/etc/postfix/whitelist_client.cidr:
192.0.2.1/32permit_sasl_authenticated
Sorry Viktor,
I have another question: what happens if a client is whitelisted AND it fails
SASL authentication?
I suppose that
On Mon, Feb 11, 2013 at 03:19:52PM +, Fabio Sangiovanni wrote:
I have another question: what happens if a client is whitelisted AND it fails
SASL authentication?
The whitelist only applies to authenticated users. Unauthenticated users
are treated like everyone else.
I suppose that the
Viktor Dukhovni postfix-users at dukhovni.org writes:
You're working too hard, the suggested settings should work just fine.
Would you be so kind to point me to some readings on the matter? The only
relevant piece of documentation seems to be RESTRICTION_CLASS_README, but, even
after reading
of recipent domains we don't want to send mail to):
smtpd_recipient_restrictions =
reject_rbl_client zen.spamhaus.org,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
check_recipient_access hash:/etc/postfix/domain.hash
=
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
check_recipient_access hash:/etc/postfix/domain.hash,
check_client_access cidr:/etc/postfix/whitelist_client.cidr,
reject_rbl_client zen.spamhaus.org,
permit_sasl_authenticated
Viktor Dukhovni postfix-users at dukhovni.org writes:
Replace OK with:
/etc/postfix/whitelist_client.cidr:
192.0.2.1/32permit_sasl_authenticated
Awesome. I totally missed this part of documentation:
http://www.postfix.org/access.5.html
[...]
OTHER ACTIONS
of restrictions
(/etc/postfix/domain.hash is a list of recipent domains we don't
want to send mail to):
smtpd_recipient_restrictions =
reject_rbl_client zen.spamhaus.org,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain
/rfc5782
For startes, only 127/8 is allowed in DNSxL replies. 127.0.0.1 is NOT
allowed. You may also want to put a help box on the screen with the
Posttfix documentation for reject_rbl_client, or a more average person
digestible version of it. I assume this is a control panel for paying
customers
to read the RFC here:
http://tools.ietf.org/html/rfc5782
For startes, only 127/8 is allowed in DNSxL replies. 127.0.0.1 is NOT
allowed. You may also want to put a help box on the screen with the
Posttfix documentation for reject_rbl_client, or a more average person
digestible version of it. I assume
On 12/11/2012 04:17 AM, Stan Hoeppner wrote:
On 12/10/2012 2:38 AM, martijn.list wrote:
It's probably my misunderstanding on the reject_rbl_client syntax
No, it's your misunderstanding of the dnsbl reply syntax.
reject_rbl_client example.com=[127;128].0.0.1
I use this as a restriction
It's probably my misunderstanding on the reject_rbl_client syntax but if
I use the following reject_rbl_client configuration , the mail logs
tells me that the reject_rbl_client syntax is invalid:
reject_rbl_client example.com=[127;128].0.0.1
I use this as a restriction
martijn.list:
It's probably my misunderstanding on the reject_rbl_client syntax but if
I use the following reject_rbl_client configuration , the mail logs
tells me that the reject_rbl_client syntax is invalid:
reject_rbl_client example.com=[127;128].0.0.1
I use this as a restriction
On 12/10/2012 2:38 AM, martijn.list wrote:
It's probably my misunderstanding on the reject_rbl_client syntax
No, it's your misunderstanding of the dnsbl reply syntax.
reject_rbl_client example.com=[127;128].0.0.1
I use this as a restriction in smtpd_recipient_restrictions
Another thing I think I see about postscreen is that it apparently will only
look up IP addresses. There doesn't seem to be any postscreen_rhsbl_sites
feature (which might allow me to move my current reject_rhsbl_client and
permit_rhswl_client checks into postscreen). Is such a thing planned,
On 6/8/2011 12:05 PM, Rich Wales wrote:
Another thing I think I see about postscreen is that it apparently will only
look up IP addresses. There doesn't seem to be any postscreen_rhsbl_sites
feature (which might allow me to move my current reject_rhsbl_client and
permit_rhswl_client checks into
On Wed, Jun 08, 2011 at 10:05:05AM -0700, Rich Wales wrote:
Another thing I think I see about postscreen is that it apparently
will only look up IP addresses. There doesn't seem to be any
postscreen_rhsbl_sites feature (which might allow me to move my
current reject_rhsbl_client and
Rich Wales:
Another thing I think I see about postscreen is that it apparently will only
look up IP addresses. There doesn't seem to be any postscreen_rhsbl_sites
feature (which might allow me to move my current reject_rhsbl_client and
permit_rhswl_client checks into postscreen). Is such a
* Rich Wales ri...@richw.org:
If I enable postscreen and specify my choice of blocklists and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I might as well
remove any reject_rbl_client and permit_dnswl_client clauses from my
smtpd_*_restrictions, since they will now
* Rich Wales ri...@richw.org:
value from a given list. (I won't go into the details, they would be
off-topic here, but it's nice to have this capability.)
It will probably start a flamewar, but I personally am interested in
your particular weights on the different RBLs
--
Ralf Hildebrandt
Rich Wales:
Note that postscreen caches the results of successful tests,
so that it does not repeat every test for every connection.
This is controlled by the postscreen_mumble_ttl parameters.
Some caching may also be done by my DNS server too, right? This would,
of course, be
On Tue, Jun 07, 2011 at 07:03:34AM -0400, Wietse Venema wrote:
Note the following difference.
postscreen caches that the client IS NOT listed in DNSBL.
It doesn't cache clients that are listed.
DNS servers cache that the client IS listed in DNSBL.
They don't cache non-existent DNSBL
If I enable postscreen and specify my choice of blocklists and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I might as well
remove any reject_rbl_client and permit_dnswl_client clauses from my
smtpd_*_restrictions, since they will now be redundant?
Rich Wales
ri
On 06/06/2011 10:45 PM, Rich Wales wrote:
If I enable postscreen and specify my choice of blocklists and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I might as well
remove any reject_rbl_client and permit_dnswl_client clauses from my
smtpd_*_restrictions, since
On 6/6/2011 5:34 PM, Jeroen Geilman wrote:
On 06/06/2011 10:45 PM, Rich Wales wrote:
If I enable postscreen and specify my choice of blocklists
and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I
might as well
remove any reject_rbl_client and permit_dnswl_client clauses
On the interfaces and ports that postscreen(8) passes mail to, yes.
Do note that the behaviour is different; you will be able to directly
transplant your reject_rbl_client RBLs to postscreen, but postscreen
has many more options available, such as checking for exact return
values, and scoring
Rich Wales:
If I enable postscreen and specify my choice of blocklists and whitelists
in postscreen_dnsbl_sites, am I correct in assuming that I might as well
remove any reject_rbl_client and permit_dnswl_client clauses from my
smtpd_*_restrictions, since they will now be redundant?
Almost
Note that postscreen caches the results of successful tests,
so that it does not repeat every test for every connection.
This is controlled by the postscreen_mumble_ttl parameters.
Some caching may also be done by my DNS server too, right? This would,
of course, be transparent to Postfix and
Rich Wales:
Note that postscreen caches the results of successful tests,
so that it does not repeat every test for every connection.
This is controlled by the postscreen_mumble_ttl parameters.
Some caching may also be done by my DNS server too, right? This would,
of course, be
for the IP, then
put the message on HOLD - rather than rejecting it?
smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/check_backscatterer,
...
# cat check_backscatterer
# reject_rbl_client ips.backscatterer.org
#postmaster reject_rbl_client ips.backscatterer.org
Thanks
than rejecting it?
smtpd_recipient_restrictions =
...
check_sender_access hash:/etc/postfix/check_backscatterer,
...
# cat check_backscatterer
# reject_rbl_client ips.backscatterer.org
#postmaster reject_rbl_client ips.backscatterer.org
Have you considered warn_if_reject? If you
Il 24/03/2011 02:46, Sahil Tandon ha scritto:
On Thu, 2011-03-24 at 14:35:06 +1300, Simon wrote:
.. [CUT] ..
Have you considered warn_if_reject? If you must HOLD such mail, plug in
a policy service that returns HOLD for IPs listed on the RBL.
Sahil.. i've a similar need, could you put me
On Thu, 2011-03-24 at 03:07:05 +0100, Amedeo Rinaldo wrote:
Il 24/03/2011 02:46, Sahil Tandon ha scritto:
On Thu, 2011-03-24 at 14:35:06 +1300, Simon wrote:
.. [CUT] ..
Have you considered warn_if_reject? If you must HOLD such mail, plug in
a policy service that returns HOLD for IPs
On Thu, Mar 24, 2011 at 3:10 PM, Sahil Tandon sa...@freebsd.org wrote:
On Thu, 2011-03-24 at 03:07:05 +0100, Amedeo Rinaldo wrote:
Il 24/03/2011 02:46, Sahil Tandon ha scritto:
On Thu, 2011-03-24 at 14:35:06 +1300, Simon wrote:
.. [CUT] ..
Have you considered warn_if_reject? If you must
On Thu, Mar 24, 2011 at 03:37:45PM +1300, Simon wrote:
On Thu, Mar 24, 2011 at 3:10 PM, Sahil Tandon sa...@freebsd.org
wrote:
On Thu, 2011-03-24 at 03:07:05 +0100, Amedeo Rinaldo wrote:
Il 24/03/2011 02:46, Sahil Tandon ha scritto:
On Thu, 2011-03-24 at 14:35:06 +1300, Simon wrote:
On Thu, Mar 24, 2011 at 4:04 PM, /dev/rob0 r...@gmx.co.uk wrote:
As to how to implement this in postfwd, this is not the right forum
for such a question. http://postfwd.org/ has instructions on how to
join the postfwd-users mailing list.
What a fantastic piece of software!! Thanks :)
this. Reject the spam during the SMTP connection.
This is costy in management.
If you have filters with higher accuracy that don't cause FPs it's not
costly in management.
Try this out for a week or two:
1. Comment out your SORBS entries in main.cf
2. Implement reject_rbl_client
On Thu, 2010-10-28 at 07:52 -0400, John Peach wrote:
Right, so, how is THAT a false positive, it is a justifiable listing
if they became part of the problem.
I never said it was a false positive. Just that it's a waste of time
trying to get delisted; we gave up with that years ago.
On Thu, 2010-10-28 at 09:40 -0400, Wietse Venema wrote:
.
This illustrates what you get when blocking all mail from an ISP
just because some customer sent some email that hit some spamtrap.
We do it here, I've done it for 5 years or so, little problems at all
given the
Hehe, noticed I've got just 2 replies on my thread from Noel Butler,
rest is missing:
.
Oct 28 11:30:50 darkstar postfix/smtpd[17528]: NOQUEUE: reject: RCPT
from camomile.cloud9.net[168.100.1.3]: 554 5.7.1 Service unavailable;
Client host [168.1
00.1.3] blocked using spam.dnsbl.sorbs.net;
On Thu, 2010-10-28 at 12:37 +0300, Покотиленко Костик wrote:
Hehe, noticed I've got just 2 replies on my thread from Noel Butler,
rest is missing:
LOL, hrmm Q, is the postfix lists the only mail coming from
camomile.cloud9.net? or do these servers host other stuff as well
.
Oct
entries in main.cf
2. Implement reject_rbl_client b.barracudacentral.org
See http://www.barracudacentral.org/rbl as sign up is required
3. Implement this dynamic/generic (residential/zombie) blocking PCRE
check_client_access pcre:/etc/postfix/fqrdns.pcre
http
В Чтв, 28/10/2010 в 19:59 +1000, Noel Butler пишет:
On Thu, 2010-10-28 at 12:37 +0300, Покотиленко Костик wrote:
Hehe, noticed I've got just 2 replies on my thread from Noel Butler,
rest is missing:
LOL, hrmm Q, is the postfix lists the only mail coming from
camomile.cloud9.net? or do
On Tue, 2010-10-26 at 14:11 +0300, Покотиленко Костик wrote:
sorbs.net is very agressive, many ISPs get blocked for several years
and are not willing to delist b/c sorbs doesn't offer free delist
for them.
That is complete FUD, yes, I know what their website says, but knowing
the
On Wed, 2010-10-27 at 22:15 -0400, John Peach wrote:
On Thu, 28 Oct 2010 11:17:00 +1000 Noel Butler noel.butler at
ausics.net wrote: On Tue, 2010-10-26 at 14:11 +0300, Покотиленко
Костик wrote: sorbs.net is very agressive, many ISPs get
blocked for several years and are not
On Thu, 2010-10-28 at 14:13 +0300, Покотиленко Костик wrote:
I have an automated script that runs over all of our mail servers log
files daily searching for IP's that send to
known spamtrap addresses and also on my private server (this domain),
addresses that never existed, and can't
1 - 100 of 140 matches
Mail list logo
