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

Recipient verification delay

Expand Messages
  • Daniel L. Miller
    I ve been using recipient verification for some time with good results but I think I need to make an adjustment to accommodate the changing email world. It
    Message 1 of 13 , Feb 6, 2013
    • 0 Attachment
      I've been using recipient verification for some time with good results
      but I think I need to make an adjustment to accommodate the changing
      email world. It appears a number of servers have adopted minimal
      greylisting - such that they immediately reject initial contacts but
      have a minimal timeout (just a few seconds) before accepting.

      At the moment, my client behavior (Thunderbird) on a send is to show
      processing...for an extended period. However, if after sending - and
      seeing the apparent timeout condition - the user cancels the send and
      then manually retries it immediately goes out. So my belief is my
      Postfix server is performing one or more verification attempts within
      the remote greylisting servers block - and is then waiting for responses.

      How can I set Postfix to make an initial attempt, not wait longer than 2
      seconds for a response, and then make another perhaps 5 or 10 seconds later?
      --
      Daniel
    • Noel Jones
      ... Recipient verification is intended for your own recipients, such as a mail gateway in front of a downstream internal mailstore. If you re doing recipient
      Message 2 of 13 , Feb 6, 2013
      • 0 Attachment
        On 2/6/2013 2:26 PM, Daniel L. Miller wrote:
        > I've been using recipient verification for some time with good
        > results but I think I need to make an adjustment to accommodate the
        > changing email world. It appears a number of servers have adopted
        > minimal greylisting - such that they immediately reject initial
        > contacts but have a minimal timeout (just a few seconds) before
        > accepting.

        Recipient verification is intended for your own recipients, such as
        a mail gateway in front of a downstream internal mailstore.

        If you're doing recipient verification on outgoing mail, please don't.


        >
        > At the moment, my client behavior (Thunderbird) on a send is to show
        > processing...for an extended period. However, if after sending -
        > and seeing the apparent timeout condition - the user cancels the
        > send and then manually retries it immediately goes out.

        Still trying to figure out how that relates to postfix...

        > So my
        > belief is my Postfix server is performing one or more verification
        > attempts within the remote greylisting servers block - and is then
        > waiting for responses.
        >
        > How can I set Postfix to make an initial attempt, not wait longer
        > than 2 seconds for a response, and then make another perhaps 5 or 10
        > seconds later?

        Apparently you're having some kind of problem with recipient
        verification. Maybe if you describe the problem rather than a
        proposed solution, we can help. Along wiht your description, please
        include logs demonstrating the problem and your "postconf -n" output.
        http://www.postfix.org/DEBUG_README.html#mail


        -- Noel Jones
      • Reindl Harald
        ... i belive you mean SENDER verification, the other way makes no sense :-) and some will block you because sender verification if some bad guy try to deilver
        Message 3 of 13 , Feb 6, 2013
        • 0 Attachment
          Am 06.02.2013 21:26, schrieb Daniel L. Miller:
          > I've been using recipient verification for some time with good results but I think I need to make an adjustment to
          > accommodate the changing email world. It appears a number of servers have adopted minimal greylisting - such that
          > they immediately reject initial contacts but have a minimal timeout (just a few seconds) before accepting.

          i belive you mean SENDER verification, the other way makes no sense :-)

          and some will block you because sender verification if some bad
          guy try to deilver mass mails with intentet wrong senders of the
          same domain nresulting in you assume to try spamming from the view
          of the forged domain

          i would not do that these days because such mechanisms can be
          exploitet and greylisting is very often used for good reasons
        • Daniel L. Miller
          ... I m using the reject_unverified_recipient parameter on all mail. That way when a user mistypes a recipient address they get instant feedback - if they re
          Message 4 of 13 , Feb 6, 2013
          • 0 Attachment
            On 2/6/2013 12:39 PM, Noel Jones wrote:
            > On 2/6/2013 2:26 PM, Daniel L. Miller wrote:
            >> I've been using recipient verification for some time with good
            >> results but I think I need to make an adjustment to accommodate the
            >> changing email world. It appears a number of servers have adopted
            >> minimal greylisting - such that they immediately reject initial
            >> contacts but have a minimal timeout (just a few seconds) before
            >> accepting.
            > Recipient verification is intended for your own recipients, such as
            > a mail gateway in front of a downstream internal mailstore.
            >
            > If you're doing recipient verification on outgoing mail, please don't.
            >

            I'm using the "reject_unverified_recipient" parameter on all mail. That
            way when a user mistypes a recipient address they get instant feedback -
            if they're told "message sent" then it actually got somewhere (unless
            the remote server swallows garbage recipients).

            My question is how to tune it - my first guesses involve
            "address_verify_poll_count" and "address_verify_poll_delay" but I don't
            want to make adjustments blindly.
            --
            Daniel
          • Wietse Venema
            ... There parameters will not change the result. reject_unverified_recipient will stop as soon as it has a reply from the SMTP server (or from the local verify
            Message 5 of 13 , Feb 6, 2013
            • 0 Attachment
              Daniel L. Miller:
              > >> I've been using recipient verification for some time with good
              > >> results but I think I need to make an adjustment to accommodate the
              > >> changing email world. It appears a number of servers have adopted
              > >> minimal greylisting - such that they immediately reject initial
              > >> contacts but have a minimal timeout (just a few seconds) before
              > >> accepting.
              >
              > I'm using the "reject_unverified_recipient" parameter on all mail. That
              > way when a user mistypes a recipient address they get instant feedback -
              > if they're told "message sent" then it actually got somewhere (unless
              > the remote server swallows garbage recipients).
              >
              > My question is how to tune it - my first guesses involve
              > "address_verify_poll_count" and "address_verify_poll_delay" but I don't
              > want to make adjustments blindly.

              There parameters will not change the result.

              reject_unverified_recipient will stop as soon as it has a reply
              from the SMTP server (or from the local verify cache).

              If that result is "4XX Come back in a few seconds", then
              reject_unverified_recipient will not wait for a few seconds.

              Wietse
            • Daniel L. Miller
              ... Thank you. Is there an adjustment that will? Or is the manual client step my only option? -- Daniel
              Message 6 of 13 , Feb 6, 2013
              • 0 Attachment
                On 2/6/2013 1:37 PM, Wietse Venema wrote:
                > Daniel L. Miller:
                >>>> I've been using recipient verification for some time with good
                >>>> results but I think I need to make an adjustment to accommodate the
                >>>> changing email world. It appears a number of servers have adopted
                >>>> minimal greylisting - such that they immediately reject initial
                >>>> contacts but have a minimal timeout (just a few seconds) before
                >>>> accepting.
                >> I'm using the "reject_unverified_recipient" parameter on all mail. That
                >> way when a user mistypes a recipient address they get instant feedback -
                >> if they're told "message sent" then it actually got somewhere (unless
                >> the remote server swallows garbage recipients).
                >>
                >> My question is how to tune it - my first guesses involve
                >> "address_verify_poll_count" and "address_verify_poll_delay" but I don't
                >> want to make adjustments blindly.
                > There parameters will not change the result.
                >
                > reject_unverified_recipient will stop as soon as it has a reply
                > from the SMTP server (or from the local verify cache).
                >
                > If that result is "4XX Come back in a few seconds", then
                > reject_unverified_recipient will not wait for a few seconds.
                >

                Thank you. Is there an adjustment that will? Or is the manual client
                step my only option?

                --
                Daniel
              • Wietse Venema
                ... To sound like a broken record, reject_unverified_recipient will stop when it has a reply from the remote SMTP server (or from the local verify cache). Just
                Message 7 of 13 , Feb 6, 2013
                • 0 Attachment
                  Daniel L. Miller:
                  > > reject_unverified_recipient will stop as soon as it has a reply
                  > > from the SMTP server (or from the local verify cache).
                  > >
                  > > If that result is "4XX Come back in a few seconds", then
                  > > reject_unverified_recipient will not wait for a few seconds.
                  > >
                  >
                  > Thank you. Is there an adjustment that will? Or is the manual client
                  > step my only option?

                  To sound like a broken record, reject_unverified_recipient will
                  stop when it has a reply from the remote SMTP server (or from the
                  local verify cache).

                  Just don't use reject_unverified_recipient for remote destinations.

                  Wietse
                • Daniel L. Miller
                  ... It s quite possible I m using this wrong - but other than the slight hiccup I m seeing with more servers adopting minimal greylisting I LIKE having the
                  Message 8 of 13 , Feb 6, 2013
                  • 0 Attachment
                    On 2/6/2013 1:53 PM, Wietse Venema wrote:
                    > Daniel L. Miller:
                    >>> reject_unverified_recipient will stop as soon as it has a reply
                    >>> from the SMTP server (or from the local verify cache).
                    >>>
                    >>> If that result is "4XX Come back in a few seconds", then
                    >>> reject_unverified_recipient will not wait for a few seconds.
                    >>>
                    >> Thank you. Is there an adjustment that will? Or is the manual client
                    >> step my only option?
                    > To sound like a broken record, reject_unverified_recipient will
                    > stop when it has a reply from the remote SMTP server (or from the
                    > local verify cache).
                    >
                    > Just don't use reject_unverified_recipient for remote destinations.

                    It's quite possible I'm using this wrong - but other than the slight
                    hiccup I'm seeing with more servers adopting minimal greylisting I LIKE
                    having the recipient verification. As I said - it gives the users
                    immediate feedback.

                    Otherwise when they send a message to "usre@...", the client
                    hands it off - the user thinks the message actually sent when in reality
                    they will get a rejection message some time later. And for my
                    technology-challenged users...

                    --
                    Daniel
                  • Reindl Harald
                    ... your idea is completly broken email is NOT instant message it is VERY common that some destination is not available due network problems between your
                    Message 9 of 13 , Feb 6, 2013
                    • 0 Attachment
                      Am 06.02.2013 22:57, schrieb Daniel L. Miller:

                      > Otherwise when they send a message to "usre@...", the client hands it off - the user thinks the message
                      > actually sent when in reality they will get a rejection message some time later

                      your idea is completly broken
                      email is NOT instant message

                      it is VERY common that some destination is not available due network
                      problems between your server and the final one or overload and that
                      is why 4xx was invented

                      typically a mail has up to 5 days to reach the destination
                      maximal_queue_lifetime = 5d

                      and no, you do your users NOT a favour by instantly give
                      them an error back because temporary errors - if i would
                      not be my own mailadmin and my ISP would force such a setup
                      i would like to have my money back to say it clear
                    • Reindl Harald
                      ... BTW: how do you imagine your idea of immediate feedback in the case of multi RCPT messages where one out of ten RCPT have a temporary error? * give no
                      Message 10 of 13 , Feb 6, 2013
                      • 0 Attachment
                        Am 06.02.2013 23:02, schrieb Reindl Harald:
                        >
                        >
                        > Am 06.02.2013 22:57, schrieb Daniel L. Miller:
                        >
                        >> Otherwise when they send a message to "usre@...", the client hands it off - the user thinks the message
                        >> actually sent when in reality they will get a rejection message some time later
                        >
                        > your idea is completly broken
                        > email is NOT instant message
                        >
                        > it is VERY common that some destination is not available due network
                        > problems between your server and the final one or overload and that
                        > is why 4xx was invented
                        >
                        > typically a mail has up to 5 days to reach the destination
                        > maximal_queue_lifetime = 5d
                        >
                        > and no, you do your users NOT a favour by instantly give
                        > them an error back because temporary errors - if i would
                        > not be my own mailadmin and my ISP would force such a setup
                        > i would like to have my money back to say it clear

                        BTW:
                        how do you imagine your idea of "immediate feedback" in the
                        case of multi RCPT messages where one out of ten RCPT have
                        a temporary error?

                        * give no feedback and skip RCPT verification
                        * give back error to the client because 10% failed
                        * how do you imageine the client should handle this
                        * how should different clients handle this
                      • Noel Jones
                        ... Sorry, using reject_unverified_recipient with outgoing mail is simply not practical because of greylisting. There is no way postfix can be configured to
                        Message 11 of 13 , Feb 6, 2013
                        • 0 Attachment
                          On 2/6/2013 3:57 PM, Daniel L. Miller wrote:
                          > On 2/6/2013 1:53 PM, Wietse Venema wrote:
                          >> Daniel L. Miller:
                          >>>> reject_unverified_recipient will stop as soon as it has a reply
                          >>>> from the SMTP server (or from the local verify cache).
                          >>>>
                          >>>> If that result is "4XX Come back in a few seconds", then
                          >>>> reject_unverified_recipient will not wait for a few seconds.
                          >>>>
                          >>> Thank you. Is there an adjustment that will? Or is the manual
                          >>> client
                          >>> step my only option?
                          >> To sound like a broken record, reject_unverified_recipient will
                          >> stop when it has a reply from the remote SMTP server (or from the
                          >> local verify cache).
                          >>
                          >> Just don't use reject_unverified_recipient for remote destinations.
                          >
                          > It's quite possible I'm using this wrong - but other than the slight
                          > hiccup I'm seeing with more servers adopting minimal greylisting I
                          > LIKE having the recipient verification. As I said - it gives the
                          > users immediate feedback.
                          >
                          > Otherwise when they send a message to "usre@...", the client
                          > hands it off - the user thinks the message actually sent when in
                          > reality they will get a rejection message some time later. And for
                          > my technology-challenged users...
                          >


                          Sorry, using reject_unverified_recipient with outgoing mail is
                          simply not practical because of greylisting.

                          There is no way postfix can be configured to keep asking some remote
                          server until it gets the answer it wants. Seems like a good way to
                          get blacklisted...

                          Your job is to explain to your non-techie users that email is a
                          store-and-forward system that values reliability over instant
                          access, and CANNOT give instant delivery confirmation.



                          -- Noel Jones
                        • Daniel L. Miller
                          ... Good points, but... Different strokes for different folks. For a larger company needing to support a quantity of users the demands on the IT staff are
                          Message 12 of 13 , Feb 6, 2013
                          • 0 Attachment
                            On 2/6/2013 2:06 PM, Reindl Harald wrote:
                            >
                            > Am 06.02.2013 23:02, schrieb Reindl Harald:
                            >>
                            >> Am 06.02.2013 22:57, schrieb Daniel L. Miller:
                            >>
                            >>> Otherwise when they send a message to "usre@...", the client hands it off - the user thinks the message
                            >>> actually sent when in reality they will get a rejection message some time later
                            >> your idea is completly broken
                            >> email is NOT instant message
                            >>
                            >> it is VERY common that some destination is not available due network
                            >> problems between your server and the final one or overload and that
                            >> is why 4xx was invented
                            >>
                            >> typically a mail has up to 5 days to reach the destination
                            >> maximal_queue_lifetime = 5d
                            >>
                            >> and no, you do your users NOT a favour by instantly give
                            >> them an error back because temporary errors - if i would
                            >> not be my own mailadmin and my ISP would force such a setup
                            >> i would like to have my money back to say it clear
                            > BTW:
                            > how do you imagine your idea of "immediate feedback" in the
                            > case of multi RCPT messages where one out of ten RCPT have
                            > a temporary error?
                            >
                            > * give no feedback and skip RCPT verification
                            > * give back error to the client because 10% failed
                            > * how do you imageine the client should handle this
                            > * how should different clients handle this
                            Good points, but...

                            Different strokes for different folks. For a larger company needing to
                            support a quantity of users the demands on the IT staff are different.
                            In my case I'm supporting up to 10 users - and I have my own work which
                            needs to be accomplished of which IT is supposed to be the smallest
                            fraction (laugh!).

                            Having the standard store-and-forward-with-retry operation results in
                            calls like, "Daniel, I sent the message 20 minutes ago but Barbara still
                            didn't get it. Why are the computers broken again?!" Since enabling
                            recipient verification years ago that particular issue has disappeared -
                            I just get the question every couple of months when they forget about
                            the verification process (usually because the verify database got wiped
                            or expired).

                            I fully agree with how SMTP is SUPPOSED to work...I'm just trying to
                            take advantage of features available in my software that make my own
                            life easier.
                            --
                            Daniel
                          • Reindl Harald
                            ... so your answer has to be why do Barbara not punish her mailadmin because it is his setup which does not accept incoming mal properly and if your user do
                            Message 13 of 13 , Feb 6, 2013
                            • 0 Attachment
                              Am 06.02.2013 23:37, schrieb Daniel L. Miller:
                              > In my case I'm supporting up to 10 users
                              >
                              > Having the standard store-and-forward-with-retry operation results in calls like, "Daniel, I sent the message 20
                              > minutes ago but Barbara still didn't get it. Why are the computers broken again?!"

                              so your answer has to be "why do Barbara not punish her mailadmin because
                              it is his setup which does not accept incoming mal properly" and if your
                              user do not understand this after explain it three times the user is
                              pretty dumb or you are failing to explain it

                              sorry but no understanding that admins with thousands of users does
                              not have this sort of troubles and the one with the smallest setups
                              believe they need solutions for non-existing problems
                            Your message has been successfully submitted and would be delivered to recipients shortly.