[pfx] Re: IP/CIDR based exception in smtpd_sender_restrictions?

On 14/07/23 16:26, Aban Dokht via Postfix-users wrote: https://www.postfix.org/postconf.5.html#smtpd_sender_restrictions check_sender_access type:table ... Any hints how smtpd_sender_restrictions can be overridden with an IP based  hash or cidr table? /etc/postfix/sender_override.cidr

[pfx] IP/CIDR based exception in smtpd_sender_restrictions?

orkaround a add them to $mynetworks, to bypass the reject_plaintext_session restriction. But I do not want to allow relaying to the whitelisted addresses. Any hints how smtpd_sender_restrictions can be overridden with an IP based hash or cidr table? Regards

Re: is a cidr table red as a textfile by postfix?

your last lines: postmap without the cidr works fine to >> create a db file, and in the manfile I could find no directions here >> (there is a little line in man cidr, but I couldnt understand it >> enough to be helpful). > > Let's look at "man postmap": > > SY

Re: is a cidr table red as a textfile by postfix?

Dnia 26.02.2023 o godz. 21:01:42 HCImap pisze: > > As for your last lines: postmap without the cidr works fine to > create a db file, and in the manfile I could find no directions here > (there is a little line in man cidr, but I couldnt understand it > enough to be helpful). Let

Re: is a cidr table red as a textfile by postfix?

to use a cidr table to whitelist. But contrary to what I assumed it seems to read the ascii file, not the db file postmap makes. Can people perhaps confirm that is how it should be? Confirmed. Did you notice that the command postmap cidr:/etc/postfix/client_checks terminates with a fatal error

Re: is a cidr table red as a textfile by postfix?

HCImap: > hi, > > I am configuring a postfix-based mailserver at home, using the > docker-based mailserver > > https://github.com/docker-mailserver/docker-mailserver > > Under the hood the version is: > > # postconf mail_version > mail_version = 3.5.17 >

is a cidr table red as a textfile by postfix?

hi, I am configuring a postfix-based mailserver at home, using the docker-based mailserver https://github.com/docker-mailserver/docker-mailserver Under the hood the version is: # postconf mail_version mail_version = 3.5.17 I am trying to use a cidr table to whitelist. But contrary

Re: Use of CIDR with mynetworks tables

Scott Kitterman: > Last one on my postfix bug triage pile for today: > > A Debian user complained that using CIDR notation in hash tables for > mynetworks doesn't work. Of course it doesn't. I found discussions about > this going back a long time [1], which

Use of CIDR with mynetworks tables

Last one on my postfix bug triage pile for today: A Debian user complained that using CIDR notation in hash tables for mynetworks doesn't work. Of course it doesn't. I found discussions about this going back a long time [1], which suggests to me that the documentation might be improved

Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes

Demi Marie Obenour: > On 4/15/21 11:00 AM, Wietse Venema wrote: > > Demi Marie Obenour: > >> Would the following be a good idea? > > [a bunch of port-dependent behavior] > > > > That is all good and well, but this needs to be made configurable. > > > > I boldly assume this will use the

Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes

On 4/15/21 11:00 AM, Wietse Venema wrote: > Demi Marie Obenour: >> Would the following be a good idea? > [a bunch of port-dependent behavior] > > That is all good and well, but this needs to be made configurable. > > I boldly assume this will use the xxx_tls_wrapper_mode parameters, > instead of

Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes

On 15 Apr 2021, at 06:41, Demi Marie Obenour wrote: > Port 465 defaults to having TLS wrapper mode disabled Won't this prevent anyone from using smtps? The example config in postfix works, why not use it? -- I'm getting really sick of being the voice in the back of the room that everyone

Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes

Demi Marie Obenour: > Would the following be a good idea? [a bunch of port-dependent behavior] That is all good and well, but this needs to be made configurable. I boldly assume this will use the xxx_tls_wrapper_mode parameters, instead of replacing them with some totally different mechanism.

Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes

On 4/14/21 3:39 PM, Wietse Venema wrote: > Viktor Dukhovni: >> On Wed, Apr 14, 2021 at 02:24:23PM -0400, Wietse Venema wrote: >>> TL;DR: the idea is to change the smtpd_forbidden_commands default >>> setting to something like: >>> >>> CONNECT GET POST pcre:{/^\x16/ Possible TLS handshake} >>>

Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes

