On 2014.12.15 23.51, Peter wrote:
On 12/16/2014 07:22 AM, btb wrote:
with various sized netblocks rejected therein. this all works fine.
i have more than one mx, and would like to store this data in a
centralized location and query over the network instead of
duplicating the files on each mx.
On 16. dec. 2014 05.24.09 b...@bitrate.net wrote:
i'll have to think more about this.
1: rsync replication && postfix reload
2: postgresql replication && live replicate in postgresql
Option 2 just need postgresql in postfix since postgresql support cidr natively
Option 1 is damm simple
--On Monday, December 15, 2014 11:23 PM -0500 b...@bitrate.net wrote:
for sql though, i envisioned a query that would return the same data that
would be read from the text file, a list of patterns and a matching
result for each, for postfix to iterate through. i know this would be a
different
On 12/16/2014 07:22 AM, btb wrote:
> with various sized netblocks rejected therein. this all works fine.
> i have more than one mx, and would like to store this data in a
> centralized location and query over the network instead of
> duplicating the files on each mx. i don't believe postfix can
>
On Dec 15, 2014, at 17.47, Wietse Venema wrote:
> btb:
>> hi-
>>
>> i currently have:
>>
>> postscreen_access_list = cidr:$table_directory/postscreen_access_list.cidr
>>
>> with various sized netblocks rejected therein. this all works
>> fine. i have more than one mx, and would like to store
btb:
> hi-
>
> i currently have:
>
> postscreen_access_list = cidr:$table_directory/postscreen_access_list.cidr
>
> with various sized netblocks rejected therein. this all works
> fine. i have more than one mx, and would like to store this data
> in a centralized location and query over the ne
El 10.06.2014 20:47, Viktor Dukhovni escribió:
There is no single right answer. For many users a single linear
list of conditions is simplest. For some users, where one wants
a whitelist for one set of test to not short-circuit other tests,
multiple lists are better. We should not be dogmatic
10.06.2014 22:43, Stan Hoeppner wrote:
> On 6/10/2014 1:24 AM, Michael Tokarev wrote:
[]
>> it all to one stage it becomes clumsier. Also, moving stuff which should
>> be run at connect or hello time to recipient time is kinda wrong.
>
> Postfix performs delayed evaluation of restrictions by defa
On Tue, Jun 10, 2014 at 01:43:50PM -0500, Stan Hoeppner wrote:
> > I'm sorry to say that, but this is wrong. All smtpd_*_restrictions give
> > precise control over all the restrictions and their order, if you move
>
> "will give you precise control". Note "you", meaning the user, not
> Postfix.
On 6/10/2014 1:24 AM, Michael Tokarev wrote:
> 10.06.2014 05:02, Stan Hoeppner wrote:
...
>> Yes. And if you have other separate smtpd_foo_restrictions sections you
>> should move those restriction parameters under
>> smtpd_recipient_restrictions as well. This will give you precise
>> control ove
Ronald F. Guilmette:
>
> I really should have figured this out ages ago, but...
>
> Quite simply, there exits a small number of organizations that
> run afoul of my various smtpd_recipient_restrictions and/or my
> smtpd_helo_restrictions, but from which I need to be able to
> receive mail anyway.
10.06.2014 05:02, Stan Hoeppner wrote:
> On 6/9/2014 7:12 PM, Ronald F. Guilmette wrote:
>> I really should have figured this out ages ago, but...
>>
>> Quite simply, there exits a small number of organizations that
>> run afoul of my various smtpd_recipient_restrictions and/or my
>> smtpd_helo_res
On 6/9/2014 7:12 PM, Ronald F. Guilmette wrote:
> I really should have figured this out ages ago, but...
>
> Quite simply, there exits a small number of organizations that
> run afoul of my various smtpd_recipient_restrictions and/or my
> smtpd_helo_restrictions, but from which I need to be able t
LuKreme:
> 220.73.0.0/255.255.0.0 reject
TABLE FORMAT
The general form of a Postfix CIDR table is:
network_address/network_mask result
When a search string matches the specified network block, use
the corresponding result value. Specify 0.
On Mon, Jun 18, 2012 at 02:01:34PM -0300, Marcio Merlone wrote:
> Greetings,
>
> I have googled a little and just found "not possible" for this,
> please advice me if this is still true or not. I want to store
> mynetworks on LDAP, but seems there is no way to make something like
> a cidr:ldap: t
On 09.04.2012 15:19, /dev/rob0 wrote:
On Mon, Apr 09, 2012 at 02:23:14PM +0200, tobi wrote:
I wonder if it's somehow possible to block client ips from a cidr
map for a certain receiver address only. I have some addresses for
which I do not want clients from certain providers to send mail to.
Wit
On Mon, Apr 09, 2012 at 02:23:14PM +0200, tobi wrote:
> I wonder if it's somehow possible to block client ips from a cidr
> map for a certain receiver address only. I have some addresses for
> which I do not want clients from certain providers to send mail to.
> With a cidr map in smtpd_client_r
On 12/20/2011 02:13 AM, Wietse Venema wrote:
Stan Hoeppner:
[ Charset ISO-8859-1 unsupported, converting... ]
On 12/19/2011 5:10 PM, Stan Hoeppner wrote:
On 12/19/2011 12:44 PM, Wietse Venema wrote:
Tolga:
I did like you said (did a postmap -q ip.add.ress.here
cidr:sinokorea.cidr). Today, I
Stan Hoeppner:
[ Charset ISO-8859-1 unsupported, converting... ]
> On 12/19/2011 5:10 PM, Stan Hoeppner wrote:
> > On 12/19/2011 12:44 PM, Wietse Venema wrote:
> >> Tolga:
> >>> I did like you said (did a postmap -q ip.add.ress.here
> >>> cidr:sinokorea.cidr). Today, I thought I'd check logs, and o
On 12/19/2011 5:10 PM, Stan Hoeppner wrote:
> On 12/19/2011 12:44 PM, Wietse Venema wrote:
>> Tolga:
>>> I did like you said (did a postmap -q ip.add.ress.here
>>> cidr:sinokorea.cidr). Today, I thought I'd check logs, and one thing I
>>> noticed is Dec 19 20:09:24 bilgisayarciniz postfix/smtpd[161
On 12/19/2011 12:44 PM, Wietse Venema wrote:
> Tolga:
>> I did like you said (did a postmap -q ip.add.ress.here
>> cidr:sinokorea.cidr). Today, I thought I'd check logs, and one thing I
>> noticed is Dec 19 20:09:24 bilgisayarciniz postfix/smtpd[16163]:
>> NOQUEUE: reject: RCPT from mail2-188.sinam
Tolga:
> I did like you said (did a postmap -q ip.add.ress.here
> cidr:sinokorea.cidr). Today, I thought I'd check logs, and one thing I
> noticed is Dec 19 20:09:24 bilgisayarciniz postfix/smtpd[16163]:
> NOQUEUE: reject: RCPT from mail2-188.sinamail.sina.com.cn[60.28.2.188]:
> 451 4.3.5 Server co
Forgot to CC
Original Message
Subject:Re: CIDR
Date: Mon, 19 Dec 2011 20:27:50 +0200
From: Tolga
To: s...@hardwarefreak.com
On 18-12-2011 13:36, Stan Hoeppner wrote:
On 12/18/2011 4:49 AM, Duane Hill wrote:
Hi, I've confirmed that the IP is from
On 12/18/2011 4:49 AM, Duane Hill wrote:
>>> Hi, I've confirmed that the IP is from China, using www.ip2location.com.
>> My CIDR file is at www.bilgisayarciniz.org/sinokorea.cidr.txt
Bingo. Your CIDR table doesn't work because you have not specified a
RESULT for each network_address. You only p
On Sunday, December 18, 2011 at 08:41:48 UTC, to...@ozses.net confabulated:
> On 18 December 2011 00:34, Stan Hoeppner wrote:
>> On 12/17/2011 2:32 PM, Ansgar Wiechers wrote:
>> > On 2011-12-17 Tolga wrote:
>> >> I've been getting a lot of Chinese spam. I've googled and come across
>> >> a guide
On 18 December 2011 00:34, Stan Hoeppner wrote:
> On 12/17/2011 2:32 PM, Ansgar Wiechers wrote:
> > On 2011-12-17 Tolga wrote:
> >> I've been getting a lot of Chinese spam. I've googled and come across
> >> a guide that advises to use a cidr file and tell postfix to use it. I
> >> got the file, e
On 12/17/2011 2:32 PM, Ansgar Wiechers wrote:
> On 2011-12-17 Tolga wrote:
>> I've been getting a lot of Chinese spam. I've googled and come across
>> a guide that advises to use a cidr file and tell postfix to use it. I
>> got the file, edited it, and told postfix to use it. However, it
>> doesn't
On 2011-12-17 Tolga wrote:
> I've been getting a lot of Chinese spam. I've googled and come across
> a guide that advises to use a cidr file and tell postfix to use it. I
> got the file, edited it, and told postfix to use it. However, it
> doesn't seem to be working (I tested it by putting in my ow
Le 14/11/2010 11:58, Jack a écrit :
Hello All,
I want to confirm that what I want to try wont break anything. I want to
use a CIDR list and reject messages.
That I can tell I need to do this:
smtpd_client_restrictions =
check_client_access cidr:/usr/local/etc/postfix/maps/ip.cidr,
On 11/05/2010 02:16 PM, Mark Martinec wrote:
Jeroen Geilman wrote:
for (entry = list; entry; entry = entry->next) {
Each map is a linked list of CIDR patterns, so consolidate as much as
possible - 10 single IPs will cause noticable delays when the last
entry matches!
Funny c
Jeroen Geilman wrote:
> for (entry = list; entry; entry = entry->next) {
> Each map is a linked list of CIDR patterns, so consolidate as much as
> possible - 10 single IPs will cause noticable delays when the last
> entry matches!
Funny coincidence: just yesterday I added a Patricia (ra
Stan Hoeppner put forth on 11/4/2010 9:20 PM:
> Wietse Venema put forth on 11/4/2010 7:30 PM:
>> Stan Hoeppner:
>>> What's the CIDR lookup table performance difference between say 256 /32
>>> entries and a single /24 entry? Is it 256:1?
>>
>> One /32 match is a probably a little faster than one /
Wietse Venema put forth on 11/4/2010 7:30 PM:
> Stan Hoeppner:
>> What's the CIDR lookup table performance difference between say 256 /32
>> entries and a single /24 entry? Is it 256:1?
>
> One /32 match is a probably a little faster than one /24 match.
> The difference depends on compiler and h
Stan Hoeppner:
> What's the CIDR lookup table performance difference between say 256 /32
> entries and a single /24 entry? Is it 256:1?
One /32 match is a probably a little faster than one /24 match.
The difference depends on compiler and hardware used.
The CIDR implementation could be sped up
On 11/04/2010 11:55 PM, Stan Hoeppner wrote:
What's the CIDR lookup table performance difference between say 256 /32
entries and a single /24 entry? Is it 256:1? Or, how about 90,000 /32
entries vs 60,000 entries that consolidate many of those 90,000 /32s
into larger CIDRs such as /24s and /21s
Jack Knowlton(jknowl...@vp44.com)@Sun, Aug 15, 2010 at 11:53:33PM +0200:
> Hi all.
> Is it possible to store a CIDR access table on a mysql database? It would
> be very useful so I could have a centralized list to serve all MXs'
> instead of rsync'ing files each time.
> Thanks,
If you're comfortab
I completely misunderstood his request, sorry.
Jack Knowlton put forth on 8/15/2010 4:53 PM:
> Is it possible to store a CIDR access table on a mysql database?
I'm pretty sure the answer is, NO.
The solution to your problem is sticking the Postfix access table files you
want shared across your MX farm on an NFS/CIFS server and mounting the s
You may be able to use a mysql access map with a template like below:
user = dbuser
password = dbpasswd
dbname = dbname
query =
SELECT y
FROM access
WHERE x='%s'
Jay Deiman:
> Hello all,
>
> I was just reading the cidr_table(5) man page and I have a few questions.
>
> First I noticed that this is a "first match" scenario based on the
> ordering in the file. Is this file (in memory) then traversed in a
> linear order?
Just like regexps, Postfix stores
40 matches
Mail list logo
