Re: Delivery to command in aliases ignored ?
Hi, Viktor, Thank you very much for your answer. I did run the command, as you suggested, but the result may be seen ... # postmap -q test hash:/var/lib/mailman/data/aliases |/usr/lib/mailman/mail/mailman post test this is exactly what i would like to have ... the delivery of mail intended for the test to the command, as indicated by the above line. However, i've just checked once more, the same error is there if I send mail for the t...@jesej.si mailing list. Kajetan 2013/3/27 Viktor Dukhovni postfix-us...@dukhovni.org On Wed, Mar 27, 2013 at 12:26:36AM +0100, Kajetan Dolinar wrote: Greetings to everyone, I have a working Postfix + Cyrus system tested (has got some history of usage) but I want to add the Mailman system to it. However, it seems that I cannot get mail through to the Mailman system past the Mailman's aliases, i.e. the delivery to commands which Mailman uses to process the requests seems to never happen. I keep on getting the following error, no matter what I do: postfix/local[17255]: 554A7300A53: to=t...@jesej.si, relay=local, ... status=bounced (unknown user: test) t...@jesej.si is the address of the mailing list. The essential configuration parameters are as follows: alias_maps = hash:/var/lib/mailman/data/aliases The command: $ postmap -q test hash:/var/lib/mailman/data/aliases will likely produce no results. Add a test alias to the table if you mail for test to be delivered to some specific alias. Cleary there is no such user. local_recipient_maps = $alias_maps unknown_local_recipient_reject_code = 550 transport_maps = hash:/etc/postfix/transport This part is working, the message was delivered via local(8). * local -- Viktor.
Re: dictionary-attack
On Tue, Mar 26, 2013 at 4:16 PM, Wietse Venema wie...@porcupine.org wrote: Lima Union: [ Charset ISO-8859-1 unsupported, converting... ] Am 26.03.2013 19:36, schrieb Lima Union: Wietse, ok, I'll disable the fqrdns check for now and check the chroot configuration after I return from holidays this is ONE char in the master.cf and if i where you i would not make holidays as long a production server is known misconfigured ok, done, chroot has been disabled and the fqrdns.pcre is working now. After disabling the chroot I issued an 'egrep '(warning|error|fatal|panic):' /var/log/mail' and am seeing many warnings like these, is it ok? Mar 26 15:56:03 relay1 postfix/smtpd[2111]: warning: 178.88.224.150: hostname 178.88.224.150.megaline.telecom.kz verification failed: Name or service not known Mar 26 15:56:03 relay1 postfix/smtpd[1953]: warning: 201.216.208.5: hostname customer-static-201-216-208.5.iplannetworks.net verification failed: Name or service not known Mar 26 15:56:18 relay1 postfix/smtpd[1951]: warning: 63.141.239.151: hostname muv4ward.com verification failed: Name or service not known Mar 26 15:56:31 relay1 postfix/smtpd[1951]: warning: 87.98.228.174: address not listed for hostname www.thedesigninstitution.com Mar 26 15:56:34 relay1 postfix/smtpd[2021]: warning: 64.191.105.74: hostname 64-191-105-74.static.hostnoc.net verification failed: Name or service not known Yes, broken DNS happens. Instead of reject_unknown_client_hostname you could use reject_unknown_reverse_client_hostname which will use the name even if the above checks fail. http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname Also, your chroot jail is missing files. Please complain to the distributor. Wietse Wietse, there's something I don't understand. I've commented out the check_reverse_client_hostname_access, reloaded postfix and am still finding those DNS warnings (ie: hostname 77-121-229-206.dhcp.kram-city.net verification failed: Name or service not known). How to know which setting is triggering that? and is it just a warning, not a reject right? in my main.cf there's no reject_unknown_client_hostname as your suggestion. Here's a copy of my current smtpd_recipient_restrictions settings: smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, # warn_if_reject reject_unknown_helo_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, # reject_unknown_sender_domain, # reject_unknown_recipient_domain, reject_unverified_recipient, check_client_access hash:$config_directory/maps/smtpd_client_checks, # check_reverse_client_hostname_access regexp:$config_directory/maps/fqrdns.pcre, check_helo_access hash:$config_directory/maps/smtpd_helo_checks, check_sender_access hash:$config_directory/maps/smtpd_sender_checks, check_sender_access regexp:$config_directory/maps/smtpd_sender_checks.regexp, check_recipient_access hash:$config_directory/maps/smtpd_recipient_checks, reject_non_fqdn_hostname, #reject_unverified_recipient, reject_rbl_client zen.spamhaus.org, reject_rbl_client b.barracudacentral.org, reject_rbl_client psbl.surriel.com, reject_rbl_client bl.spamcop.net, reject_rhsbl_client rhsbl.sorbs.net, check_sender_access hash:$config_directory/maps/forged_domain_senders, check_policy_service inet:127.0.0.1:10023, permit Thanks once again. LU
Fw: Distributed Postfix
Thanks I have refered to split only postfix functions,but for it ,is need create coherent users system. For example if I create one user in gmail system,this user physical is stored only one central machine then is accesed through diverse distribute mechanism (same DNS),or is replicate in all machine? - Original Message - From: Bill Cole To: postfix-users@postfix.org Sent: Tuesday, March 26, 2013 16:00 Subject: Re: Distributed Postfix On 26 Mar 2013, at 6:51, Gaby L wrote: Hi My teoretic question is how configure multiple (distributed) postfix mail servers for one domain,which can load balance tasks? (e.g gmail),but all servers same (unique) users list,alias,rules for one domain? As Dr. Venema's answer implies, splitting up functions (especially non-Postfix functions) between different sets of machines is the first step, as it is easier to distribute limited subsets of work across many machines than to replicate everything on every box and keep them all coherent. A corollary of this is that you need to start by understanding what your Postfix mail server actually is doing. Inbound, outbound, and internal mail can be split apart between distinct Postfix configurations, while access to delivered mail (i.e. IMAP, POP, or webmail) is a non-Postfix function that is inherently the most difficult part of a mail server to distribute across many nodes. Because large-scale mail servers aren't all large in the same way, how one should split up and replicate functionality between machines is dependent on the details of what the whole system is doing.
Re: dictionary-attack
Lima Union: Mar 26 15:56:34 relay1 postfix/smtpd[2021]: warning: 64.191.105.74: hostname 64-191-105-74.static.hostnoc.net verification failed: Name or service not known Yes, broken DNS happens. Instead of reject_unknown_client_hostname you could use reject_unknown_reverse_client_hostname which will use the name even if the above checks fail. http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname Also, your chroot jail is missing files. Please complain to the distributor. Wietse Wietse, there's something I don't understand. I've commented out the The error messages will not go away. The error is in someone elses DNS server. Postfix will not use such hostnames with reject_unknown_client_hostname. Therefore it is not useful blocking home computers by their name. Postfix will use such hostnames with reject_unknown_reverse_client_hostname. Use this for blocking home computers by their name. In addition, your chroot jail is missing files, and that was breaking your DNS lookups. That bug is caused by the distrutor, so please complain there. Wietse
Re: check_recipient_access, regexp and case sensitivity
Wietse Venema wietse at porcupine.org writes: Viktor Dukhovni: src/smtpd/smtpd_resolve.c: lowercase(STR(reply-recipient)); /* XXX */ This may have escaped the code cleanup when forced lowercase was removed from access maps. Wietse Thanks for your answer, Wietse. Should we then expect a bugfix in one of the next 2.10.x releases (and in the other maintained branches)? As far as I understand, this is not an intended behaviour (since Postfix 2.3), right? Thanks, Fabio
Re: check_recipient_access, regexp and case sensitivity
Viktor Dukhovni: src/smtpd/smtpd_resolve.c: lowercase(STR(reply-recipient)); /* XXX */ Wietse Venema: This may have escaped the code cleanup when forced lowercase was removed from access maps. Fabio Sangiovanni: Thanks for your answer, Wietse. Should we then expect a bugfix in one of the next 2.10.x releases (and in the other maintained branches)? As far as I understand, this is not an intended behaviour (since Postfix 2.3), right? I do not expect that removing the lowercase() call will break other code. It sits in code that maintains a cache of resolved recipient addresses. However, this needs to be verified before anything can be changed in a stable release. Considering that this has not been a problem in the last 7 years, this is not a high-priority item. Generally, it is unwise to have access policy that depends on the recipient address case. First, the case is under control by the adversary. Second, the policy is prone to accidental matches and non-matches. Wietse
Re: dictionary-attack
On 3/27/2013 7:30 AM, Lima Union wrote: Wietse, there's something I don't understand. I've commented out the check_reverse_client_hostname_access, Re-enable it. reloaded postfix and am still finding those DNS warnings (ie: hostname 77-121-229-206.dhcp.kram-city.net verification failed: Name or service not known). These warnings are not related to the fqrdns table. As Wietse explained they are DNS server errors. I get many dozens of these warnings per day, every day. So does everyone else. -- Stan
Re: dictionary-attack
On 3/26/2013 1:29 PM, Lima Union wrote: No ipv6 here and pdnsd is using 8.8.8.8 as DNS server. Instead of using a caching DNS proxy daemon querying Google's public DNS servers, I recommend you run a recursing caching resolver on your Postfix host, such as PowerDNS recursor (I've been using it for years without any issues). There are a few reasons for this: 1. Spamhaus refuses dnsbls queries from Google DNS servers, and most public DNS servers, because of volume. Thus you can't query the Zen list using this proxy setup. Other dnsbl operators may block Google DNS as well. 2. Latency is greatly reduced as your DNS queries are direct instead of proxied. On a high volume server latency is critical as it limits message throughput. 3. If you have DNS related problems at some point in the future, you have complete control and troubleshooting ability. If using Google or another DNS server via proxy you're at that operator's mercy. And there is always the possibility that Google may modify results in some way, or respond inaccurately due to some policy or other reason. It's best to run your own resolver and do direct queries. -- Stan
Re: dictionary-attack
Hello, I ran into a bit of an issue trying out fqrdns.pcre as recommended here in this thread. The header in the file recommended adding it into smtpd_client_restrictions. However if I place it there, I end up rejecting mail even from SASL authenticated client devices, if they also match a rule in fqrdns.pcre. Is it acceptable to put it into smtpd_relay_restrictions instead? I am worried if I do this, it would not be able to prevent these bad hosts from sending mail directly to my domain (non-relay), which kind of defeats the purpose of using it for botnet protection. I have some dynamic clients, and I don't know what subnet they'll be on since they're mobile devices with an IP from the mobile provider, so whitelisting isn't going to work very well if they roam somewhere surprising, like a different unexpected provider. Thanks, Matthew.
AW: dictionary-attack
Im Auftrag von Matthew Hall Hello, I ran into a bit of an issue trying out fqrdns.pcre as recommended here in this thread. The header in the file recommended adding it into smtpd_client_restrictions. However if I place it there, I end up rejecting mail even from SASL authenticated client devices, if they also match a rule in fqrdns.pcre. Put all your restriction in smtpd_recipient_restrictions Do fqrdns.pcre after permit_sasl_authenticated and your Users can send No restriction in all the other smtpd_*_restrictions Only in smtpd_data_restrictions = reject_multi_recipient_bounce, reject_unauth_pipelining Is it acceptable to put it into smtpd_relay_restrictions instead? I am worried if I do this, it would not be able to prevent these bad hosts from sending mail directly to my domain (non-relay), which kind of defeats the purpose of using it for botnet protection. I have some dynamic clients, and I don't know what subnet they'll be on since they're mobile devices with an IP from the mobile provider, so whitelisting isn't going to work very well if they roam somewhere surprising, like a different unexpected provider. Thanks, Matthew. Mit freundlichen Grüßen Uwe Drießen -- Software Computer Uwe Drießen Lembergstraße 33 67824 Feilbingert Tel.: 06708660045
Re: dictionary-attack
On 3/27/2013 5:11 PM, Matthew Hall wrote: Hello, I ran into a bit of an issue trying out fqrdns.pcre as recommended here in this thread. The header in the file recommended adding it into smtpd_client_restrictions. However if I place it there, I end up rejecting mail even from SASL authenticated client devices, if they also match a rule in fqrdns.pcre. The blurb in the file you refer to says: # smtpd_client_restrictions # ... # check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre # ... The ... means something belongs there, and it's up to you to figure it out. A typical implementation that would exempt local networks and authenticated clients would look something like: # main.cf smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_reverse_client_hostname_access pcre:/etc/postfixfqrdns.pcre While the example I show is very common, there are other valid settings. One could argue the example included in the file should be clearer (and it's missing the required '='). Is it acceptable to put it into smtpd_relay_restrictions instead? I am worried if I do this, it would not be able to prevent these bad hosts from sending mail directly to my domain (non-relay), which kind of defeats the purpose of using it for botnet protection. smtpd_relay_restrictions should be reserved for relay decisions only. Anti-spam controls should be in one of the other smtpd_*_restrictions sections. -- Noel Jones
Re: dictionary-attack
On 3/27/2013 5:11 PM, Matthew Hall wrote: I ran into a bit of an issue trying out fqrdns.pcre as recommended here in this thread. The header in the file recommended adding it into smtpd_client_restrictions. The instructions I provide are examples, not a concise how-to. As with any restriction table, it's up to the administrator to decide how/where it best fits into his/her configuration. This table is targeted at intermediate to advanced level Postfix administrators, not entry level folks. However if I place it there, I end up rejecting mail even from SASL authenticated client devices, if they also match a rule in fqrdns.pcre. This is because you inserted the restriction before permit_sasl_authenticated. It must be inserted after. Is it acceptable to put it into smtpd_relay_restrictions instead? It seems pretty clear you need to convert to putting everything under smtpd_recipient_restrictions. Makes things a lot easier. I give an example of this in the instructions as well. Doing so gives you precise control of restriction evaluation order. Frankly I'm surprised anyone still uses the old multi-section restrictions configuration these days. If after Google you need help converting, let us know. -- Stan
Re: dictionary-attack
On Wed, Mar 27, 2013 at 05:56:03PM -0500, Stan Hoeppner wrote: Frankly I'm surprised anyone still uses the old multi-section restrictions configuration these days. Sometimes it's necessary for complex restrictions, but I think the worst I've ever needed was 2-3 mumbles of smtpd_mumble_restrictions. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: dictionary-attack
On 3/27/2013 5:39 PM, Noel Jones wrote: One could argue the example included in the file should be clearer I'm open to suggestions. As long as the doc section doesn't end up longer than the expression list. (and it's missing the required '='). Fixed. Thanks for catching this oversight Noel. I've (over)looked that only a few hundred times. I also added text explaining it can be used as table type PCRE or REGEXP. -- Stan
Re: dictionary-attack
On Wed, Mar 27, 2013 at 3:56 PM, Stan Hoeppner s...@hardwarefreak.com wrote: It seems pretty clear you need to convert to putting everything under smtpd_recipient_restrictions. Makes things a lot easier. I give an example of this in the instructions as well. Doing so gives you precise control of restriction evaluation order. Frankly I'm surprised anyone still uses the old multi-section restrictions configuration these days. If after Google you need help converting, let us know. Hi Stan, Of course I'm grateful for the file and the instructions inside, which is why I was excited to try it, and I have no problem doing the restrictions in the single list if it's the accepted best way, but it's different from the advice I found and got on a separate thread that it's safer to place the relay restrictions into smtpd_relay_restrictions instead. So I just wanted to be sure to understand the difference before making changes blindly and adding yet more open relays to the Internet, and possibly getting myself blacklisted in the process. ;) FWIW, I didn't do it wrong when I added it to smtpd_relay_restrictions, I already checked this before posting: smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, #check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, reject_unauth_destination So the evaluation order issue must have been caused by using two lists, instead of the ordering in relay_restrictions. Matthew.
Re: dictionary-attack
I altered the restrictions according to the new advice: relay_restrictions - removed smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org, #reject_rbl_client cbl.abuseat.org, #reject_rbl_client list.dsbl.org, #reject_rbl_client sbl.spamhaus.org, #reject_rbl_client pbl.spamhaus.org permit Now, with everything in one list, all of the trivial RFC-ish checks come first, then client access (to allow whitelisting), then fqrdns.pcre, then special HELO, From, and To checks, then we go to the more expensive ones that use DNS. Does this make more sense than what I did before? Or am I still off base. Thanks for your help. Matthew.
Re: dictionary-attack
On 3/27/2013 6:15 PM, Stan Hoeppner wrote: On 3/27/2013 5:39 PM, Noel Jones wrote: One could argue the example included in the file should be clearer I'm open to suggestions. As long as the doc section doesn't end up longer than the expression list. I would suggest a fully-working example to help out the newbies. Maybe something like: simple usage example; add this to your main.cf smtpd_client_restrictions = permit_sasl_authenticated permit_mynetworks check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre see the postfix docs or the postfix-users mail list for details (and it's missing the required '='). Fixed. Thanks for catching this oversight Noel. I've (over)looked that only a few hundred times. I also added text explaining it can be used as table type PCRE or REGEXP. (BTDT...) Thanks. -- Noel Jones
Re: dictionary-attack
On 3/27/2013 7:07 PM, Matthew Hall wrote: smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks, #check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, reject_unauth_destination The above is wrong in two ways. First, anti-spam access lists MUST be after reject_unauth_destination. Secondly, anti-spam access lists don't belong in smtpd_relay_restrictions. The intent of smtpd_relay_restrictions is a safety net to prevent unintentional open relays that sometimes happen in anti-spam controls. Unless you have complex relay controls (and don't confuse complex relay controls with complex anti-spam controls!) you should have only smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination All your anti-spam stuff goes in the other smtpd_*_restrictions. It's often convenient to put all anti-spam controls under smtpd_recipient_restrictions, as suggested elsewhere in this thread. -- Noel Jones
Re: dictionary-attack
On 3/27/2013 7:18 PM, Matthew Hall wrote: I altered the restrictions according to the new advice: relay_restrictions - removed there's no reason to remove the safety net. smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination Yes, these are repeated in smtpd_recipient_restrictions. That's why this is called a safety net -- to protect against accidents in smtpd_recipient_restrictions. No, executing these extra commands this will not slow down postfix. Your smtpd_recipient_restrictions look great, but I will mention list.dsbl.org is dead and unlikely to return; probably best to remove that line instead of just commenting it out. -- Noel Jones smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_hostname, reject_non_fqdn_hostname, reject_non_fqdn_sender, reject_non_fqdn_recipient, check_client_access hash:/etc/postfix/client_checks, check_client_access pcre:/etc/postfix/client_checks.pcre, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_helo_access hash:/etc/postfix/helo_checks, check_sender_access hash:/etc/postfix/sender_checks, check_recipient_access pcre:/etc/postfix/recipient_checks.pcre, reject_unknown_sender_domain, reject_rbl_client zen.spamhaus.org, #reject_rbl_client cbl.abuseat.org, #reject_rbl_client list.dsbl.org, #reject_rbl_client sbl.spamhaus.org, #reject_rbl_client pbl.spamhaus.org permit Now, with everything in one list, all of the trivial RFC-ish checks come first, then client access (to allow whitelisting), then fqrdns.pcre, then special HELO, From, and To checks, then we go to the more expensive ones that use DNS. Does this make more sense than what I did before? Or am I still off base. Thanks for your help. Matthew.
Re: compile and path
hi, sorry for late. i merged CCARGS as : / make -f Makefile.init makefiles 'CCARGS=-DHAS_MYSQL -I/usr/include/mysql/ -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\dovecot\ -DUSE_TLS -I/usr/include/openssl/' 'AUXLIBS=-L/usr/lib64/mysql -L/usr/lib -lmysqlclient -lz -lm -lssl -lcrypto ' / But when i use : /// telnet 0 25 i get the // ehlo localhost 250-mail.pahlevanzadeh.info 250-PIPELINING 250-SIZE 3072 250-VRFY 250-ETRN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN /// I read to should get the // ehlo localhost 250-plato.example.com 250-PIPELINING 250-SIZE 3072 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN /// What's happen? However dovecot isn't ran. --mohsen On Sun, 2013-03-24 at 06:21 -0500, /dev/rob0 wrote: On Sun, Mar 24, 2013 at 08:31:32AM +0430, Mohsen Pahlevanzadeh wrote: i compiled postfix with : make -f Makefile.init makefiles 'CCARGS=-DHAS_MYSQL -I/usr/include/mysql/' CCARGS='-DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE= \dovecot\' CCARGS='-DUSE_TLS -I/usr/include/openssl/' 'AUXLIBS=-L/usr/lib64/mysql -L/usr/lib -lmysqlclient -lz -lm -lssl -lcrypto ' i checked their path on my machine. they was correct.library and include files. Question: can i use many CCARGS when i use make command? Merge all your CCARGS into a single expression. make makefiles CCARGS=-DHAS_MYSQL -I/usr/include/mysql/ \ -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\dovecot\ -DUSE_TLS \ -I/usr/include/openssl/ AUXLIBS=-L/usr/lib64/mysql -L/usr/lib \ -lmysqlclient -lz -lm -lssl -lcrypto http://www.postfix.org/INSTALL.html http://www.postfix.org/MYSQL_README.html http://www.postfix.org/SASL_README.html#postfix_build http://www.postfix.org/TLS_README.html#build_tls
Re: dictionary-attack
On Wed, Mar 27, 2013 at 7:20 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 3/27/2013 7:18 PM, Matthew Hall wrote: I altered the restrictions according to the new advice: relay_restrictions - removed there's no reason to remove the safety net. Makes sense. Corrected. Your smtpd_recipient_restrictions look great, but I will mention list.dsbl.org is dead and unlikely to return; probably best to remove that line instead of just commenting it out. Agree. Corrected. One other question here. So, if I have a host which matches permit_sasl_authenticated, but also matches one of the rejections present in check_reverse_client_hostname_access, but permit_sasl_authenticated comes first in recipient_restrictions, then it's still going to work right, because the first rule in the chain wins, correct? Just want to be sure I parsed the documentation correctly. -- Noel Jones Thanks, Matthew
Re: dictionary-attack
On 3/27/2013 10:07 PM, Matthew Hall wrote: One other question here. So, if I have a host which matches permit_sasl_authenticated, but also matches one of the rejections present in check_reverse_client_hostname_access, but permit_sasl_authenticated comes first in recipient_restrictions, then it's still going to work right, because the first rule in the chain wins, correct? Just want to be sure I parsed the documentation correctly. Yes, first match wins. http://www.postfix.org/documentation.html - for the purpose of this discussion, we'll treat OK and permit as interchangeable. - the smtpd_*_restrictions are executed in the order: smtpd_client_restrictions smtpd_helo_restrictions smtpd_sender_restrictions smtpd_recipient_restrictions smtpd_relay_restrictions (if your postfix supports this) smtpd_data_restrictions smtpd_end_of_data_restrictions You might notice this is the same order as an SMTP transaction. Details here: http://www.postfix.org/OVERVIEW.html - within each smtpd_*_restrictions section, restrictions are executed in exactly the order you specify. - first match wins - any REJECT/DEFER action takes effect immediately; all subsequent smtpd_*_restrictions are skipped. - each smtpd_*_restrictions section must resolve to permit (or empty) to accept mail. A permit in one smtpd_*_restrictions section is not inherited by the next section. - special case -- access(5) documents several OTHER ACTIONS other than OK/REJECT. These actions stop processing of that single access table and skip to the next rule within the same smtpd_*_restrictions section. DEFER_IF_PERMIT and DEFER_IF_REJECT are also treated this way; they don't take effect until a REJECT or (final) PERMIT decision is made. http://www.postfix.org/access.5.html -- Noel Jones