Viktor Dukhovni: > On Wed, Apr 14, 2021 at 02:24:23PM -0400, Wietse Venema wrote: > > TL;DR: the idea is to change the smtpd_forbidden_commands default > > setting to something like: > > > > CONNECT GET POST pcre:{/^\x16/ Possible TLS handshake} > > > > Which would match current TLS

Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes

On Wed, Apr 14, 2021 at 02:24:23PM -0400, Wietse Venema wrote: > TL;DR: the idea is to change the smtpd_forbidden_commands default > setting to something like: > > CONNECT GET POST pcre:{/^\x16/ Possible TLS handshake} > > Which would match current TLS protocols. I guess subject to "#ifdef

Re: idea: inlining pcre, cidr, etc and detecting TLS handshakes

TL;DR: the idea is to change the smtpd_forbidden_commands default setting to something like: CONNECT GET POST pcre:{/^\x16/ Possible TLS handshake} Which would match current TLS protocols. Wietse

idea: inlining pcre, cidr, etc and detecting TLS handshakes

file. Which is not good for a feature that is preferably enabled by default. I then realized that we could make Postfix map support a little smarter with only minor changes to internals. Suppose that in main.cf a table is specified as pcre:{{/pattern/ value}, ...} cidr:{{net/mask value

Re: smtpd_client_restriction map in CIDR? (Thanks & suggestion)

On 2/19/21 1:51 PM, Wietse Venema wrote: Postfix CIDR maps support CIDR. I don't understand how one would implement CIDR lookup keys in a hash: map. me either, thanks and to others who replied also It would be handy if postmap hash:foo printed a warning if it encountered CIDR or any other

Re: smtpd_client_restriction map in CIDR?

Gary Aitken: > I had the impression a map could contain client addresses in CIDR > notation, but apparently not. Is there a way to make restrictions > using CIDR notation? Postfix CIDR maps support CIDR. I don't understand how one would implement CIDR lookup keys in a hash: map.

Re: smtpd_client_restriction map in CIDR?

On 2021-02-19 21:01, Gary Aitken wrote: $ postmap -q 209.85.217.52 hash:ok_client $ postmap -q 209.85 hash:ok_client $ postmap -q 209.85.128.0 hash:ok_client $ postmap -q 209.85.128.0/17 hash:ok_client OK change hash to cidr, and try again

Re: smtpd_client_restriction map in CIDR?

Hi Gary, Is there a way to make restrictions using CIDR notation? Yes - just replace hash with cidr, like this: smtpd_client_restrictions = permit_mynetworks check_client_access cidr:/etc/postfix/ok_client reject More details: http://www.postfix.org/cidr_table.5.html Best regards

smtpd_client_restriction map in CIDR?

I had the impression a map could contain client addresses in CIDR notation, but apparently not. Is there a way to make restrictions using CIDR notation? Here's what I was trying to do: smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/ok_client reject

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

omedomain.tld' specified as a sender address*) > > to IPs belonging from some CIDR ranges: > > - if addresses from the ranges belong to 'somedomain.tld'? > > - if addresses from the ranges and 'somedomain.tld' A records don;t > > cover the same sets of hosts? >

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

> to IPs belonging from some CIDR ranges: > - if addresses from the ranges belong to 'somedomain.tld'? > - if addresses from the ranges and 'somedomain.tld' A records don;t > cover the same sets of hosts? A policy service can inspect the full combinatio of: - client IP ad

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

be accepted even if the user is not authenticated, and rejected without authentication for other CIDR blocks. add 192.168.0.0/16 to mynetworks you show bogus logs btw No! "Mail from 192.168.1/24 with sender's address 'sth1.tld' should be accepted even if the user is not authenti

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

, and rejected without authentication for other CIDR blocks. add 192.168.0.0/16 to mynetworks you show bogus logs btw No! "Mail from 192.168.1/24 with sender's address 'sth1.tld' should be accepted even if the user is not authenticated, and rejected without authentication for other

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

for other CIDR blocks. add 192.168.0.0/16 to mynetworks you show bogus logs btw No! "Mail from 192.168.1/24 with sender's address 'sth1.tld' should be accepted even if the user is not authenticated, and rejected without authentication for other CIDR blocks. " Mail from 192.168.1

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

:-) On 2/7/21 6:34 PM, Benny Pedersen wrote: On 2021-02-07 18:28, Marek Kozlowski wrote: Mail from 192.168.3/24 with sender's address 'sth3.tld' should be accepted even if the user is not authenticated, and rejected without authentication for other CIDR blocks. add 192.168.0.0/16

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

On 2021-02-07 18:28, Marek Kozlowski wrote: Mail from 192.168.3/24 with sender's address 'sth3.tld' should be accepted even if the user is not authenticated, and rejected without authentication for other CIDR blocks. add 192.168.0.0/16 to mynetworks you show bogus logs btw

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

On 2021-02-07 18:08, Curtis Maurand wrote: I would suggest giving higher preference to SPF. You can even reject if SPF fails. sure spf is the network policy, but i do not need network policy to reject local domains in port 25 world would be perfect if spf was used more even on postfix

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

, and rejected without authentication for other CIDR blocks. Mail from 192.168.2/24 with sender's address 'sth2.tld' should be accepted even if the user is not authenticated, and rejected without authentication for other CIDR blocks. Mail from 192.168.3/24 with sender's address 'sth3.tld' should

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

wondering if it possible to >> limit incoming mail with '...@somedomain.tld' specified as a sender >> address*) to IPs belonging from some CIDR ranges: > > sure > >> - if addresses from the ranges belong to 'somedomain.tld'? >> - if addresses from the ranges and 'some

