On 2013-05-14 10:35 AM, Steve Jenkins <[hidden email]> 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 |
In reply to this post by Steve Jenkins-3
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 |
In reply to this post by Charles Marcus
On Tue, May 14, 2013 at 7:38 AM, Charles Marcus <[hidden email]> wrote:
Doh. Of course it is. Can you tell I just woke up? :) |
In reply to this post by Noel Jones-2
On Mon, May 13, 2013 at 6:42 PM, Noel Jones <[hidden email]> wrote:
Don't forget that all the other main.cf parameters are still in 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:
... # 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 ... ... 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 |
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: |
On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 <[hidden email]> wrote:
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 |
On 5/14/2013 11:45 AM, Steve Jenkins wrote:
> On Tue, May 14, 2013 at 8:33 AM, /dev/rob0 <[hidden email]> 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 |
Free forum by Nabble | Edit this page |