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

Re: Mail backup for malfunctioning MTA

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.