Re: Mail from @somedomain.tld allowed only from some CIDR ranges?

CIDR ranges: sure - if addresses from the ranges belong to 'somedomain.tld'? - if addresses from the ranges and 'somedomain.tld' A records don;t cover the same sets of hosts? you should not accept local envelope sender on port 25, its not you :-) *) For both envelope and internal 'from:' would

Mail from @somedomain.tld allowed only from some CIDR ranges?

:-) Presumably it's my fault but I cannot find such an option. If so - thank you for directing me to it. I'm wondering if it possible to limit incoming mail with '...@somedomain.tld' specified as a sender address*) to IPs belonging from some CIDR ranges: - if addresses from the ranges belong

Re: Message got through CIDR table reject rule

On 10/28/2020 1:34 PM, Joey J wrote: To confirm, each table needs an entry like so: check_client_access  cidr:/etc/postfix/clientaccess check_client_access  cidr:/etc/postfix/sender_reject_ip Thank you Yes, each individual access table must be proceeded by a check_*_access statement

Re: Message got through CIDR table reject rule

To confirm, each table needs an entry like so: check_client_access cidr:/etc/postfix/clientaccess check_client_access cidr:/etc/postfix/sender_reject_ip Thank you On Wed, Oct 28, 2020 at 12:38 PM Noel Jones wrote: > On 10/28/2020 11:22 AM, Joey J wrote: > > > I have the foll

Re: Message got through CIDR table reject rule

/postfix/senderaccess check_client_access cidr:/etc/postfix/clientaccess hash:/etc/postfix/sender_reject cidr:/etc/postfix/sender_reject_ip sender_reject_ip has: 170.130.0.0/16 550 SPR-170.130.0.0 directives such as check_client_access take one single table name. You need to prefix each table

Message got through CIDR table reject rule

check_recipient_access regexp:/etc/postfix/rcptaccess check_sender_access regexp:/etc/postfix/senderaccess check_client_access cidr:/etc/postfix/clientaccess hash:/etc/postfix/sender_reject cidr:/etc/postfix/sender_reject_ip sender_reject_ip has: 170.130.0.0/16 550 SPR-170.130.0.0 Am I trying

Re: PATCH: check_helo_access and address literal vs cidr table

No, all I was saying was that address literals were not currently processed in the manner you expected. Wietse's patch implements the (inadvertently) missing feature. Oh, excellent! That's a easy-to-understand statement. Thank you. - James

