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

policy daemon failure

Expand Messages
  • steve@...
    Hi We use sqlgrey as a policy daemon for greylisting. It runs on both our mail servers with a shared database on one of them. If the database is unavailable
    Message 1 of 12 , Jun 2, 2014
    • 0 Attachment

      Hi

      We use sqlgrey as a policy daemon for greylisting. It runs on both our mail servers with a shared database on one of them. If the database is unavailable for some reason on the main server the backup rejects mail with "451 4.3.5 Server configuration problem" Is it possible to change the default to accept the mail if the policy daemon fails. Most of our users would prefer a bit of extra spam to losing genuine mail.

      Thanks

      steve

    • lists@rhsoft.net
      ... you *do not* lose anything 451 is a *temporary* error 5xx would be a complete reject please learn how email works
      Message 2 of 12 , Jun 2, 2014
      • 0 Attachment
        Am 02.06.2014 17:11, schrieb steve@...:
        > We use sqlgrey as a policy daemon for greylisting. It runs on both our mail servers with a shared database on one
        > of them. If the database is unavailable for some reason on the main server the backup rejects mail with "451 4.3.5
        > Server configuration problem" Is it possible to change the default to accept the mail if the policy daemon fails.
        > Most of our users would prefer a bit of extra spam to losing genuine mail.

        you *do not* lose anything

        451 is a *temporary* error
        5xx would be a complete reject

        please learn how email works
      • Viktor Dukhovni
        ... The place to apply such logic is in the policy server itself. Postfix should not second-guess the policy server verdict. As noted by others 4XX is not a
        Message 3 of 12 , Jun 2, 2014
        • 0 Attachment
          On Mon, Jun 02, 2014 at 04:11:27PM +0100, steve@... wrote:

          > We use sqlgrey as a policy daemon for greylisting. It runs on
          > both our mail servers with a shared database on one of them. If the
          > database is unavailable for some reason on the main server the backup
          > rejects mail with "451 4.3.5 Server configuration problem" Is it
          > possible to change the default to accept the mail if the policy daemon
          > fails. Most of our users would prefer a bit of extra spam to losing
          > genuine mail.

          The place to apply such logic is in the policy server itself.
          Postfix should not second-guess the policy server verdict.

          As noted by others 4XX is not a permanent error, the sending system
          should retry the delivery.

          --
          Viktor.
        • steve@...
          ... *temporary* error ... Yes, but many mails rejected in an incident this morning haven t been resent. I guess we re dealing with broken clients. Steve ...
          Message 4 of 12 , Jun 2, 2014
          • 0 Attachment

            >
            > you *do not* lose anything
            >
            > 451 is a
            *temporary* error
            > 5xx would be a complete reject

            Yes, but many mails rejected in an incident this morning haven't been resent. I guess we're dealing with broken clients.

            Steve

          • Robert Schetterer
            ... perhaps, but this is not your problem, the sender has to fix it, some more workaround may use greylist more selective like perhaps read
            Message 5 of 12 , Jun 2, 2014
            • 0 Attachment
              Am 02.06.2014 18:05, schrieb steve@...:
              >>
              >> you *do not* lose anything
              >>
              >> 451 is a *temporary* error
              >> 5xx would be a complete reject
              >>
              >
              > Yes, but many mails rejected in an incident this morning haven't been
              > resent. I guess we're dealing with broken clients.

              perhaps, but this is not "your" problem, the sender has to fix it,
              some more workaround may use greylist more selective like

              perhaps read

              https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit-smtpd_restriction_classes/

              sorry german, but setup should speak for its own

              >
              > Steve
              >



              Best Regards
              MfG Robert Schetterer

              --
              [*] sys4 AG

              http://sys4.de, +49 (89) 30 90 46 64
              Franziskanerstraße 15, 81669 München

              Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
              Vorstand: Patrick Ben Koetter, Marc Schiffbauer
              Aufsichtsratsvorsitzender: Florian Kirstein
            • Микаел Бак
              Hi ... Maybe you should consider having a master db on one of the mail servers and a slave db on the other one and have the data be replicated to the slave
              Message 6 of 12 , Jun 3, 2014
              • 0 Attachment
                Hi

                On 06/02/2014 05:11 PM, steve@... wrote:
                > Hi
                >
                > We use sqlgrey as a policy daemon for greylisting. It runs on both our
                > mail servers with a shared database on one of them. If the database is
                > unavailable for some reason on the main server the backup rejects mail
                > with "451 4.3.5 Server configuration problem" Is it possible to change
                > the default to accept the mail if the policy daemon fails. Most of our
                > users would prefer a bit of extra spam to losing genuine mail.
                >

                Maybe you should consider having a master db on one of the mail servers
                and a slave db on the other one and have the data be replicated to the
                slave automatically.
                This way you can minimize the risk to have either mail server to reject
                email just because the to servers aren't connected.

                Setting up mysql replication is of course off topic here.

                HTH,
                Mikael
              • Jeffrey 'jf' Lim
                ... resent. I guess we re dealing with broken clients. ... What sort of broken clients are these that don t use real email servers, and how do you know they
                Message 7 of 12 , Jun 3, 2014
                • 0 Attachment


                  On Jun 3, 2014 12:06 AM, <steve@...> wrote:
                  >
                  > >
                  > > you *do not* lose anything
                  > >
                  > > 451 is a *temporary* error
                  > > 5xx would be a complete reject
                  > > 
                  >
                  > Yes, but many mails rejected in an incident this morning haven't been resent. I guess we're dealing with broken clients.
                  >

                  What sort of "broken" clients are these that don't use real email servers, and how do you know they are broken? They could very well be waiting for some time to pass before retrying again (and there is some kind of a system for these intervals. It's not as if the standard protocol is to resend all of your undelivered email every 5 minutes...)

                  -jf

                • steve@...
                  ... use real email servers, ... They could very well be waiting for ... retrying again (and there is some kind of a ... these intervals. It s not as if the
                  Message 8 of 12 , Jun 3, 2014
                  • 0 Attachment


                    > What sort of "broken" clients are these that don't
                    use real email servers,
                    > and how do you know they are broken? They could very well be waiting for
                    > some time to pass before retrying again (and there is some kind of a
                    > system
                    > for these intervals. It's not as if the standard protocol is to resend all
                    > of your undelivered email every 5 minutes...)
                     

                    After 24 hours the missing mail still hasnt arrived. So they must have a very long retry period!

                    Steve

                  • D'Arcy J.M. Cain
                    On Tue, 03 Jun 2014 11:17:07 +0200 ... Since both servers need to write to the database as well the slave is still dependent on the master. They both need to
                    Message 9 of 12 , Jun 3, 2014
                    • 0 Attachment
                      On Tue, 03 Jun 2014 11:17:07 +0200
                      Микаел Бак <mikael.bak@...> wrote:
                      > Maybe you should consider having a master db on one of the mail
                      > servers and a slave db on the other one and have the data be
                      > replicated to the slave automatically.

                      Since both servers need to write to the database as well the slave is
                      still dependent on the master. They both need to be masters with some
                      scheme to pass updates between them. I have done this for a world-wide
                      financial system that required thousands of "masters" but it was quite
                      tricky. A better option might be to simply have two databases and let
                      both of them build from mail that hits them. It might slow down a few
                      emails but if all you have are two mail servers this may be acceptable.

                      --
                      D'Arcy J.M. Cain
                      System Administrator, Vex.Net
                      http://www.Vex.Net/ IM:darcy@...
                      VoIP: sip:darcy@...
                    • lists@rhsoft.net
                      ... what are you discussing here? * the SMTP protocol specifies temporary and permanent errors * in case of temporary the client MUST retry * if it does not
                      Message 10 of 12 , Jun 3, 2014
                      • 0 Attachment
                        Am 03.06.2014 11:39, schrieb steve@...:
                        >> What sort of "broken" clients are these that don't use real email servers,
                        >> and how do you know they are broken? They could very well be waiting for
                        >> some time to pass before retrying again (and there is some kind of a
                        >> system
                        >> for these intervals. It's not as if the standard protocol is to resend all
                        >> of your undelivered email every 5 minutes...)
                        >
                        > After 24 hours the missing mail still hasnt arrived. So they must have a very long retry period!

                        what are you discussing here?

                        * the SMTP protocol specifies temporary and permanent errors
                        * in case of temporary the client MUST retry
                        * if it does not it's broken and not your problem
                        * if it does the retry period is the senders business
                        * typically each retry adds more time before try again
                        * the frist retry normally is within minutes

                        it is *not* your problem if the sender is broken
                        in that case he is *not* only broken in case of mails to you

                        if the sender don't respect 4xx repsones he has *massive*
                        problems all over the world when the destination is using
                        greylisting because greylisting *by definition* always
                        rejetcs the first delivery with a 4xx response just because
                        it catchs any non-MTA and spam zombies

                        so don't waste your time
                        solve *your* problems and not the ones of other people

                        it's the problem of the sender to *shout at his* server admin
                        why he has a non working MTA or re-consider using a MTA at
                        all instead of broken software try to deliver only once

                        the sender MUST NOT expect that every delivery is successful
                        at the first try because that's not how the internet is
                        supposed to work - internet services are supposed to deal
                        with temporary problems and SMTP is *well desigend* to handle
                        that perfectly
                      • Микаел Бак
                        Hi, ... Yes, you are right! Next time I will think before I post :-) Mikael
                        Message 11 of 12 , Jun 3, 2014
                        • 0 Attachment
                          Hi,

                          On 06/03/2014 11:42 AM, D'Arcy J.M. Cain wrote:
                          > On Tue, 03 Jun 2014 11:17:07 +0200
                          > Микаел Бак <mikael.bak@...> wrote:
                          >> Maybe you should consider having a master db on one of the mail
                          >> servers and a slave db on the other one and have the data be
                          >> replicated to the slave automatically.
                          >
                          > Since both servers need to write to the database as well the slave is
                          > still dependent on the master. They both need to be masters with some
                          > scheme to pass updates between them. I have done this for a world-wide
                          > financial system that required thousands of "masters" but it was quite
                          > tricky. A better option might be to simply have two databases and let
                          > both of them build from mail that hits them. It might slow down a few
                          > emails but if all you have are two mail servers this may be acceptable.
                          >

                          Yes, you are right!
                          Next time I will think before I post :-)

                          Mikael
                        • Bernhard Schmidt
                          Hi Steve, ... While agreeing on the arguments the other responders have raised we are using the hapolicy script from postfwd to deal with broken Policy
                          Message 12 of 12 , Jun 3, 2014
                          • 0 Attachment
                            Hi Steve,

                            >
                            > We use sqlgrey as a policy daemon for greylisting. It runs on both our
                            > mail servers with a shared database on one of them. If the database is
                            > unavailable for some reason on the main server the backup rejects mail
                            > with "451 4.3.5 Server configuration problem" Is it possible to change
                            > the default to accept the mail if the policy daemon fails. Most of our
                            > users would prefer a bit of extra spam to losing genuine mail.

                            While agreeing on the arguments the other responders have raised we are
                            using the hapolicy script from postfwd to deal with broken Policy
                            servers, i.e. for dovecot quota-status requests to the message stores.

                            http://postfwd.org/hapolicy/index.html

                            Works very well, the only disadvantage is that it uses quite a bit of
                            memory due to spawning a full perl interpreter for each lookup process.
                            A daemon that forks on accept() would probably be a lot more
                            memory-saving, but it would be another part that could be broken.

                            Bernhard
                          Your message has been successfully submitted and would be delivered to recipients shortly.