Loading ...
Sorry, an error occurred while loading the content.
 

smtp restrictions

Expand Messages
  • James Zee
    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
    Message 1 of 11 , May 30, 2013
      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!
    • lists@...
      On Fri, 31 May 2013 00:43:51 -0400 ... check_policy_service must be after reject_unauth_destination. http://www.howtoforge.com/postfix_spf
      Message 2 of 11 , May 30, 2013
        On Fri, 31 May 2013 00:43:51 -0400
        James Zee <jameszee13@...> 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
      • Stan Hoeppner
        ... 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
        Message 3 of 11 , May 30, 2013
          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
        • Mikael Bak
          Stan, ... 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
          Message 4 of 11 , May 31, 2013
            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
          • Stan Hoeppner
            ... Long ago I shared this sentiment, until Wietse made it very clear to me that we don t do this here. ... Surely you don t believe I would attempt to
            Message 5 of 11 , May 31, 2013
              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
            • Charles Marcus
              ... 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
              Message 6 of 11 , May 31, 2013
                On 2013-05-31 6:04 AM, Stan Hoeppner <stan@...> 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
              • /dev/rob0
                ... If you have smtpd_relay_restrictions, you have postscreen. Consider postscreen in addition to the spam control restrictions below. ... As was indicated
                Message 7 of 11 , May 31, 2013
                  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:
                • Wietse Venema
                  ... To place the quote in context: ... Meanwhile the postconf command has evolved such that it will warn about unused/undefined parameter settings in main.cf
                  Message 8 of 11 , May 31, 2013
                    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
                  • James Zee
                    ... 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
                    Message 9 of 11 , May 31, 2013
                      On Fri, May 31, 2013 at 8:09 AM, /dev/rob0 <rob0@...> 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.
                    • /dev/rob0
                      ... snip ... These two options are not set globally, but only for submission. ... This one is unset, to override the main.cf default. ... And this one is set
                      Message 10 of 11 , May 31, 2013
                        On Fri, May 31, 2013 at 11:15:05AM -0400, James Zee wrote:
                        > On Fri, May 31, 2013 at 8:09 AM, /dev/rob0 <rob0@...> 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:
                      • Benny Pedersen
                        ... 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
                        Message 11 of 11 , Jun 3 6:52 AM
                          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
                        Your message has been successfully submitted and would be delivered to recipients shortly.