Re: PATCH: check_helo_access and address literal vs cidr table

> On Feb 5, 2017, at 4:44 PM, James wrote: > > The original source of my confusion was assuming that all information > received with the HELO or EHLO command would be processed by the > smtpd_helo_restrictions. > > I understand now that that the text under >

Re: PATCH: check_helo_access and address literal vs cidr table

Thank you for the replies. The original source of my confusion was assuming that all information received with the HELO or EHLO command would be processed by the smtpd_helo_restrictions. I understand now that that the text under http://www.postfix.org/postconf.5.html#smtpd_helo_restrictions

PATCH: check_helo_access and address literal vs cidr table

gt; > command presents an address literal?" > > Support for cidr tables in check_helo_a_access applies only to domain names > not to address literals. > > So it works when the "domain name" is just a dotted IPv4 string, but not > when it is enclosed in [] as an address lite

Re: check_helo_access and address literal vs cidr table

> On Feb 5, 2017, at 1:25 PM, James <postfix_trac...@trackivity.com> wrote: > > I guess my basic question here is "does check_helo_access, or > check_helo_a_access, play nicely with cidr:table's when the helo/ehlo command > presents an address literal?

check_helo_access and address literal vs cidr table

ccess, or check_helo_a_access, play nicely with cidr:table's when the helo/ehlo command presents an address literal?" My cidr table includes: [127.0.0.0/8] REJECT [192.168.0.0/16] REJECT plus the other usual suspects. (Originally, I didn't have the square brackets so I added but that didn't seem t

Re: check_client_access cidr - Performance concerns ?

list...@tutanota.com: > 23. May 2016 18:48 by njo...@megan.vbhcs.org: > > > Yes, exactly right idea, but your expressions could use some improvement > > Thanks it helped! > > >IF /^(To|From|Cc|Reply-To): / Why not: /^(To|From|Cc|Reply-To): *(addr1|addr2|addr3)/ > Is the space between ":

Re: check_client_access cidr - Performance concerns ?

23. May 2016 18:48 by njo...@megan.vbhcs.org: > Yes, exactly right idea, but your expressions could use some improvement Thanks it helped! >IF /^(To|From|Cc|Reply-To): / Is the space between ": /" always needed? I think yes.  

Re: check_client_access cidr - Performance concerns ?

On 5/23/2016 5:55 PM, list...@tutanota.com wrote: > I noticed this email today about IF ... ENDIF. > > I didnt know about it yet so I have been reading and looking at > examples. > > I can understand some but not all yet. The examples with matching > on just an IP or

Re: check_client_access cidr - Performance concerns ?

I noticed this email today about IF ... ENDIF. I didnt know about it yet so I have been reading and looking at examples. I can understand some but not all yet.  The examples with matching on just an IP or CIDR are easy to see. But can IF ... ENDIF in Postfix be used to make this .pcre

Re: check_client_access cidr - Performance concerns ?

Viktor Dukhovni: > On Fri, May 20, 2016 at 03:24:26PM -0400, Wietse Venema wrote: > > > I can do a little better than thats, and also give a number for the > > per-query overhead. With this i5-650 CPU @3.2GHZ, it takes 0.92 > > seconds to parse 1 million IPv4 patterns, and less than about 0.01 >

Re: check_client_access cidr - Performance concerns ?

On Fri, May 20, 2016 at 03:24:26PM -0400, Wietse Venema wrote: > I can do a little better than thats, and also give a number for the > per-query overhead. With this i5-650 CPU @3.2GHZ, it takes 0.92 > seconds to parse 1 million IPv4 patterns, and less than about 0.01 > second to search through

Re: check_client_access cidr - Performance concerns ?

Wietse Venema: > To measure [cidr map] initialization overhead, look at the difference between > > $ time postmap -q /dev/null static:foo > $ time postmap -q /dev/null pcre:yourfile > > You will probably have to run this several times to get a meaningful > resul

Re: check_client_access cidr - Performance concerns ?

> On May 20, 2016, at 1:42 PM, Noel Jones <njo...@megan.vbhcs.org> wrote: > > The cidr: map is quite efficient. > > IIRC the last time someone performance tested the cidr: map type, > performance stayed high even with 10's of thousands of entries. (or > was it 10

