On Fri, Oct 30, 2009 at 1:26 PM, Noel Jones <njo...@megan.vbhcs.org> wrote: > On 10/30/2009 12:55 PM, Robert Lopez wrote: >> >> I would like to confirm my understanding about access files. >> >> Please let me know if any of this is not correct... >> >> The man (5) access description describes a prototype file, where that >> file could be a single file describing any host names, network >> addresses, envelope senders or recipient addresses. >> >> The file could also be a set of files all following the same format >> rules. >> >> Where such files might be >> recipient_checks, helo_checks, sender_checks, client_checks, etc. >> >> >> The usefulness of the content of an access file is dependent upon the >> parameter that selects a routine that reads the file. >> >> If check_client_access causes a read of the file it will only be >> looking for IP addresses of a client server that sent the email or a >> fully qualified domain name that successfully reverse maps to the IP >> address of a client server that sent the email. >> >> If check_sender_access causes a read of the file it will only be >> looking for an email SMTP "MAIL FROM" address or a pattern which could >> be a part that email address to the left of the "@" sign. >> >> If check_helo_access causes a read of the file it will only be looking >> for the HELO or EHLO hostname or any valid parent domain of that >> hostname that is in the SMTP HELO. >> >> The routines executed vi the parameters such as check_client_access, >> check_sender_access, check_helo_access, etc. return the value the >> check to the routine that called for the check where the calling >> routine would be instigated by any of these parameters: >> >> smtpd_client_restrictions >> smtpd_helo_restrictions >> smtpd_sender_restrictions >> smtpd_recipient_restrictions >> smtpd_data_restrictions >> >> It is possible to have all the lookups done on a single >> .../postfix/access.db file but that could mean the file gets confusing >> so in practice multiple access files with names like client_access, >> helo_access, sender_access, etc. > > so far so good... > > >> >> A single parameter such as check_client_access may be called multiple >> times in a situation like this: >> >> smtpd_sender_restrictions = >> check_sender_access hash:/etc/postfix/greylist >> check_sender_access hash:/etc/postfix/sender_access >> permit_mynetworks >> >> >> However if the above causes a pattern to be found more than once then >> only the last pattern match is used. (I think that is what "When the >> same parameter is defined multiple times, only the last instance is >> remembered." means.) > > No, the "last parameter is used" rule refers to when indexing a single map > -- when the map is indexed with postmap, a duplicate key will overwrite the > previous identical key. > > With multiple maps -- or multiple restrictions of any type -- in > smtpd_*_restrictions, the first match wins.
Ah! Good. That now makes more sense. > > Postfix places no limit on how many maps you can use, but there is system > overhead with each map. Rule of thumb is to combine maps wherever possible > -- don't use two check_sender_access statements if you can do it with one. > The smart way to do this is use a Makefile to build a single map from > multiple similar input files. That is interesting. What is the advantage of that over directly editing a single file? I can see having unique names that pair with the parameters that cause them to be read. It is not clear to me what the benefit of multiple files is beyond this association. We do something similar with the virtualaliases table. There is a table that has all college employees who use an Exchange server, another that has all customers (students) who use Sungard Luminis, and a third that has Mailman lists. So email is delivered to one of those three systems based on that file. We build that single file from three separate files. > >> >> This is how I am putting this in practice on a new virtual server >> where I hope to fix some problems on current production servers: >> >> r...@mg0x:/etc/postfix# postconf -d mail_version >> mail_version = 2.5.5 >> >> I am using 2.5.5 because that is the latest from Ubuntu. >> >> >> r...@mg0x:/etc/postfix# postconf -n >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> append_dot_mydomain = yes >> biff = no >> bounce_size_limit = 1 >> config_directory = /etc/postfix >> default_process_limit = 400 >> header_checks = regexp:/etc/postfix/header_checks >> inet_interfaces = all >> mailbox_size_limit = 0 >> masquerade_domains = $mydomain, cnm.edu, nmvc.org, nmvirtualcollege.org >> max_use = 100 >> message_size_limit = 16777216 >> mydestination = $myhostname, $mydomain, localhost.localdomain, >> cnm.edu, mail.cnm.edu, mg0x.cnm.edu, mg04.cnm.edu, mg05.cnm.edu, >> nmvc.org, mail.nmvc.org, mg0x.nmvc.org, mg04.nmvc.org, mg05.nmvc.org, >> mg06.nmvc, nmvirtualcollege.org, mail.nmvirtualcollege.org, >> mg0x.nmvirtualcollege.org, mg04.nmvirtualcollege.org, >> mg05.nmvirtualcollege.org, mg04.nmvirtualcollege.org, nmln.net, >> ideal-nm.org, ideal-nm.net, idealnm.org, idealnm.net > > Lots of domains in mydestination... Are you sure these don't belong in > relay_domains instead? > http://www.postfix.org/BASIC_CONFIGURATION_README.html > http://www.postfix.org/STANDARD_CONFIGURATION_README.html > http://www.postfix.org/ADDRESS_CLASS_README.html No, I am not sure. All email going students and employees are sent to either Sungard Luminis servers or to Microsoft Exchange servers. There are Mailman lists that have membership beyond this college. Members of some lists include state employees, other college and university employees, state high school employees, etc. So, for example steering-bo...@ideal-nm.org is a list and any mail sent to it is then sent to persons at many different other organizations. The nmvirtualcollege is moving toward a single service for students of many different colleges who take on-line courses from a number of different colleges via a single web access point. Does that mean they belong in relay_domains? > >> myhostname = mg0x.cnm.edu >> mynetworks = 198.133.182.0/24, 198.133.181.0/24, 198.133.180.0/24, >> 172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8, 127.0.0.0/8 >> [::ffff:127.0.0.0]/104 [::1]/128 >> myorigin = /etc/mailname >> notify_classes = resource, software >> readme_directory = no >> recipient_delimiter = + >> relay_domains = $mydestination > > relay_domains should be set explicitly, and generally should not include > $mydestination. If there are no relay_domains, it should be set empty. > http://www.postfix.org/ADDRESS_CLASS_README.html This may be another point where I am confused. I am thinking relay is when a postfix server accepts email for u...@cnm.edu and then rewrites that address to what is found in a table for the user where the email is then sent to u...@other.domain. I may have to read that a few times to get it all straight. > >> relayhost = >> smtp_host_lookup = dns, native >> smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache >> smtpd_banner = cnm.edu > > Should be "cnm.edu ESTMP", or better, just leave it at the default. Is that "cnm.edu ESMTP" or default? > >> smtpd_client_restrictions = permit_mynetworks check_client_access >> hash:/etc/postfix/access reject_rbl_client >> zen.spamhaus.org reject_rbl_client bl.spamcop.net >> reject_rbl_client >> dnsbl.njabl.org permit > > OK. The final "permit" is a no-op and can be removed, but it doesn't hurt > anything. > >> smtpd_helo_required = yes >> smtpd_helo_restrictions = permit_mynetworks reject_invalid_hostname >> smtpd_recipient_restrictions = check_recipient_access >> hash:/etc/postfix/overquota reject_non_fqdn_sender >> reject_unknown_sender_domain reject_non_fqdn_recipient >> reject_unknown_recipient_domain reject_unlisted_recipient >> permit_mynetworks reject_unauth_destination >> reject_unauth_pipeliningreject_invalid_helo_hostname >> reject_non_fqdn_helo_hostname reject_rbl_client zen.spamhaus.org > > Caution! lookup tables before reject_unauth_destination can make you an > open relay if something inintended gets put there. If you want to reject > overquota recipients before permit_mynetworks, do it in > smtpd_sender_restrictions. > (Yes, you can use check_*_access in smtpd_**_restrictions, with the default > "smtpd_delay_reject = yes".) OK > >> smtpd_sender_restrictions = check_sender_access >> hash:/etc/postfix/greylist check_sender_access >> hash:/etc/postfix/sender_access permit_mynetworks >> reject_unknown_sender_domain > > Seems like permit_mynetworks should come before greylist or other sender > access checks. Seems like? :-) This greylist program reads the tail of the mail log and looks for bursts of email in a short period of time. The program adds the bursting account to the map which causes the email to be deferred. > >> smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem >> smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key >> smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache >> smtpd_use_tls = yes >> virtual_alias_maps = hash:/etc/postfix/virtualaliases > > -- Noel Jones > Thanks for the education assistance. -- Robert Lopez Unix Systems Administrator Central New Mexico Community College (CNM) 525 Buena Vista SE Albuquerque, New Mexico 87106
