Re: smtp restrictions
James Zee skrev den 2013-05-31 06:43: reject_rhsbl_sender dsn.rfc-ignorant.org http://www.rfc-ignorant.de/ -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: smtp restrictions
On 5/30/2013 11:43 PM, James Zee wrote: I was hoping someone could take a quick glance at my smtpd_*_restrictions configurations. While I've read and (re-)read the SMTPD_ACCESS_README file a few times over I would be greatly appreciative if someone could sanity check my work. Reviewing people's main.cf files is not a function of the mailing list. Answering specific questions or solving problems related to main.cf is. If we did the former the list would be clogged with such requests and responses. Thus I'll reply off list. It'll arrive shortly. -- Stan
Re: smtp restrictions
Stan, On 05/31/2013 08:49 AM, Stan Hoeppner wrote: On 5/30/2013 11:43 PM, James Zee wrote: I was hoping someone could take a quick glance at my smtpd_*_restrictions configurations. While I've read and (re-)read the SMTPD_ACCESS_README file a few times over I would be greatly appreciative if someone could sanity check my work. Reviewing people's main.cf files is not a function of the mailing list. Answering specific questions or solving problems related to main.cf is. If we did the former the list would be clogged with such requests and responses. Thus I'll reply off list. It'll arrive shortly. I disagree. It could be VERY helpful to others to have a discussion about different configurations. It is a way to learn. I fail to see why you have the authority to decide what is and is not the purpose of this mailing list. Cheers, Mikael
Re: smtp restrictions
On 5/31/2013 4:09 AM, Mikael Bak wrote: Stan, On 05/31/2013 08:49 AM, Stan Hoeppner wrote: On 5/30/2013 11:43 PM, James Zee wrote: I was hoping someone could take a quick glance at my smtpd_*_restrictions configurations. While I've read and (re-)read the SMTPD_ACCESS_README file a few times over I would be greatly appreciative if someone could sanity check my work. Reviewing people's main.cf files is not a function of the mailing list. Answering specific questions or solving problems related to main.cf is. If we did the former the list would be clogged with such requests and responses. Thus I'll reply off list. It'll arrive shortly. I disagree. It could be VERY helpful to others to have a discussion about different configurations. It is a way to learn. Long ago I shared this sentiment, until Wietse made it very clear to me that we don't do this here. I fail to see why you have the authority to decide what is and is not the purpose of this mailing list. Surely you don't believe I would attempt to arbitrarily set list policy. What I stated above is Wietse's policy: It is a waste of everyone's time including the poster and readers to go spell check main.cf files on the mailing list. Wietse Venema 12/09/2010 -- Stan
Re: smtp restrictions
On 2013-05-31 6:04 AM, Stan Hoeppner s...@hardwarefreak.com wrote: It is a waste of everyone's time including the poster and readers to go spell check main.cf files on the mailing list. Wietse Venema 12/09/2010 Stan, I certainly don't read that as saying people cannot ask for a sanity check on their current config. It says (to me, but Wietse can correct me if I'm wrong) not to submit copy/paste snippets from main.cf, but rather, provide output of postconf -n. I disagree wholeheartedly that people should not be able to ask for this kind of help. Think of those coming from a sendmail, or qmail, or exim, or courier - it would be really bad policy if this list rejected requests from people like this who just want to make sure they got things (mostly) right. -- Best regards, Charles
Re: smtp restrictions
On Fri, May 31, 2013 at 12:43:51AM -0400, James Zee wrote: I was hoping someone could take a quick glance at my smtpd_*_restrictions configurations. While I've read and (re-)read the SMTPD_ACCESS_README file a few times over I would be greatly appreciative if someone could sanity check my work. The goal is, obviously, to (a) block spammers, (b) only allow relaying / sending to SASL-authorized users. --8-- smtpd_relay_restrictions = If you have smtpd_relay_restrictions, you have postscreen. Consider postscreen in addition to the spam control restrictions below. permit_mynetworks permit_sasl_authenticated check_policy_service unix:private/policy-spf reject_unauth_destination As was indicated upthread, this could be a problem. I'm not sure why you'd be checking SPF in smtpd_relay_restrictions anyway. Also, you really should separate submission from your inbound port 25. I only allow relaying on the submission port. As such I define separate smtpd_*_restrictions for the submission port, to wit: [ master.cf ] submission inet n - n - - smtpd -o smtpd_tls_auth_only=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=$submission_relay_restrictions -o milter_macro_daemon_name=ORIGINATING -o syslog_name=postfix/submission (Also unset any other restrictions which are in use on port 25.) [ main.cf ] submission_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination (Also include any other restrictions that you want to apply to your own users, before the permit_* ones.) smtpd_recipient_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain ok reject_non_fqdn_recipient reject_unknown_recipient_domain These two will generally only apply to your own users. Won't hurt anything being applied to inbound mail, but won't help, either. reject_non_fqdn_hostname reject_invalid_hostname These are both deprecated syntax. Did you look them up in the postconf(5) manual? They are reject_non_fqdn_helo_hostname and reject_invalid_helo_hostname respectively. And they're reasonably safe except that they should not be applied to your own users. reject_unauth_destination smtpd_relay_restrictions has this, so it's not needed here. OTOH perhaps you did need the permit_* restrictions you have omitted; everything here will also be applied to your own users: very wrong! reject_unauth_pipelining reject_rbl_client zen.spamhaus.org You definitely should not apply Zen to your own users. reject_rbl_client bl.spamcop.net I wouldn't use Spamcop like this. I use it with a low score in postscreen. reject_rbl_client cbl.abuseat.org This is included in Zen and now hosted by Spamhaus, wasted lookup. reject_rbl_client dnsbl.njabl.org NJABL is no more. reject_rbl_client dnsbl.sorbs.net I wouldn't use SORBS like this. I use it with a low score in postscreen. reject_rhsbl_sender dsn.rfc-ignorant.org RFC-ignorant.org is long gone. Don't use random DNSBLs/RHSBLs without becoming familiar with them and their policies. reject_rhsbl_sender blackhole.securitysage.com Yikes, this one looks like a wildcard! I don't know what happened to securitysage.com, but I suspect it is not under the control of the original registrant. An extra pair of eyes that could confirm things look good and things are as locked down as possible (both in terms of relaying *and* dealing with blacklisted IPs) would be greatly appreciated. Consider postscreen, as I said, and Stan's fcrdns.pcre, as I bet he said. http://www.postfix.org/POSTSCREEN_README.html http://rob0.nodns4.us/postscreen.html -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
List rules (was: smtp restrictions)
Stan Hoeppner: What I stated above is Wietse's policy: It is a waste of everyone's time including the poster and readers to go spell check main.cf files on the mailing list. To place the quote in context: Stan: This is exactly why I wanted to see your main.cf. It's a total mess. I'll try to annotate needed changes. then my main.cf: cat /etc/postfix/main.cf Everything from here... permit_sasl_authenticated, reject_unauth_destination check_client_access pcre:/etc/postfix/fqrdns.pcre, reject_rbl_client dnsbl.sorbs.net, Wietse: This is PRECISELY why this mailing list instists on posting POSTCONF -N output, because THAT is the only way to find out that the main.cf file is mal-formed. It is a waste of everyone's time including the poster and readers to go spell check main.cf files on the mailing list. Meanwhile the postconf command has evolved such that it will warn about unused/undefined parameter settings in main.cf (and master.cf). At this point there are no reasons left to post main.cf files instead of postconf -n output, except to report a discrepancy between them. That said, the main purpose of this list is to help people use Postfix, so it is appropriate to cut newcomers some slack (but not too much; they should provide information after 1-2 reminders). Wietse
Re: smtp restrictions
On Fri, May 31, 2013 at 8:09 AM, /dev/rob0 r...@gmx.co.uk wrote: On Fri, May 31, 2013 at 12:43:51AM -0400, James Zee wrote: I was hoping someone could take a quick glance at my smtpd_*_restrictions configurations. While I've read and (re-)read the SMTPD_ACCESS_README file a few times over I would be greatly appreciative if someone could sanity check my work. The goal is, obviously, to (a) block spammers, (b) only allow relaying / sending to SASL-authorized users. --8-- smtpd_relay_restrictions = If you have smtpd_relay_restrictions, you have postscreen. Consider postscreen in addition to the spam control restrictions below. permit_mynetworks permit_sasl_authenticated check_policy_service unix:private/policy-spf reject_unauth_destination As was indicated upthread, this could be a problem. I'm not sure why you'd be checking SPF in smtpd_relay_restrictions anyway. Also, you really should separate submission from your inbound port 25. I only allow relaying on the submission port. As such I define separate smtpd_*_restrictions for the submission port, to wit: [ master.cf ] submission inet n - n - - smtpd -o smtpd_tls_auth_only=yes -o smtpd_sasl_auth_enable=yes -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=$submission_relay_restrictions -o milter_macro_daemon_name=ORIGINATING -o syslog_name=postfix/submission (Also unset any other restrictions which are in use on port 25.) Thanks for the tip. This is a good idea that I just attempted to implement based on some reading / research. Forgive the lack of knowledge in this particular field -- like your postscreen readme indicated, I'm attempting to walk before I run. :) Any gentle guidance on things to improve in this master.cf snippet would be definitely appreciated and humbly accepted. --8-- submission inet n - - - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt smtps inet n - - - - smtpd -o syslog_name=postfix/smtps --8-- Look good? [ main.cf ] submission_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination (Also include any other restrictions that you want to apply to your own users, before the permit_* ones.) smtpd_recipient_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain ok reject_non_fqdn_recipient reject_unknown_recipient_domain These two will generally only apply to your own users. Won't hurt anything being applied to inbound mail, but won't help, either. reject_non_fqdn_hostname reject_invalid_hostname These are both deprecated syntax. Did you look them up in the postconf(5) manual? They are reject_non_fqdn_helo_hostname and reject_invalid_helo_hostname respectively. And they're reasonably safe except that they should not be applied to your own users. Yes, you're right. I suppose I found these deprecated syntaxes in some reading material and didn't look them up to confirm. reject_unauth_destination smtpd_relay_restrictions has this, so it's not needed here. OTOH perhaps you did need the permit_* restrictions you have omitted; everything here will also be applied to your own users: very wrong! Can you please clarify? I omitted permit_* restrictions because I didn't think that they were necessary if a message passed all of the reject restrictions. Should I be explicitly defining a permit? If so, where and why? reject_unauth_pipelining reject_rbl_client zen.spamhaus.org You definitely should not apply Zen to your own users. reject_rbl_client bl.spamcop.net I wouldn't use Spamcop like this. I use it with a low score in postscreen. reject_rbl_client cbl.abuseat.org This is included in Zen and now hosted by Spamhaus, wasted lookup. reject_rbl_client dnsbl.njabl.org NJABL is no more. reject_rbl_client dnsbl.sorbs.net I wouldn't use SORBS like this. I use it with a low score in postscreen. reject_rhsbl_sender dsn.rfc-ignorant.org RFC-ignorant.org is long gone. Don't use random DNSBLs/RHSBLs without becoming familiar with them and their policies. reject_rhsbl_sender blackhole.securitysage.com Yikes, this one looks like a wildcard! I don't know what happened to securitysage.com, but I suspect it is not under the control of the original registrant. An extra pair of eyes that could confirm things look good and things are as locked down as possible (both in terms of relaying *and* dealing with blacklisted IPs) would be greatly appreciated. Consider postscreen, as I said, and Stan's fcrdns.pcre, as I bet he said. http://www.postfix.org/POSTSCREEN_README.html http://rob0.nodns4.us/postscreen.html Thank you for the detailed response. I will take a look at both and follow up with any further questions about fcrdns.pcre or postscreen if needed.
Re: smtp restrictions
On Fri, May 31, 2013 at 11:15:05AM -0400, James Zee wrote: On Fri, May 31, 2013 at 8:09 AM, /dev/rob0 r...@gmx.co.uk wrote: On Fri, May 31, 2013 at 12:43:51AM -0400, James Zee wrote: snip Also, you really should separate submission from your inbound port 25. I only allow relaying on the submission port. As such I define separate smtpd_*_restrictions for the submission port, to wit: [ master.cf ] submission inet n - n - - smtpd -o smtpd_tls_auth_only=yes -o smtpd_sasl_auth_enable=yes These two options are not set globally, but only for submission. -o smtpd_recipient_restrictions= This one is unset, to override the main.cf default. -o smtpd_relay_restrictions=$submission_relay_restrictions And this one is set to a non-standard name which is defined in the main.cf file. -o milter_macro_daemon_name=ORIGINATING -o syslog_name=postfix/submission (Also unset any other restrictions which are in use on port 25.) If you had any other smtpd_*_restrictions set in main.cf, they should be unset here just as was shown for smtpd_recipient_restrictions. Thanks for the tip. This is a good idea that I just attempted to implement based on some reading / research. Forgive the lack of knowledge in this particular field -- like your postscreen readme indicated, I'm attempting to walk before I run. :) Any gentle guidance on things to improve in this master.cf snippet would be definitely appreciated and humbly accepted. --8-- submission inet n - - - - smtpd Your chroot issues are between you and the Debian maintainer. I will have no part of it, thank you. :) -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt You did not override the main.cf settings I showed you above. smtps inet n - - - - smtpd -o syslog_name=postfix/smtps smtps is deprecated, and was never actually finalized as a protocol. Only old (and highly vulnerable) Microsoft clients need it, being unable to STARTTLS in submission. Those clients are not worth supporting. Tell your users to download Thunderbird. --8-- Look good? It was not what I said. snip reject_unauth_destination smtpd_relay_restrictions has this, so it's not needed here. OTOH perhaps you did need the permit_* restrictions you have omitted; everything here will also be applied to your own users: very wrong! Can you please clarify? Every smtpd_* postconf(5) setting you define in main.cf applies to every smtpd(8) instance you invoke from master.cf except where the master.cf command line explicitly overrides those settings. Did you test relaying with the settings in the OP? I'm guessing you did not. I omitted permit_* restrictions because I didn't think that they were necessary if a message passed all of the reject restrictions. Should I be explicitly defining a permit? If so, where and why? If you define an optional restriction stage (and with smtpd_relay_restrictions in Postix(sic)[1] 2.10 and later, smtpd_recipient_restrictions is optional), it is evaluated for every connection to every smtpd, unless as I mentioned a few times above, overridden in the master.cf command line. SMTPD_ACCESS_README.html#lists explains how this works. For a message to be accepted, every restriction stage must evaluate to a permit action. You have your permit_* restrictions in smtpd_relay_restrictions, but not in smtpd_recipient_restrictions. Therefore, relaying is forbidden by smtpd_recipient_restrictions. [1] Wietse, this is a typo in the man page at the end of postconf.5.html#smtpd_relay_restrictions -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
smtp restrictions
I was hoping someone could take a quick glance at my smtpd_*_restrictions configurations. While I've read and (re-)read the SMTPD_ACCESS_README file a few times over I would be greatly appreciative if someone could sanity check my work. The goal is, obviously, to (a) block spammers, (b) only allow relaying / sending to SASL-authorized users. --8-- smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated check_policy_service unix:private/policy-spf reject_unauth_destination smtpd_recipient_restrictions = reject_non_fqdn_sender reject_unknown_sender_domain reject_non_fqdn_recipient reject_unknown_recipient_domain reject_non_fqdn_hostname reject_invalid_hostname reject_unauth_destination reject_unauth_pipelining reject_rbl_client zen.spamhaus.org reject_rbl_client bl.spamcop.net reject_rbl_client cbl.abuseat.org reject_rbl_client dnsbl.njabl.org reject_rbl_client dnsbl.sorbs.net reject_rhsbl_sender dsn.rfc-ignorant.org reject_rhsbl_sender blackhole.securitysage.com --8-- An extra pair of eyes that could confirm things look good and things are as locked down as possible (both in terms of relaying *and* dealing with blacklisted IPs) would be greatly appreciated. Thanks!
Re: smtp restrictions
On Fri, 31 May 2013 00:43:51 -0400 James Zee jamesze...@gmail.com wrote: smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated check_policy_service unix:private/policy-spf reject_unauth_destination check_policy_service must be after reject_unauth_destination. http://www.howtoforge.com/postfix_spf