Re: check_client_access cidr - Performance concerns ?

t; should worry. I've pruned the oldest entries from here in the > past (assuming plenty of time to get them added to an RBL) - but > if there's no foreseeable performance impact - I'd like to not > worry about keeping it pruned. Postfix CIDR maps have two sources of overhead. 1) The o

Re: check_client_access cidr - Performance concerns ?

On 5/20/2016 11:20 AM, Brandon Applegate wrote: > Hello all, > > In my cascade of smtpd restrictions, along with RBL, rDNS etc - I have: > > check_client_access cidr:/etc/postfix/cidr_client_checks > > I mainly (manually) throw egregious offenders in there that haven’t

check_client_access cidr - Performance concerns ?

Hello all, In my cascade of smtpd restrictions, along with RBL, rDNS etc - I have: check_client_access cidr:/etc/postfix/cidr_client_checks I mainly (manually) throw egregious offenders in there that haven’t been added to one of the RBLs yet. In any case - I’ve been wondering about

Re: postscreen CIDR access blocks compared to in-firewall?

On 4/8/2016 12:04 PM, jaso...@mail-central.com wrote: > > For me then, simplest seems that "known bad" can stay in fail2ban-ready > firewall IPSETs, and "need to investigate a bit more" in postscreen's CIDR > accces list. > Note that updating the post

Re: postscreen CIDR access blocks compared to in-firewall?

; use the locking protocol described in lmdb_table(5). Otherwise the > > > result will be incorrect. > > Does that^ imply that I can replace the cidr_table for postscreen_access with > an lmdb_table? No. You would use CIDR for address ranges, LMDB for individual IP addresses. Wietse

Re: postscreen CIDR access blocks compared to in-firewall?

SMTP client IP addresses. Typically one would specify something that whitelists local networks, followed by a CIDR table for selective white- and blacklisting. mentions only CIDR table. Is cidr: or lmdb: recommended? If lmdb:, is it a simple swap of DB type, with same content, e.g. cat /etc/p

Re: postscreen CIDR access blocks compared to in-firewall?

ct. I hadn't realized the need for locking. For me then, simplest seems that "known bad" can stay in fail2ban-ready firewall IPSETs, and "need to investigate a bit more" in postscreen's CIDR accces list. Thanks. Jason

Re: postscreen CIDR access blocks compared to in-firewall?

jaso...@mail-central.com: > To date I've maintained & deployed a firewall blacklist of bad-actor, port25 > CIDRs. > > Its blocking is obviously in front of Postfix, and logs if/as I choose to my > firewall logs. > > I populate it both manually, and append it using fail2ban. > > Its a 'fast'

Re: cidr:/ lookup using network map [e.g. mysql]

. i don't believe postfix can currently do this, aside from a traditional access(5) lookup which is limited to octet boundaries. am i wrong? if not, could this be considered as a possible feature? could this potentially be done with pipemap? Postfix can't do it, but if you google for mysql cidr

cidr:/ lookup using network map [e.g. mysql]

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 network instead

Re: cidr:/ lookup using network map [e.g. mysql]

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 network

Re: cidr:/ lookup using network map [e.g. mysql]

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 this data

Re: cidr:/ lookup using network map [e.g. mysql]

currently do this, aside from a traditional access(5) lookup which is limited to octet boundaries. am i wrong? if not, could this be considered as a possible feature? could this potentially be done with pipemap? Postfix can't do it, but if you google for mysql cidr you will come across various

Re: cidr:/ lookup using network map [e.g. mysql]

type of query than is currently used for sql maps. We store the my networks value to be used by Postfix, Amavis, and SpamAssassin in LDAP just fine. It's a single valued attribute with CIDR notation. For example: zimbraMtaMyNetworks: 127.0.0.0/8 10.0.0.0/8 [::1]/128 [fe80::]/64 The above

Re: cidr:/ lookup using network map [e.g. mysql]

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

Re: CIDR Whitelist ?

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

Re: CIDR Whitelist ?

