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

Re: Mail backup for malfunctioning MTA

Expand Messages
  • Melvyn Sopacua
    ... The problem is that postfix will see success initially: - client sends - postfix receives - postfix relays, gets OK ... - exchange checks quota, decides
    Message 1 of 15 , Jan 31, 2009
    • 0 Attachment
      On Saturday 31 January 2009 06:49:28 Terry Carmen wrote:
      > Melvyn Sopacua wrote:
      > > The reason is that a client has unsolved ongoing configuration issues
      > > with their Exchange server and can no longer afford to loose mail because
      > > of it. The Exchange server is not my problem(tm).
      > >
      > > . . .
      > >
      > > 4) Magically catch the accepted mail that bounces after completed
      > > transaction (mailbox is full primarily. Spoof MAIL FROM: dialog?)
      >
      > If you're saying that exchange is losing the mail, the easiest fix is to
      > configure postfix as a relayhost between the outside world and the
      > broken exchange server. Postfix will queue the mail and send it to the
      > exchange server as quickly as possible and if the exchange server is
      > down, it will wait until it's back up again.

      The problem is that postfix will see "success" initially:

      - client sends
      - postfix receives
      - postfix relays, gets OK
      ----> postfix deletes queued message
      - exchange checks quota, decides mailbox is full
      - exchange sends DSN to client

      Worst case, client just spent 30 minutes on dial-up trying to send his 10MB in
      images my client needs.

      --
      Melvyn Sopacua
      mdev@...

      FreeBSD 7.1-STABLE
      Qt: 3.3.8
      KDE: 3.5.10
    • Wietse Venema
      ... Use reject_unverified_recipient, with a persistent database. This will check the Exchange response BEFORE accepting mail, and will avoid hammering the
      Message 2 of 15 , Jan 31, 2009
      • 0 Attachment
        Melvyn Sopacua:
        > The problem is that postfix will see "success" initially:
        >
        > - client sends
        > - postfix receives
        > - postfix relays, gets OK
        > ----> postfix deletes queued message
        > - exchange checks quota, decides mailbox is full
        > - exchange sends DSN to client

        Use reject_unverified_recipient, with a persistent database. This
        will check the Exchange response BEFORE accepting mail, and will
        avoid hammering the Exchange server with repeated requests.

        http://www.postfix.org/ADDRESS_VERIFICATION_README.html

        Wietse
      • Sahil Tandon
        ... Yes, http://www.postfix.org/postconf.5.html#soft_bounce. ... Hm, and where is this access map syntax documented? -- Sahil Tandon
        Message 3 of 15 , Jan 31, 2009
        • 0 Attachment
          On Sat, 31 Jan 2009, Melvyn Sopacua wrote:

          > On Friday 30 January 2009 21:12:30 Victor Duchovni wrote:
          > > On Fri, Jan 30, 2009 at 08:42:22PM -0900, Melvyn Sopacua wrote:
          > > > 1) Accept mail for example.com as primary MX (yes, possible)
          > > > 2) Relay to mx2.example.com (yes, possible)
          > > > 3) If mx2.example.com gives fatal error, reduce to transient and try
          > > > again later (not sure if relay -o soft_bounce=yes would cover it)
          > >
          > > This also will work.
          >
          > So to confirm, relay -o soft_bounce=yes in master.cf will reduce any 5xx
          > replies it receives from the exchange server to 4xx?

          Yes, http://www.postfix.org/postconf.5.html#soft_bounce.

          > > > 4) Magically catch the accepted mail that bounces after completed
          > > > transaction (mailbox is full primarily. Spoof MAIL FROM: dialog?)
          > >
          > > This is getting too "creative". Probably easier to deliver a Bcc stream
          > > of the mail, and provide access to missed mail on demand.
          >
          > Yes, I'm thinking this too. But I'd like to have a log mailed to them (a
          > seperate account that's not touched by exchange) via cron, so they can see
          > subjects and senders, so I will probably create a 'backup' service in
          > master.cf that does all the stuff. It would be equivalent to an alias like
          > this:
          >
          > @... localmailbox, |logthis, relay:[mx2.example.com]

          Hm, and where is this access map syntax documented?

          --
          Sahil Tandon <sahil@...>
        • Melvyn Sopacua
          ... No where, it s pseudo code to explain what my backup service would do. -- Melvyn Sopacua
          Message 4 of 15 , Jan 31, 2009
          • 0 Attachment
            On Saturday 31 January 2009 08:21:56 Sahil Tandon wrote:
            > On Sat, 31 Jan 2009, Melvyn Sopacua wrote:

            > > @... localmailbox, |logthis, relay:[mx2.example.com]
            >
            > Hm, and where is this access map syntax documented?

            No where, it's pseudo code to explain what my 'backup' service would do.

            --
            Melvyn Sopacua
          • Melvyn Sopacua
            ... VRFY info@example.com 252 2.1.5 Cannot VRFY user, but will take message for yet, mailbox is full and DSN will come few seconds after
            Message 5 of 15 , Jan 31, 2009
            • 0 Attachment
              On Saturday 31 January 2009 08:03:17 Wietse Venema wrote:
              > Melvyn Sopacua:
              > > The problem is that postfix will see "success" initially:
              > >
              > > - client sends
              > > - postfix receives
              > > - postfix relays, gets OK
              > > ----> postfix deletes queued message
              > > - exchange checks quota, decides mailbox is full
              > > - exchange sends DSN to client
              >
              > Use reject_unverified_recipient, with a persistent database. This
              > will check the Exchange response BEFORE accepting mail, and will
              > avoid hammering the Exchange server with repeated requests.
              >
              > http://www.postfix.org/ADDRESS_VERIFICATION_README.html


              VRFY info@...
              252 2.1.5 Cannot VRFY user, but will take message for <info@...>

              yet, mailbox is full and DSN will come few seconds after mail is accepted.
              Judging from the 2xx response, this means to postfix that VRFY succeeded, so
              the problem persists.
              --
              Melvyn Sopacua
              mdev@...

              FreeBSD 7.1-STABLE
              Qt: 3.3.8
              KDE: 3.5.10
            • Terry Carmen
              ... This is a classic example of trying to fix a people problem using technology. Exchange is broken. It is accepting then losing messages that it can t
              Message 6 of 15 , Jan 31, 2009
              • 0 Attachment
                Melvyn Sopacua wrote:
                > On Saturday 31 January 2009 08:03:17 Wietse Venema wrote:
                >
                >> Melvyn Sopacua:
                >>
                >>> The problem is that postfix will see "success" initially:
                >>>
                >>> - client sends
                >>> - postfix receives
                >>> - postfix relays, gets OK
                >>> ----> postfix deletes queued message
                >>> - exchange checks quota, decides mailbox is full
                >>> - exchange sends DSN to client
                >>>
                >> Use reject_unverified_recipient, with a persistent database. This
                >> will check the Exchange response BEFORE accepting mail, and will
                >> avoid hammering the Exchange server with repeated requests.
                >>
                >> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
                > VRFY info@...
                > 252 2.1.5 Cannot VRFY user, but will take message for <info@...>
                >
                > yet, mailbox is full and DSN will come few seconds after mail is accepted.
                > Judging from the 2xx response, this means to postfix that VRFY succeeded, so
                > the problem persists.
                >
                This is a classic example of trying to fix a people problem using
                technology. Exchange is broken. It is accepting then losing messages
                that it can't deliver. You are not the exchange admin, so you can't fix it.

                The next time someone complains, show them the postfix log entry where
                Exchange accepted the message from Postfix, then suggest they go talk to
                the Exchange admin.

                If you persist in trying to fix Exchange from the outside, you will have
                accepted responsibility (and later, blame) for a problem that you can't
                fix and in the end, you'll be in trouble or fired and the Exchange admin
                will claim no responsibility or knowledge of the situation.

                Terry
              • Wietse Venema
                ... POSTFIX DOES NOT USE THE VRFY COMMAND.
                Message 7 of 15 , Jan 31, 2009
                • 0 Attachment
                  Melvyn Sopacua:
                  > On Saturday 31 January 2009 08:03:17 Wietse Venema wrote:
                  > > Melvyn Sopacua:
                  > > > The problem is that postfix will see "success" initially:
                  > > >
                  > > > - client sends
                  > > > - postfix receives
                  > > > - postfix relays, gets OK
                  > > > ----> postfix deletes queued message
                  > > > - exchange checks quota, decides mailbox is full
                  > > > - exchange sends DSN to client
                  > >
                  > > Use reject_unverified_recipient, with a persistent database. This
                  > > will check the Exchange response BEFORE accepting mail, and will
                  > > avoid hammering the Exchange server with repeated requests.
                  > >
                  > > http://www.postfix.org/ADDRESS_VERIFICATION_README.html
                  >
                  >
                  > VRFY info@...
                  > 252 2.1.5 Cannot VRFY user, but will take message for <info@...>

                  POSTFIX DOES NOT USE THE VRFY COMMAND.
                • Melvyn Sopacua
                  ... Aha, actual probe messages. Still it does not solve my problem: Unfortunately, some major sites such as YAHOO do not reject unknown addresses in reply to
                  Message 8 of 15 , Jan 31, 2009
                  • 0 Attachment
                    On Saturday 31 January 2009 09:45:16 Wietse Venema wrote:
                    > Melvyn Sopacua:
                    > > On Saturday 31 January 2009 08:03:17 Wietse Venema wrote:
                    > > > Melvyn Sopacua:
                    > > > > The problem is that postfix will see "success" initially:
                    > > > >
                    > > > > - client sends
                    > > > > - postfix receives
                    > > > > - postfix relays, gets OK
                    > > > > ----> postfix deletes queued message
                    > > > > - exchange checks quota, decides mailbox is full
                    > > > > - exchange sends DSN to client
                    > > >
                    > > > Use reject_unverified_recipient, with a persistent database. This
                    > > > will check the Exchange response BEFORE accepting mail, and will
                    > > > avoid hammering the Exchange server with repeated requests.
                    > > >
                    > > > http://www.postfix.org/ADDRESS_VERIFICATION_README.html
                    > >
                    > > VRFY info@...
                    > > 252 2.1.5 Cannot VRFY user, but will take message for <info@...>
                    >
                    > POSTFIX DOES NOT USE THE VRFY COMMAND.

                    Aha, actual probe messages. Still it does not solve my problem:
                    Unfortunately, some major sites such as YAHOO do not reject unknown addresses
                    in reply to the RCPT TO command, but report a delivery failure in response to
                    end of DATA after a message is transferred. Postfix address verification does
                    not work with such sites.

                    Exchange works like YAHOO in this case. Mailbox restrictions are not checked
                    during SMTP conversation but once the internal queue figured it out.

                    --
                    Melvyn Sopacua
                    mdev@...

                    FreeBSD 7.1-STABLE
                    Qt: 3.3.8
                    KDE: 3.5.10
                  • Melvyn Sopacua
                    ... Yes, I already mentioned that. I m not trying to fix their problem, I m trying to provide redundancy, until their problem is fixed. It could similarly be
                    Message 9 of 15 , Jan 31, 2009
                    • 0 Attachment
                      On Saturday 31 January 2009 09:22:28 Terry Carmen wrote:
                      > Melvyn Sopacua wrote:
                      > > On Saturday 31 January 2009 08:03:17 Wietse Venema wrote:
                      > >> Melvyn Sopacua:
                      > >>> The problem is that postfix will see "success" initially:
                      > >>>
                      > >>> - client sends
                      > >>> - postfix receives
                      > >>> - postfix relays, gets OK
                      > >>> ----> postfix deletes queued message
                      > >>> - exchange checks quota, decides mailbox is full
                      > >>> - exchange sends DSN to client
                      > >>
                      > >> Use reject_unverified_recipient, with a persistent database. This
                      > >> will check the Exchange response BEFORE accepting mail, and will
                      > >> avoid hammering the Exchange server with repeated requests.
                      > >>
                      > >> http://www.postfix.org/ADDRESS_VERIFICATION_README.html
                      > >
                      > > VRFY info@...
                      > > 252 2.1.5 Cannot VRFY user, but will take message for <info@...>
                      > >
                      > > yet, mailbox is full and DSN will come few seconds after mail is
                      > > accepted. Judging from the 2xx response, this means to postfix that VRFY
                      > > succeeded, so the problem persists.
                      >
                      > This is a classic example of trying to fix a people problem using
                      > technology. Exchange is broken. It is accepting then losing messages
                      > that it can't deliver. You are not the exchange admin, so you can't fix it.

                      Yes, I already mentioned that. I'm not trying to fix their problem, I'm trying
                      to provide redundancy, until their problem is fixed. It could similarly be
                      used to catch false positives of a spam filter, until it is trained finer.

                      --
                      Melvyn Sopacua
                    • Wietse Venema
                      ... Well, that is just too bad. Postfix does not have to solve every problem that happens in a down-stream MTA. We live in a free world, and the market is
                      Message 10 of 15 , Jan 31, 2009
                      • 0 Attachment
                        Melvyn Sopacua:
                        > On Saturday 31 January 2009 09:45:16 Wietse Venema wrote:
                        > > Melvyn Sopacua:
                        > > > On Saturday 31 January 2009 08:03:17 Wietse Venema wrote:
                        > > > > Melvyn Sopacua:
                        > > > > > The problem is that postfix will see "success" initially:
                        > > > > >
                        > > > > > - client sends
                        > > > > > - postfix receives
                        > > > > > - postfix relays, gets OK
                        > > > > > ----> postfix deletes queued message
                        > > > > > - exchange checks quota, decides mailbox is full
                        > > > > > - exchange sends DSN to client
                        > > > >
                        > > > > Use reject_unverified_recipient, with a persistent database. This
                        > > > > will check the Exchange response BEFORE accepting mail, and will
                        > > > > avoid hammering the Exchange server with repeated requests.
                        > > > >
                        > > > > http://www.postfix.org/ADDRESS_VERIFICATION_README.html
                        > > >
                        > > > VRFY info@...
                        > > > 252 2.1.5 Cannot VRFY user, but will take message for <info@...>
                        > >
                        > > POSTFIX DOES NOT USE THE VRFY COMMAND.
                        >
                        > Aha, actual probe messages. Still it does not solve my problem:
                        > Unfortunately, some major sites such as YAHOO do not reject unknown addresses
                        > in reply to the RCPT TO command, but report a delivery failure in response to
                        > end of DATA after a message is transferred. Postfix address verification does
                        > not work with such sites.
                        >
                        > Exchange works like YAHOO in this case. Mailbox restrictions are not checked
                        > during SMTP conversation but once the internal queue figured it out.

                        Well, that is just too bad. Postfix does not have to solve every
                        problem that happens in a down-stream MTA. We live in a free world,
                        and the market is always right.

                        Wietse
                      • Melvyn Sopacua
                        ... Agreed. Which is why I informed if it s possible using standard configuration or if I d have to roll my own relay service for this. -- Melvyn Sopacua
                        Message 11 of 15 , Jan 31, 2009
                        • 0 Attachment
                          On Saturday 31 January 2009 10:29:35 Wietse Venema wrote:

                          > Well, that is just too bad. Postfix does not have to solve every
                          > problem that happens in a down-stream MTA. We live in a free world,
                          > and the market is always right.

                          Agreed. Which is why I informed if it's possible using standard configuration
                          or if I'd have to roll my own relay service for this.
                          --
                          Melvyn Sopacua
                        Your message has been successfully submitted and would be delivered to recipients shortly.