Noel Jones put forth on 10/30/2009 11:50 PM:
> On 10/30/2009 9:05 PM, Stan Hoeppner wrote:
>> Robert Lopez put forth on 10/30/2009 6:57 PM:
>>
>>> It is not clear to me what the benefit of multiple files is beyond
>>> this association.
>>
>> Organization and ease of management for one.  For example:
>>
>> smtpd_client_restrictions =
>>          check_recipient_access hash:/etc/postfix/access
>>          check_client_access hash:/etc/postfix/access
>>          pcre:/etc/postfix/check_client_fqdn.pcre
>>          hash:/etc/postfix/coolsavings.access
>>          hash:/etc/postfix/richk-1.access
>>          cidr:/etc/postfix/cidr_files/china.cidr
>>          cidr:/etc/postfix/cidr_files/korea.cidr
>>          cidr:/etc/postfix/cidr_files/russia.cidr
>>          cidr:/etc/postfix/cidr_files/ukraine.cidr
>>          cidr:/etc/postfix/cidr_files/malaysia.cidr
>>          cidr:/etc/postfix/cidr_files/belarus.cidr
>>          cidr:/etc/postfix/cidr_files/indonesia.cidr
>>          cidr:/etc/postfix/cidr_files/hongkong.cidr
>>          cidr:/etc/postfix/cidr_files/africa.cidr
>>          cidr:/etc/postfix/cidr_files/romania.cidr
>>          cidr:/etc/postfix/cidr_files/thailand.cidr
>>          cidr:/etc/postfix/cidr_files/poland.cidr
>>          cidr:/etc/postfix/cidr_files/spammer.cidr
>>          cidr:/etc/postfix/cidr_files/hurricane-electric.cidr
>>          cidr:/etc/postfix/cidr_files/richk-1.cidr
>>          pcre:/etc/postfix/access.pcre
> 
> It's poor form to omit the check_client_access in front of each map name.

It may be poor form, but it's legal, gives the same result, and main.cf
doesn't look nearly as busy/cluttered by omitting it.  If/when it
becomes mandatory, I'll add it.  I hope it doesn't.

> All these cidr maps are a great example of separate tables that should
> be combined into a single table with a Makefile.

Interesting.  I may take a look into Makefile some time.  I was unaware
of it until today.  Just out of curiosity, how does putting it all in
one file make the resulting single file smaller than the sum of the
individual files' contents?  Does Makefile compress the contents in some
way, such as postmap indexes hash files?  I ask as the only overlapping
data in my CIDR files is the "REJECT" + "custom error" within each CIDR
file.

> Maintain the separate input files from different sources for easy
> management, then combine them into one table for postfix to use.

Again, why does a single large map file consume less memory than a bunch
of smaller map files, given there is no overlap but some of the custom
error message text?

>> My access file contains some whitelist email addresses, some whitelist
>> domains, some blacklist domains, and some whitelist and blacklist IP
>> addresses, so I do have some consolidation in the one file and I use it
>> in multiple restriction classes.However, it's by far my smallest table
>> file.  Some of my cidr files are pretty large.  Note that I'm using the
>> IPdeny (http://www.ipdeny.com) data and rejecting entire countries' smtp
>> connections.  Some of those files have thousands of entries.  Note also
>> that I'm using multiple table types, hash, cidr, and pcre.  It's better
>> to use multiple files in this kind of setup.
> 
> large cidr tables can use huge amounts of memory.  If you really feel
> you need these, 1) consolidate them into one table, and 2) use proxymap
> to open the table once per postfix instance rather than once per smtpd
> process.
> 
> If the data is available in multiple forms, hash: or cdb: tables scale
> much better than cidr, and a local DNSBL running rbldnsd scales even
> better.
> http://www.corpit.ru/mjt/rbldnsd.html

This is moot in a low volume environment serving around 1000 connections
a day, with no concurrency, is it not?  My smptd's currently use 8MB
VIRT and 4MB RES, and IIRC the max I've ever seen were two smtpd
processes running simultaneously.  Now, should I start hitting 25 to 50K
connections per day, then I should probably look at optimizing my map
files a bit, no?

Thanks for the hints Noel.  I may need them down the road, although not
at the moment.  Though I am curious and may play around with Makefile
just to learn something.

--
Stan


Reply via email to