listed on Spamcop.) So anyway, I just now added the following to my pre-existing list of smtpd_recipient_restrictions: check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist where my cidr-whitelist file currently contains just: # Microsoft 65.52.0.0/14 OK

Re: CIDR Whitelist ?

to my pre-existing list of smtpd_recipient_restrictions: check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist where my cidr-whitelist file currently contains just: # Microsoft 65.52.0.0/14 OK Of course, I placed this new check_client_access clause above

Re: CIDR Whitelist ?

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 over

Re: CIDR Whitelist ?

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. Having

Re: CIDR Whitelist ?

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 default so

CIDR Whitelist ?

of smtpd_recipient_restrictions: check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist where my cidr-whitelist file currently contains just: # Microsoft 65.52.0.0/14 OK Of course, I placed this new check_client_access clause above all of the other/pre-existing clauses in my

Re: CIDR Whitelist ?

now added the following to my pre-existing list of smtpd_recipient_restrictions: check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist where my cidr-whitelist file currently contains just: # Microsoft 65.52.0.0/14 OK Of course, I placed this new

cidr maps

In a cidr map in postfix, I thought that both 10.0.0.8/8 and 10.0.0.0/255.0.0.0 were valid syntaxes however, 220.73.0.0/255.255.0.0 reject in postscreen_access.cidr posts an error, so obviously that syntax is wrong. Do I have to transform that to a /16 or is there a IP and Netmask

Re: cidr maps

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

Re: postfix need reload after cidr changes?

Marko Weber | ZBF skrev den 2013-05-23 21:05: when i change a cidr map, do i have to reload postfix like on chnages by texthash? yes, would be nice to have man pages updated to contain reload needs, eg sql maps does in terms of reload not need to be running postfix reload, nearly all other

Re: postfix need reload after cidr changes?

On Thu, May 23, 2013 at 09:12:23PM +0200, Benny Pedersen wrote: Marko Weber | ZBF skrev den 2013-05-23 21:05: when i change a cidr map, do i have to reload postfix like on chnages by texthash? If you're willing to wait until the process in question exits, no, reload is not necessary. If you

Re: postfix need reload after cidr changes?

Marko Weber | ZBF: when i change a cidr map, do i have to reload postfix like on chnages by texthash? i was on http://www.postfix.org/cidr_table.5.html and cant find that info. It is safe to assume that if you change a file, then a reload will be needed. cidr is like texthash, pcre

Re: postfix need reload after cidr changes?

hey wietse, Am 2013-05-23 21:33, schrieb wie...@porcupine.org: Marko Weber | ZBF: when i change a cidr map, do i have to reload postfix like on chnages by texthash? i was on http://www.postfix.org/cidr_table.5.html and cant find that info. It is safe to assume that if you change a file

Re: postfix need reload after cidr changes?

Marko Weber | ZBF skrev den 2013-05-23 21:47: postscreen_access_list = cidr:/etc/postfix/lookups/cidr/postscreen_access.cidr cidr:/etc/postfix/lookups/cidr/spamhausdrop.cidr how much blocked trafic do you get from it ? -- senders that put my email into body content will deliver it to my own

Re: postfix need reload after cidr changes?

On 5/23/2013 2:47 PM, Marko Weber | ZBF wrote: background: i use the LASSO DROP from spamhaus. this list you can update hourly and i read it with the cidr option. Spamhaus DROP - [D]on't [R]oute [O]n [P]eer list http://www.spamhaus.org/drop/ When implemented at a network or ISP's 'core

Re: using cidr notation in client_access

to store IP networks (w/ CIDR postfix) in PostgreSQL; this is somewhat given. PostgreSQL handles CIDR with some special functions and operators. See http://www.postgresql.org/docs/9.2/interactive/functions-net.html The type in PostgreSQL is irrelevant. Ignore it. That is not part

using cidr notation in client_access

Hi! I have the following parameter in main.cf (Postfix 2.9): proxy_read_maps = proxy:pgsql:/etc/postfix/client_access-sql.cf, [...] smtpd_client_restrictions = check_client_access proxy:pgsql:/etc/postfix/client_access-sql.cf, [...] ... which works for unique IP lookups, but I wish to use CIDR

