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

Re: Integration of content filter in master.cf

Expand Messages
  • Titanus Eramius
    Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones ... OK, but using submission more or less removes the problem with SpamAssassin. Thank you for the pointer,
    Message 1 of 15 , Jan 8, 2013
      Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones
      <njones@...>:

      > On 1/8/2013 10:47 AM, Titanus Eramius wrote:
      > > I'm a little unsure about best practice here, hence the question.
      > >
      > > Running /usr/sbin/spamd from the SpamAssassin package to scan mail,
      > > I've integrated it into /etc/postfix/master.cf with the following
      > > lines
      > > ---
      > > smtp inet n - n - - smtpd -o
      > > content_filter=spamassassin
      > > ...
      > > spamassassin unix - n n - - pipe
      > > flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
      > > -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
      > > ---
      > >
      > > And then in /etc/postfix/main.cf there's added the line
      > > ---
      > > spamassassin_destination_recipient_limit = 1
      > > ---
      > >
      > > However, this scans both incoming and outgoing mail, but for
      > > outgoing I plan on using rate-limiting to avoid spamming the net
      > > (to much), in case an account gets hacked.
      > >
      > > So I searched the web, and constructed this alternative to use in
      > > master.cf
      > > ---
      > > 26 inet n - n - - smtpd -o
      > > content_filter=spamassassin smtp inet n - n - - smtpd
      > > ---
      > >
      > > Using iptables, all incoming connections to port 25 could then be
      > > directed to port 26. The server only have one ip-address.
      > >
      > > The question then is, is this a practical solution, or can it be
      > > done smarter, for example with less work and without using
      > > iptables, or maybe some other way entirely?
      > >
      >
      > Using iptables to separate traffic is a reasonable solution.
      > Probably a good idea to add a comment to master.cf documenting what
      > you've done.
      >
      > The more typical way to do this is for local mail to use the
      > submission port 587. Sometimes folks redirect port 25 on the local
      > network to 587 as a migration aid.
      >
      >
      >
      > -- Noel Jones

      OK, but using submission more or less removes the problem with
      SpamAssassin. Thank you for the pointer, I'll be sure to use 587
      for relaying from the users.

      This raises the question (or at least I think it do), if it's
      possible to "force" the users onto 587 by denying relay access to 25?
    • Titanus Eramius
      Tue, 8 Jan 2013 20:29:30 +0100 skrev DTNX Postmaster : ... Thank you for the pointer on submission, I ll be sure to make use of it. But it
      Message 2 of 15 , Jan 8, 2013
        Tue, 8 Jan 2013 20:29:30 +0100 skrev DTNX Postmaster
        <postmaster@...>:

        ...

        > > The more typical way to do this is for local mail to use the
        > > submission port 587. Sometimes folks redirect port 25 on the local
        > > network to 587 as a migration aid.
        >
        >
        > This. Using the submission port is highly recommended, as it avoids
        > all kinds of trouble, such as access providers blocking port 25.
        >
        > It also allows you to tailor each service to its specific needs;
        > postscreen on 25, required authentication plus TLS and rate limiting
        > on 587, and so on.
        >
        > HTH,
        > Jona
        >

        Thank you for the pointer on submission, I'll be sure to make use of it.

        But it raises a question (like i wrote in the reply to Noel), and that
        is (as far as i know) that I need to ensure the use of 587 so users
        can't "go around" rate limiting on 587 by using 25 for relaying.

        Would such a thing be possible to do?
      • Reindl Harald
        ... it s more a human problem than a technically to force a large amount of users to change their for a long time wrong usage of port 25 submission inet
        Message 3 of 15 , Jan 8, 2013
          Am 08.01.2013 21:48, schrieb Titanus Eramius:
          > This raises the question (or at least I think it do), if it's
          > possible to "force" the users onto 587 by denying relay access to 25?

          it's more a human problem than a technically to force a large amount
          of users to change their for a long time wrong usage of port 25

          submission inet n - n - 50 smtpd -o smtpd_client_connection_count_limit=15 -o
          smtpd_client_connection_rate_limit=80 -o smtpd_sasl_auth_enable=yes -o smtpd_delay_reject=yes -o
          smtpd_client_restrictions=permit_sasl_authenticated,reject -o max_idle=1h -o max_use=500

          remove "permit_sasl_authenticated" at the same time from main.cf and you should
          be more or less done, but as said. how to explain all users that thheir config
          is wrong since the first day they are using it
        • Reindl Harald
          ... smtp inet n - n - 50 smtpd -o smtpd_client_connection_rate_limit=5 submission inet n - n -
          Message 4 of 15 , Jan 8, 2013
            Am 08.01.2013 22:03, schrieb Titanus Eramius:
            > But it raises a question (like i wrote in the reply to Noel), and that
            > is (as far as i know) that I need to ensure the use of 587 so users
            > can't "go around" rate limiting on 587 by using 25 for relaying.
            >
            > Would such a thing be possible to do?

            smtp inet n - n - 50 smtpd -o smtpd_client_connection_rate_limit=5

            submission inet n - n - 50 smtpd -o smtpd_client_connection_rate_limit=500
            -o smtpd_sasl_auth_enable=yes
            -o smtpd_delay_reject=yes
            -o smtpd_client_restrictions=permit_sasl_authenticated,reject
          • Titanus Eramius
            Tue, 08 Jan 2013 22:06:26 +0100 skrev Reindl Harald ... Thankfully I still have a few months before I start to have actual costumers, so this is my one chance
            Message 5 of 15 , Jan 8, 2013
              Tue, 08 Jan 2013 22:06:26 +0100 skrev Reindl Harald
              <h.reindl@...>:

              >
              >
              > Am 08.01.2013 21:48, schrieb Titanus Eramius:
              > > This raises the question (or at least I think it do), if it's
              > > possible to "force" the users onto 587 by denying relay access to
              > > 25?
              >
              > it's more a human problem than a technically to force a large amount
              > of users to change their for a long time wrong usage of port 25
              >
              > submission inet n - n - 50 smtpd
              > -o smtpd_client_connection_count_limit=15 -o
              > smtpd_client_connection_rate_limit=80 -o smtpd_sasl_auth_enable=yes
              > -o smtpd_delay_reject=yes -o
              > smtpd_client_restrictions=permit_sasl_authenticated,reject -o
              > max_idle=1h -o max_use=500
              >
              > remove "permit_sasl_authenticated" at the same time from main.cf and
              > you should be more or less done, but as said. how to explain all
              > users that thheir config is wrong since the first day they are using
              > it
              >

              Thankfully I still have a few months before I start to have actual
              costumers, so this is my one chance to avoid some of the common
              problems.
              But I suspect you might be right with 587 anyway, because at least this
              client (Claws Mail) uses 25 as the standard port when sending through
              POP.

              Thank you for the example to deactivate client relaying through 25.

              I think this solves my problem, so thanks again for the replies.
            • Noel Jones
              ... It s certainly possible to prevent relaying via port 25, and many sites do so. The choice is a local policy decision; do what fits your needs best.
              Message 6 of 15 , Jan 8, 2013
                On 1/8/2013 2:48 PM, Titanus Eramius wrote:
                > Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones

                >> Using iptables to separate traffic is a reasonable solution.
                >> Probably a good idea to add a comment to master.cf documenting what
                >> you've done.
                >>
                >> The more typical way to do this is for local mail to use the
                >> submission port 587. Sometimes folks redirect port 25 on the local
                >> network to 587 as a migration aid.
                >>
                >
                > OK, but using submission more or less removes the problem with
                > SpamAssassin. Thank you for the pointer, I'll be sure to use 587
                > for relaying from the users.
                >
                > This raises the question (or at least I think it do), if it's
                > possible to "force" the users onto 587 by denying relay access to 25?
                >

                It's certainly possible to prevent relaying via port 25, and many
                sites do so.

                The choice is a local policy decision; do what fits your needs best.

                Typically this is done by giving submission and port 25 different
                settings via master.cf -o ... overrides.

                A quick incomplete example:

                # main.cf
                mynetworks = 127.0.0.1
                submission_mynetworks = 127.0.0.1, 192.168.0.0/16
                smtpd_recipient_restrictions =
                permit_mynetworks
                reject_unauth_destination
                ... anti-spam controls ...
                submission_smtpd_recipient_restrictions =
                permit_mynetworks
                permit_sasl_authenticated
                reject

                # master.cf
                submission inet n - n - - smtpd
                -o syslog_name=postfix/submission
                -o mynetworks=$submission_mynetworks
                -o
                smtpd_recipient_restrictions=$submission_smtpd_recipient_restrictions
                ... more -o overrides ...


                Common variations are to require sasl AUTH on the submission port by
                removing permit_mynetworks, and to require TLS with AUTH by using
                "-o smtpd_tls_auth_only=yes".


                -- Noel Jones
              • Titanus Eramius
                Tue, 08 Jan 2013 15:54:41 -0600 skrev Noel Jones : ... Thank you for the additional information, it s very helpful in the understanding
                Message 7 of 15 , Jan 8, 2013
                  Tue, 08 Jan 2013 15:54:41 -0600 skrev Noel Jones
                  <njones@...>:

                  ...

                  > > This raises the question (or at least I think it do), if it's
                  > > possible to "force" the users onto 587 by denying relay access to
                  > > 25?
                  > >
                  >
                  > It's certainly possible to prevent relaying via port 25, and many
                  > sites do so.
                  >
                  > The choice is a local policy decision; do what fits your needs best.
                  >
                  > Typically this is done by giving submission and port 25 different
                  > settings via master.cf -o ... overrides.
                  >
                  > A quick incomplete example:
                  >
                  > # main.cf
                  > mynetworks = 127.0.0.1
                  > submission_mynetworks = 127.0.0.1, 192.168.0.0/16
                  > smtpd_recipient_restrictions =
                  > permit_mynetworks
                  > reject_unauth_destination
                  > ... anti-spam controls ...
                  > submission_smtpd_recipient_restrictions =
                  > permit_mynetworks
                  > permit_sasl_authenticated
                  > reject
                  >
                  > # master.cf
                  > submission inet n - n - - smtpd
                  > -o syslog_name=postfix/submission
                  > -o mynetworks=$submission_mynetworks
                  > -o
                  > smtpd_recipient_restrictions=$submission_smtpd_recipient_restrictions
                  > ... more -o overrides ...
                  >
                  >
                  > Common variations are to require sasl AUTH on the submission port by
                  > removing permit_mynetworks, and to require TLS with AUTH by using
                  > "-o smtpd_tls_auth_only=yes".
                  >
                  >
                  > -- Noel Jones

                  Thank you for the additional information, it's very helpful in the
                  understanding of Postfix. I've had some trouble seeing the difference
                  between -o overrides in main.cf and master.cf, but this really helps.
                • Noel Jones
                  ... main.cf parameters are used by all postfix services (but not all parameters apply to all services). Individual services defined in master.cf can override
                  Message 8 of 15 , Jan 8, 2013
                    On 1/8/2013 4:11 PM, Titanus Eramius wrote:

                    > I've had some trouble seeing the difference
                    > between -o overrides in main.cf and master.cf, but this really helps.
                    >


                    main.cf parameters are used by all postfix services (but not all
                    parameters apply to all services).

                    Individual services defined in master.cf can override main.cf
                    settings with -o ... options.

                    http://www.postfix.org/postconf.5.html
                    http://www.postfix.org/master.5.html




                    -- Noel Jones
                  • mouss
                    ... fix the problem at the source: force the client to do the work: use different services for different uses: [MX service] port: 25 example DNS name:
                    Message 9 of 15 , Jan 8, 2013
                      Le 08/01/2013 21:48, Titanus Eramius a écrit :
                      > Tue, 08 Jan 2013 12:39:58 -0600 skrev Noel Jones
                      > <njones@...>:
                      >
                      >> On 1/8/2013 10:47 AM, Titanus Eramius wrote:
                      >>> I'm a little unsure about best practice here, hence the question.
                      >>>
                      >>> Running /usr/sbin/spamd from the SpamAssassin package to scan mail,
                      >>> I've integrated it into /etc/postfix/master.cf with the following
                      >>> lines
                      >>> ---
                      >>> smtp inet n - n - - smtpd -o
                      >>> content_filter=spamassassin
                      >>> ...
                      >>> spamassassin unix - n n - - pipe
                      >>> flags=Rq user=spamd argv=/usr/bin/spamc -u ${user}@${domain}
                      >>> -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}
                      >>> ---
                      >>>
                      >>> And then in /etc/postfix/main.cf there's added the line
                      >>> ---
                      >>> spamassassin_destination_recipient_limit = 1
                      >>> ---
                      >>>
                      >>> However, this scans both incoming and outgoing mail, but for
                      >>> outgoing I plan on using rate-limiting to avoid spamming the net
                      >>> (to much), in case an account gets hacked.
                      >>>
                      >>> So I searched the web, and constructed this alternative to use in
                      >>> master.cf
                      >>> ---
                      >>> 26 inet n - n - - smtpd -o
                      >>> content_filter=spamassassin smtp inet n - n - - smtpd
                      >>> ---
                      >>>
                      >>> Using iptables, all incoming connections to port 25 could then be
                      >>> directed to port 26. The server only have one ip-address.
                      >>>
                      >>> The question then is, is this a practical solution, or can it be
                      >>> done smarter, for example with less work and without using
                      >>> iptables, or maybe some other way entirely?
                      >>>
                      >> Using iptables to separate traffic is a reasonable solution.
                      >> Probably a good idea to add a comment to master.cf documenting what
                      >> you've done.
                      >>
                      >> The more typical way to do this is for local mail to use the
                      >> submission port 587. Sometimes folks redirect port 25 on the local
                      >> network to 587 as a migration aid.
                      >>
                      >>
                      >>
                      >> -- Noel Jones
                      > OK, but using submission more or less removes the problem with
                      > SpamAssassin. Thank you for the pointer, I'll be sure to use 587
                      > for relaying from the users.
                      >
                      > This raises the question (or at least I think it do), if it's
                      > possible to "force" the users onto 587 by denying relay access to 25?

                      fix the problem at the source: force the client to do the work:
                      use different services for different uses:

                      [MX service]
                      port: 25
                      example DNS name: mx01.example.com
                      => no relay
                      virus and spam filtering...



                      [submission service]
                      example DNS name: smtp01.example.com
                      port 587. if this is hard, port 25 with a specific IP is ok.
                      SASL auth. when not desirable, IP based access control (thoug this may
                      be implemented outside of postfix, such as on a firewall)
                      virus filtering
                      rate limit and custom checks as needed.

                      [reverse MX]
                      example DNS name: mailrelay01.example.com
                      in small setups, this could be the same service as the submission one.
                      in larger setups, make this dedicated. it'll take the complexity of mail
                      routing and "caching" (retry).

                      ...
                    • Titanus Eramius
                      Tue, 08 Jan 2013 16:24:11 -0600 skrev Noel Jones ... Sorry for the delayed answer, it took some time to adjust the server to match the advices I got, but
                      Message 10 of 15 , Jan 16, 2013
                        Tue, 08 Jan 2013 16:24:11 -0600 skrev Noel Jones
                        <njones@...>:

                        > On 1/8/2013 4:11 PM, Titanus Eramius wrote:
                        >
                        > > I've had some trouble seeing the difference
                        > > between -o overrides in main.cf and master.cf, but this really
                        > > helps.
                        > >
                        >
                        >
                        > main.cf parameters are used by all postfix services (but not all
                        > parameters apply to all services).
                        >
                        > Individual services defined in master.cf can override main.cf
                        > settings with -o ... options.
                        >
                        > http://www.postfix.org/postconf.5.html
                        > http://www.postfix.org/master.5.html
                        >
                        >
                        >
                        >
                        > -- Noel Jones

                        Sorry for the delayed answer, it took some time to adjust the server to
                        match the advices I got, but everything seems to run better than ever,
                        so thanks for the help again.

                        Some day one really ought to read the entire postconf(5) manual to get a
                        sense of what Postfix is capable of, but so far I've only read about the
                        settings I use.

                        If I may ask one last thing, just to be sure.
                        To integrate SpamAssassin I adjusted the smtp-line in master.cf to
                        ---
                        smtp inet n - - - - smtpd -o content_filter=spamassassin
                        ---

                        and then disallowed submission on port 25.

                        In main.cf I have 7 reject_*-lines like so
                        ---
                        smtpd_recipient_restrictions =
                        ...
                        reject_invalid_helo_hostname
                        reject_unknown_sender_domain
                        ...
                        permit
                        ---

                        Will the reject_*-rules still apply to incoming mail before Postfix
                        hands it over to SpamAssassin?
                      • Titanus Eramius
                        ... Thank you for the insights, together with a subdomain to the Dovecot IMAP service they have all been implemented so I later may split the services to
                        Message 11 of 15 , Jan 16, 2013
                          Tue, 08 Jan 2013 23:59:31 +0100 skrev mouss <mouss@...>:

                          > > This raises the question (or at least I think it do), if it's
                          > > possible to "force" the users onto 587 by denying relay access to
                          > > 25?
                          >
                          > fix the problem at the source: force the client to do the work:
                          > use different services for different uses:
                          >
                          > [MX service]
                          > port: 25
                          > example DNS name: mx01.example.com
                          > => no relay
                          > virus and spam filtering...
                          >
                          > [submission service]
                          > example DNS name: smtp01.example.com
                          > port 587. if this is hard, port 25 with a specific IP is ok.
                          > SASL auth. when not desirable, IP based access control (thoug this may
                          > be implemented outside of postfix, such as on a firewall)
                          > virus filtering
                          > rate limit and custom checks as needed.
                          >
                          > [reverse MX]
                          > example DNS name: mailrelay01.example.com
                          > in small setups, this could be the same service as the submission one.
                          > in larger setups, make this dedicated. it'll take the complexity of
                          > mail routing and "caching" (retry).
                          >
                          > ...
                          >

                          Thank you for the insights, together with a subdomain to the Dovecot
                          IMAP service they have all been implemented so I later may split the
                          services to multiple servers.

                          However I'm not sure I understand the reverse MX part very well,
                          perhaps I could trouble you for a link where I could do some reading on
                          the subject?
                        • Noel Jones
                          ... The -o content_filter... setting on smtpd will override any main.cf content_filter setting, all other main.cf smtpd settings still apply. So yes, your
                          Message 12 of 15 , Jan 16, 2013
                            On 1/16/2013 3:13 AM, Titanus Eramius wrote:
                            > Tue, 08 Jan 2013 16:24:11 -0600 skrev Noel Jones
                            > <njones@...>:
                            >
                            >> main.cf parameters are used by all postfix services (but not all
                            >> parameters apply to all services).
                            >>
                            >> Individual services defined in master.cf can override main.cf
                            >> settings with -o ... options.
                            >>
                            >> http://www.postfix.org/postconf.5.html
                            >> http://www.postfix.org/master.5.html
                            >>
                            >>
                            >>
                            >>
                            >> -- Noel Jones
                            >
                            > If I may ask one last thing, just to be sure.
                            > To integrate SpamAssassin I adjusted the smtp-line in master.cf to
                            > ---
                            > smtp inet n - - - - smtpd -o content_filter=spamassassin
                            > ---
                            >
                            > and then disallowed submission on port 25.
                            >
                            > In main.cf I have 7 reject_*-lines like so
                            > ---
                            > smtpd_recipient_restrictions =
                            > ...
                            > reject_invalid_helo_hostname
                            > reject_unknown_sender_domain
                            > ...
                            > permit
                            > ---
                            >
                            > Will the reject_*-rules still apply to incoming mail before Postfix
                            > hands it over to SpamAssassin?
                            >


                            The "-o content_filter..." setting on smtpd will override any
                            main.cf content_filter setting, all other main.cf smtpd settings
                            still apply.

                            So yes, your main.cf smtpd_recipient_restrictions will still apply.





                            -- Noel Jones
                          Your message has been successfully submitted and would be delivered to recipients shortly.