Re: Restrictions after postscreen
On Mon, May 13, 2013 at 6:42 PM, Noel Jones njo...@megan.vbhcs.org wrote: On 5/13/2013 6:34 PM, Steve Jenkins wrote: On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 r...@gmx.co.uk mailto:r...@gmx.co.uk wrote: Here are my current entries: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, I don't put these permit_* in global restrictions; I only apply them to submission via -o smtpd_relay_restrictions=... in master.cf http://master.cf. And that brings up another point: if you're using 2.10 you now have smtpd_relay_restrictions for relay control. First, thanks for the extremely insightful help, Rob. OK - I commented those two lines out of smtpd_recipient_restrictions as recommended, and added a new smtpd_relay_restrictions -o line to submission in master.cf http://master.cf. My submission now reads: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination However, I get this when sending a message from my home desktop (connected via Comcast) via my personal Postfix server to my Gmail test address: Don't forget that all the other main.cf parameters are still in effect on your submission entry; likely you're seeing unintended spillover. I suggest setting ALL the smtpd_*_restrictions entries for submission in master.cf so you don't have unexpected results. submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o milter_macro_daemon_name=ORIGINATING -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject Hmm.. for some reason, I can't seem to get it to aceept my smtpd_relay_restrictions settings. In main.cf: smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination but the I get: # postconf -d | grep smtpd_relay smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination Any idea why my permit_sasl_authenticated is being ignored in favor of the default? SteveJ
Re: Restrictions after postscreen
On 2013-05-14 10:35 AM, Steve Jenkins stevejenk...@gmail.com wrote: # postconf -d | grep smtpd_relay smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination Any idea why my permit_sasl_authenticated is being ignored in favor of the default? -d gives DEFAULTS -n is what you want to use to see your changes... -- Best regards, Charles
Re: Restrictions after postscreen
On Tue, May 14, 2013 at 07:35:15AM -0700, Steve Jenkins wrote: # postconf -d | grep smtpd_relay smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination Any idea why my permit_sasl_authenticated is being ignored in favor of the default? | -d Print main.cf default parameter settings instead of actual settings. Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, Day of the Dove, stardate unknown
Re: Restrictions after postscreen
On Tue, May 14, 2013 at 7:38 AM, Charles Marcus cmar...@media-brokers.comwrote: On 2013-05-14 10:35 AM, Steve Jenkins stevejenk...@gmail.com wrote: # postconf -d | grep smtpd_relay smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination Any idea why my permit_sasl_authenticated is being ignored in favor of the default? -d gives DEFAULTS -n is what you want to use to see your changes... Doh. Of course it is. Can you tell I just woke up? :)
Re: Restrictions after postscreen
On Mon, May 13, 2013 at 6:42 PM, Noel Jones njo...@megan.vbhcs.org wrote: Don't forget that all the other main.cf parameters are still in effect on your submission entry; likely you're seeing unintended spillover. I suggest setting ALL the smtpd_*_restrictions entries for submission in master.cf so you don't have unexpected results. submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o milter_macro_daemon_name=ORIGINATING -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject That was the final piece, Noel. Thx. Explicitly setting empty values for those options for submission fixed whatever unintended spillover I was experiencing. Thanks to everyone's help here, I now have a slightly better understanding of how these restrictions should work, and a much cleaner and easier to understand list of recipient restrictions: main.cf: ... # SMTPD Restrictions smtpd_helo_required = yes disable_vrfy_command = yes smtpd_recipient_restrictions = reject_invalid_helo_hostname, warn_if_reject reject_non_fqdn_helo_hostname, reject_unknown_reverse_client_hostname, warn_if_reject reject_unknown_helo_hostname, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_helo_access hash:/etc/postfix/helo_access, check_sender_access hash:/etc/postfix/sender_access, reject_rbl_client zen.spamhaus.org, reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org, permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3], permit smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination smtpd_data_restrictions = reject_unauth_pipelining ... master.cf: ... submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o milter_macro_daemon_name=ORIGINATING -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= ... Thanks again! SteveJ
Re: Restrictions after postscreen
On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote: smtpd_recipient_restrictions = reject_invalid_helo_hostname, warn_if_reject reject_non_fqdn_helo_hostname, reject_unknown_reverse_client_hostname, warn_if_reject reject_unknown_helo_hostname, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_helo_access hash:/etc/postfix/helo_access, check_sender_access hash:/etc/postfix/sender_access, reject_rbl_client zen.spamhaus.org, reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org, permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3], permit The last two lines are no-op. If you have anything you want to be subjected to the list.dnswl.org whitelist, put it after the permit_dnswl_client. If not, there is no point in querying it. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Restrictions after postscreen
On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 r...@gmx.co.uk wrote: On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote: smtpd_recipient_restrictions = reject_invalid_helo_hostname, warn_if_reject reject_non_fqdn_helo_hostname, reject_unknown_reverse_client_hostname, warn_if_reject reject_unknown_helo_hostname, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_helo_access hash:/etc/postfix/helo_access, check_sender_access hash:/etc/postfix/sender_access, reject_rbl_client zen.spamhaus.org, reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org, permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3], permit The last two lines are no-op. If you have anything you want to be subjected to the list.dnswl.org whitelist, put it after the permit_dnswl_client. If not, there is no point in querying it. Excellent point. If the next step is going to permit anyway, then no use in the extra query. I've moved the dnswl.org line up so that it's just above the three local check_* lines. SteveJ
Re: Restrictions after postscreen
On 5/14/2013 11:45 AM, Steve Jenkins wrote: On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 r...@gmx.co.uk wrote: On Tue, May 14, 2013 at 07:49:50AM -0700, Steve Jenkins wrote: smtpd_recipient_restrictions = reject_invalid_helo_hostname, warn_if_reject reject_non_fqdn_helo_hostname, reject_unknown_reverse_client_hostname, warn_if_reject reject_unknown_helo_hostname, check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_helo_access hash:/etc/postfix/helo_access, check_sender_access hash:/etc/postfix/sender_access, reject_rbl_client zen.spamhaus.org, reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org, permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3], permit The last two lines are no-op. If you have anything you want to be subjected to the list.dnswl.org whitelist, put it after the permit_dnswl_client. If not, there is no point in querying it. Excellent point. If the next step is going to permit anyway, then no use in the extra query. I've moved the dnswl.org line up so that it's just above the three local check_* lines. permits always come before rejects. Thus whitelist type entries should always be at the top of the restrictions list. As you are using (client|helo|sender|recipient) sections any whitelisting in smtpd_recipient_restrictions should typically be at the very top. permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3] ^^ This shows you are explicitly permitting anything/everything listed in the dnswl. Are you sure that is what you want? I use... permit_dnswl_client list.dnswl.org=127.0.[2..14].[2..3] which does not explicitly permit email marketing providers nor any IP with trustworthiness score of 1. A score of 1 is equivalent to a SpamAssassin score of -1, which does not merit a direct shot to the queue. That would typically require an SA score of -5. I want these clients to go through all of my other restrictions before allowing their payload into my queue. Also worth noting, there are currently only 14 categories (3rd octet of a reply), so specifying 255 is not necessary, and possibly problematic. Hypothetically, if dnswl decided one day to create categories 16, political campaigns, and 17, religious newsletters, you are currently setup to automatically permit such clients. Remember, the sole purpose of whitelisting is to bypass all of your other spam checks and get the mail into your queue unmolested. IMO, not every IP listed by dnswl is deserving of this honor, not even close to all of them. See section Return codes at: http://www.dnswl.org/tech -- Stan
Re: Restrictions after postscreen (was: Re: Postscreen DNSBL Sites)
On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 r...@gmx.co.uk wrote: Here are my current entries: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, I don't put these permit_* in global restrictions; I only apply them to submission via -o smtpd_relay_restrictions=... in master.cf. And that brings up another point: if you're using 2.10 you now have smtpd_relay_restrictions for relay control. First, thanks for the extremely insightful help, Rob. OK - I commented those two lines out of smtpd_recipient_restrictions as recommended, and added a new smtpd_relay_restrictions -o line to submission in master.cf. My submission now reads: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination However, I get this when sending a message from my home desktop (connected via Comcast) via my personal Postfix server to my Gmail test address: May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject_warning: RCPT from c-xx-xxx-xx-xx.hsd1.wa.comcast.net[xx.xxx.xx.xx]: 504 5.5.2 STEVEJPC: Helo command rejected: need fully-qualified hostname; from= u...@example.com to=u...@gmail.com proto=ESMTP helo=STEVEJPC May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject_warning: RCPT fromc-xx-xxx-xx-xx.hsd1.wa.comcast.net[[xx.xxx.xx.xx]: 450 4.7.1 STEVEJPC: Helo command rejected: Host not found; from=u...@example.com to=u...@gmail.com proto=ESMTP helo=STEVEJPC May 13 16:05:48 carbonfiber postfix/smtpd[25210]: NOQUEUE: reject: RCPT fromc-xx-xxx-xx-xx.hsd1.wa.comcast.net[[xx.xxx.xx.xx]: 554 5.7.1 c-xx-xxx-xx-xx5.hsd1.wa.comcast.net[xx.xxx.xx.xx]: Unverified Client host rejected: Generic - Please relay via ISP (comcast.net); from= u...@example.com to=u...@gmail.com proto=ESMTP helo=STEVEJPC That last line is a result of using from Stan's excellent PCRE file (using check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre). Uncommenting the two permit_* lines in smtpd_recipient_restrictions allows the message to send without error. I'm running 2.10.0 so smtpd_relay_restrictions should be available to me, but I'm not sure why it's not working as I expected it to on the submission. I'm also wondering if I no longer need that -o smtpd_client_restrictrions in master.cf ( reject_invalid_hostname, Deprecated syntax for reject_invalid_helo_hostname. reject_unauth_destination, See above re: smtpd_relay_restrictions. warn_if_reject reject_non_fqdn_hostname, I consider this one quite safe. In fact, it's one of the CBL's listing criteria; when they see a host using a non-FQDN as HELO, it will be listed. Deprecated syntax again. warn_if_reject reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unknown_sender_domain, These are safe, but mostly pointless here. You might want them on submission, in case a user has a misconfigured MUA. warn_if_reject reject_unknown_reverse_client_hostname, Safe, because many large receivers do this as well. warn_if_reject reject_non_fqdn_helo_hostname, This is the new syntax for reject_non_fqdn_hostname, you do the warning twice for the same thing. warn_if_reject reject_invalid_helo_hostname, Deja vu all over again! warn_if_reject reject_unknown_helo_hostname, This one is NOT safe. A lot of sites use HELOs which don't resolve. So I'd not take off the warn_if_reject. reject_unauth_pipelining, This could go higher. It's a cheap restriction. check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre, check_helo_access hash:/etc/postfix/helo_access, check_sender_access hash:/etc/postfix/check_backscatterer, check_sender_access hash:/etc/postfix/access, access is not a descriptive name. I would name it either sender_access or whatever the general purpose of the lookup is. It could also be merged with the check_backscatterer lookup. reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org, permit My guess would be to either put them just after the reject_unknown_sender_domain or just before the check_reverse_client_hostname... but that's a total guess. The BRBL entry I'd stick back just in front of the reject_rhsbl_client entry. I wouldn't whitelist the check_*_access lookups, but you might choose to do that for your own reasons. I would put Zen just before the three DBL lookups. This way the DBL lookups might be avoided. I'd keep DBL before DNSWL. I doubt the DNSWL folks want to list any client sending for DBL-listed domains, so check DBL first.
Re: Restrictions after postscreen
On 5/13/2013 6:34 PM, Steve Jenkins wrote: On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 r...@gmx.co.uk mailto:r...@gmx.co.uk wrote: Here are my current entries: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, I don't put these permit_* in global restrictions; I only apply them to submission via -o smtpd_relay_restrictions=... in master.cf http://master.cf. And that brings up another point: if you're using 2.10 you now have smtpd_relay_restrictions for relay control. First, thanks for the extremely insightful help, Rob. OK - I commented those two lines out of smtpd_recipient_restrictions as recommended, and added a new smtpd_relay_restrictions -o line to submission in master.cf http://master.cf. My submission now reads: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination However, I get this when sending a message from my home desktop (connected via Comcast) via my personal Postfix server to my Gmail test address: Don't forget that all the other main.cf parameters are still in effect on your submission entry; likely you're seeing unintended spillover. I suggest setting ALL the smtpd_*_restrictions entries for submission in master.cf so you don't have unexpected results. submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o milter_macro_daemon_name=ORIGINATING -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -- Noel Jones
Re: Restrictions after postscreen
On 5/13/2013 8:42 PM, Noel Jones wrote: On 5/13/2013 6:34 PM, Steve Jenkins wrote: On Wed, May 1, 2013 at 5:14 AM, /dev/rob0 r...@gmx.co.uk mailto:r...@gmx.co.uk wrote: Here are my current entries: smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, I don't put these permit_* in global restrictions; I only apply them to submission via -o smtpd_relay_restrictions=... in master.cf http://master.cf. And that brings up another point: if you're using 2.10 you now have smtpd_relay_restrictions for relay control. First, thanks for the extremely insightful help, Rob. OK - I commented those two lines out of smtpd_recipient_restrictions as recommended, and added a new smtpd_relay_restrictions -o line to submission in master.cf http://master.cf. My submission now reads: submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o smtpd_relay_restrictions=permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination However, I get this when sending a message from my home desktop (connected via Comcast) via my personal Postfix server to my Gmail test address: Don't forget that all the other main.cf parameters are still in effect on your submission entry; likely you're seeing unintended spillover. I suggest setting ALL the smtpd_*_restrictions entries for submission in master.cf so you don't have unexpected results. submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o milter_macro_daemon_name=ORIGINATING -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject and don't forget -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions= -- Noel Jones
Re: Restrictions after postscreen (was: Re: Postscreen DNSBL Sites)
On 2013-05-01 07:14:37 -0500, /dev/rob0 wrote: On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote: warn_if_reject reject_unknown_reverse_client_hostname, Safe, because many large receivers do this as well. That's interesting. Several months ago, I intended to add it, but I noticed that legitimate mail I received sometimes contained unknown (at least for some user), e.g. Received: from snip (unknown [174.33.138.226]) by ioooi.vinc17.net (Postfix) with ESMTP id 017ED31D51 for vinc...@vinc17.org; Tue, 19 Jul 2011 05:03:52 +0200 (CEST) and at that time, I thought that the machine didn't have a correct reverse hostname, so that I thought that adding this option would be bad. But if I grep all the messages from this IP, I now notice that for most of them, I get host1743300226138.direcway.com instead of unknown, which occurs only from time to time. This makes me think that the unknown could just be due to a temporary failure, but with the above option, the mail wouldn't be rejected (it would just be delayed from time to time due to the 450 reply, as documented). Is this correct? Regards, -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Restrictions after postscreen
On 5/2/2013 6:27 AM, Vincent Lefevre wrote: On 2013-05-01 07:14:37 -0500, /dev/rob0 wrote: On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote: warn_if_reject reject_unknown_reverse_client_hostname, Safe, because many large receivers do this as well. That's interesting. Several months ago, I intended to add it, but I noticed that legitimate mail I received sometimes contained unknown (at least for some user), e.g. Received: from snip (unknown [174.33.138.226]) by ioooi.vinc17.net (Postfix) with ESMTP id 017ED31D51 for vinc...@vinc17.org; Tue, 19 Jul 2011 05:03:52 +0200 (CEST) and at that time, I thought that the machine didn't have a correct reverse hostname, so that I thought that adding this option would be bad. But if I grep all the messages from this IP, I now notice that for most of them, I get host1743300226138.direcway.com instead of unknown, which occurs only from time to time. This makes me think that the unknown could just be due to a temporary failure, but with the above option, the mail wouldn't be rejected (it would just be delayed from time to time due to the 450 reply, as documented). Is this correct? Regards, If the DNS lookup fails with a temporary error, the mail will be deferred. It's important to note that not all clients labeled as unknown will be rejected by reject_unknown_reverse_client_hostname. For enlightenment, compare the docs on reject_unknown_client_hostname (a strict test not widely used), with the docs on reject_unknown_reverse_client_hostname (a generally safe check). Very strict: http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname Generally safe: http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname -- Noel Jones