Re: using cidr notation in client_access

LEVAI Daniel skrev den 2013-01-12 09:51: ... which works for unique IP lookups, but I wish to use CIDR postfixes. Is it possible to combine the cidr:filename lookups with proxy:pgsql? http://pastebin.com/RMKBmW0p postgresql support cidr, so its just create it :=) untested since i have

Re: using cidr notation in client_access

On szo, jan 12, 2013 at 13:17:45 +0100, Benny Pedersen wrote: LEVAI Daniel skrev den 2013-01-12 09:51: ... which works for unique IP lookups, but I wish to use CIDR postfixes. Is it possible to combine the cidr:filename lookups with proxy:pgsql? http://pastebin.com/RMKBmW0p postgresql

Re: using cidr notation in client_access

LEVAI Daniel skrev den 2013-01-12 13:51: How should I put this... My question is not in regards to how to store IP networks (w/ CIDR postfix) in PostgreSQL; this is somewhat given. telnet 127.0.0.0/16 25 works ? postfix only query single ip, not ip ranges

Re: using cidr notation in client_access

On Sat, Jan 12, 2013 at 01:51:26PM +0100, LEVAI Daniel wrote: How should I put this... My question is not in regards to how to store IP networks (w/ CIDR postfix) in PostgreSQL; this is somewhat given. PostgreSQL handles CIDR with some special functions and operators. See http

Re: using cidr notation in client_access

On szo, jan 12, 2013 at 14:00:08 +0100, Benny Pedersen wrote: LEVAI Daniel skrev den 2013-01-12 13:51: How should I put this... My question is not in regards to how to store IP networks (w/ CIDR postfix) in PostgreSQL; this is somewhat given. telnet 127.0.0.0/16 25 works ? postfix

Re: using cidr notation in client_access

On szo, jan 12, 2013 at 14:11:12 +0100, Bastian Blank wrote: On Sat, Jan 12, 2013 at 01:51:26PM +0100, LEVAI Daniel wrote: How should I put this... My question is not in regards to how to store IP networks (w/ CIDR postfix) in PostgreSQL; this is somewhat given. PostgreSQL handles CIDR

Re: using cidr notation in client_access

On 12-01-13 17:39, LEVAI Daniel wrote: On szo, jan 12, 2013 at 14:11:12 +0100, Bastian Blank wrote: On Sat, Jan 12, 2013 at 01:51:26PM +0100, LEVAI Daniel wrote: How should I put this... My question is not in regards to how to store IP networks (w/ CIDR postfix) in PostgreSQL; this is somewhat

Re: using cidr notation in client_access

LEVAI Daniel skrev den 2013-01-12 17:34: Sorry but I think you're totally confused about the question. then explain proxy: more in detail for what you want, maybe with a log snippet of what does not work

Re: Verify CIDR format

On Mon, Nov 12, 2012 at 04:16:40PM -0500, Jack S wrote: I just wanted to verify the format for the CIDR file is correct: To whitelist: 94.68.240.213 OK 94.68.240.214 OK To blacklist: 94.242.222.0/20 REJECT CIDR-BLOCK SPAMMERS-94.242.222.0/20 109.95.120.0/21

Re: Verify CIDR format

On 11/12/12 5:15 PM, Viktor Dukhovni wrote: On Mon, Nov 12, 2012 at 04:16:40PM -0500, Jack S wrote: I just wanted to verify the format for the CIDR file is correct: To whitelist: 94.68.240.213 OK 94.68.240.214 OK To blacklist: 94.242.222.0/20 REJECT CIDR-BLOCK

CIDR table from LDAP lookup

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: type map. Is there any solution other than dump the LDAP query to a file or

Re: CIDR table from LDAP lookup

. Is there any solution other than dump the LDAP query to a file or store every individual host on LDAP? The CIDR matching would have to be done by the LDAP server. If your LDAP server has a CIDR block attribute type and supports a suitable matching rule, you can do CIDR lookups in LDAP. Otherwise

cidr map for a certain receiver address only?

Hello list 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_restrictions I affect all addresses on my server

Re: cidr map for a certain receiver address only?

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

  1   2   3   >