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

Re: HOLDing certain recipients during migration

Expand Messages
  • Reindl Harald
    ... i would not do this and simply shutdown mail-services at night due migration, the sender will try later and you do not lost messages if the migration is
    Message 1 of 14 , Feb 11, 2013
    View Source
    • 0 Attachment
      Am 11.02.2013 19:56, schrieb Miha Valencic:
      > Hi!
      >
      > Just want to double check if I am planning this correctly. We're migrating users from one system to another, and
      > want to HOLD incoming messages for certain recipients during migration. For that purpose, we'll create a file with
      > users listed:
      >
      > /hold-users:
      > user1@... <mailto:user1@...> HOLD
      > user2@... <mailto:user2@...> HOLD

      i would not do this and simply shutdown mail-services at night due
      migration, the sender will try later and you do not lost messages

      if the migration is done smart like imapsync before shutdown
      and after that with the correct params again to sync changes
      the downtime is minimal
    • Miha Valencic
      Hello! Will below be OK for holding messages for recipients? Thanks, Miha
      Message 2 of 14 , Feb 12, 2013
      View Source
      • 0 Attachment

        Hello!

        Will below be OK for holding messages for recipients?

        Thanks, Miha

        On Feb 11, 2013 7:56 PM, "Miha Valencic" <miha.valencic@...> wrote:
        Hi!

        Just want to double check if I am planning this correctly. We're migrating users from one system to another, and want to HOLD incoming messages for certain recipients during migration. For that purpose, we'll create a file with users listed:

        /hold-users:
        ...

        postmap that file and configure this HOLD queue in recipient restrictions:

        smtpd_recipient_restrictions = check_recipient_access hash:/opt/zimbra/conf/postfix_recipient_access_ldapcheck, reject_non_fqdn_recipient,  permit_sasl_authenticated, permit_mynetworks, reject_unknown_sender_domain, reject_unauth_destination, permit

        In order to HOLD messages, I need to put "check_recipient_access hash:/hold-users" somewhere. 

        If I put it before "permit_sasl_authenticated", this should do the trick, correct?

        Thanks,
         Miha.

      • Noel Jones
        ... put it under smtpd_sender_restrictions so you don t have to muck around with your existing smtpd_recipient_restrictions. # main.cf
        Message 3 of 14 , Feb 12, 2013
        View Source
        • 0 Attachment
          > On Feb 11, 2013 7:56 PM, "Miha Valencic" <miha.valencic@...
          > <mailto:miha.valencic@...>> wrote:
          >
          > Hi!
          >
          > Just want to double check if I am planning this correctly. We're
          > migrating users from one system to another, and want to HOLD
          > incoming messages for certain recipients during migration. For
          > that purpose, we'll create a file with users listed:
          >
          > /hold-users:
          > user1@... <mailto:user1@...> HOLD
          > user2@... <mailto:user2@...> HOLD
          > ...
          >
          > postmap that file and configure this HOLD queue in recipient
          > restrictions:
          >
          > smtpd_recipient_restrictions = check_recipient_access
          > hash:/opt/zimbra/conf/postfix_recipient_access_ldapcheck,
          > reject_non_fqdn_recipient, permit_sasl_authenticated,
          > permit_mynetworks, reject_unknown_sender_domain,
          > reject_unauth_destination, permit
          >
          > In order to HOLD messages, I need to put "check_recipient_access
          > hash:/hold-users" somewhere.
          >
          > If I put it before "permit_sasl_authenticated", this should do
          > the trick, correct?
          >
          > Thanks,
          > Miha.
          >


          put it under smtpd_sender_restrictions so you don't have to muck
          around with your existing smtpd_recipient_restrictions.

          # main.cf
          smtpd_sender_restrictions =
          check_recipient_access hash:/etc/postfix/hold-users




          -- Noel Jones
        • Miha Valencic
          ... Noel, just want to make sure: postfix 2.7 evaluates smtpd_sender_restrictions *after* RCPT TO? Couldn t find which version of postfix changed the time of
          Message 4 of 14 , Feb 12, 2013
          View Source
          • 0 Attachment
            On Tue, Feb 12, 2013 at 4:28 PM, Noel Jones <njones@...> wrote:
            >
            > put it under smtpd_sender_restrictions so you don't have to muck
            > around with your existing smtpd_recipient_restrictions.

            Noel,

            just want to make sure: postfix 2.7 evaluates
            smtpd_sender_restrictions *after* RCPT TO? Couldn't find which version
            of postfix changed the time of the evaluation. From the docs: "Early
            Postfix versions evaluated SMTP access restrictions lists as early as
            possible..."

            Don't sender restrictions get evaluated before the recipient
            restrictions? Which would mean that we would potentically "HOLD" email
            (spam) for non-existing users (and hence generate NDRs)?

            Thanks, Miha.
          • Reindl Harald
            ... this will give you the answer [root@srv-rhsoft:~]$ postconf -d | grep smtpd_delay_reject smtpd_delay_reject = yes
            Message 5 of 14 , Feb 12, 2013
            View Source
            • 0 Attachment
              Am 12.02.2013 17:07, schrieb Miha Valencic:
              > On Tue, Feb 12, 2013 at 4:28 PM, Noel Jones <njones@...> wrote:
              >>
              >> put it under smtpd_sender_restrictions so you don't have to muck
              >> around with your existing smtpd_recipient_restrictions.
              >
              > Noel,
              >
              > just want to make sure: postfix 2.7 evaluates
              > smtpd_sender_restrictions *after* RCPT TO? Couldn't find which version
              > of postfix changed the time of the evaluation. From the docs: "Early
              > Postfix versions evaluated SMTP access restrictions lists as early as
              > possible..."

              this will give you the answer

              [root@srv-rhsoft:~]$ postconf -d | grep smtpd_delay_reject
              smtpd_delay_reject = yes
            • Noel Jones
              ... In this case, early refers to ancient pre-1.0 versions. In your version, evaluation is controlled by the smtpd_delay_reject, which should always be set
              Message 6 of 14 , Feb 12, 2013
              View Source
              • 0 Attachment
                On 2/12/2013 10:07 AM, Miha Valencic wrote:
                > On Tue, Feb 12, 2013 at 4:28 PM, Noel Jones <njones@...> wrote:
                >>
                >> put it under smtpd_sender_restrictions so you don't have to muck
                >> around with your existing smtpd_recipient_restrictions.
                >
                > Noel,
                >
                > just want to make sure: postfix 2.7 evaluates
                > smtpd_sender_restrictions *after* RCPT TO? Couldn't find which version
                > of postfix changed the time of the evaluation. From the docs: "Early
                > Postfix versions evaluated SMTP access restrictions lists as early as
                > possible..."

                In this case, "early" refers to ancient pre-1.0 versions. In your
                version, evaluation is controlled by the smtpd_delay_reject, which
                should always be set to "yes".
                http://www.postfix.org/postconf.5.html#smtpd_delay_reject


                >
                > Don't sender restrictions get evaluated before the recipient
                > restrictions? Which would mean that we would potentically "HOLD" email
                > (spam) for non-existing users (and hence generate NDRs)?
                >
                > Thanks, Miha.
                >

                HOLD does not guarantee the mail will be accepted. The HOLD action
                doesn't do anything until after the mail is accepted and queued.



                -- Noel Jones
              • Sahil Tandon
                ... The HOLD action affects all recipients; you can be more specific by using the retry service. See the following thread:
                Message 7 of 14 , Feb 13, 2013
                View Source
                • 0 Attachment
                  On Mon, 2013-02-11 at 19:56:23 +0100, Miha Valencic wrote:

                  > Just want to double check if I am planning this correctly. We're migrating
                  > users from one system to another, and want to HOLD incoming messages for
                  > certain recipients during migration. For that purpose, we'll create a file
                  > with users listed:
                  >
                  > /hold-users:
                  > user1@... HOLD
                  > user2@... HOLD
                  > ...

                  The HOLD action affects all recipients; you can be more specific by
                  using the retry service. See the following thread:

                  http://article.gmane.org/gmane.mail.postfix.user/197989

                  --
                  Sahil Tandon
                • Miha Valencic
                  ... Thanks Sahil! I ll consider it. It also makes sense, though delivery of rejected emails is somewhat delayed (due to unknown retry interval). What do you
                  Message 8 of 14 , Feb 14, 2013
                  View Source
                  • 0 Attachment
                    On Thu, Feb 14, 2013 at 4:34 AM, Sahil Tandon <sahil+postfix@...> wrote:
                    > The HOLD action affects all recipients; you can be more specific by
                    > using the retry service. See the following thread:
                    > http://article.gmane.org/gmane.mail.postfix.user/197989

                    Thanks Sahil! I'll consider it. It also makes sense, though delivery
                    of rejected emails is somewhat delayed (due to unknown retry
                    interval). What do you mean by 'HOLD action affects all recipients'?
                    HOLD action affects only recipients listed in the "hold file" - at
                    least that's how I understand it.

                    Miha
                  • Noel Jones
                    ... HOLD acts at the message level, not the recipient level. If one recipient of a multi-recipient message is put on HOLD, all recipients of that message will
                    Message 9 of 14 , Feb 14, 2013
                    View Source
                    • 0 Attachment
                      On 2/14/2013 3:43 AM, Miha Valencic wrote:
                      > On Thu, Feb 14, 2013 at 4:34 AM, Sahil Tandon <sahil+postfix@...> wrote:
                      >> The HOLD action affects all recipients; you can be more specific by
                      >> using the retry service. See the following thread:
                      >> http://article.gmane.org/gmane.mail.postfix.user/197989
                      >
                      > Thanks Sahil! I'll consider it. It also makes sense, though delivery
                      > of rejected emails is somewhat delayed (due to unknown retry
                      > interval). What do you mean by 'HOLD action affects all recipients'?
                      > HOLD action affects only recipients listed in the "hold file" - at
                      > least that's how I understand it.
                      >
                      > Miha
                      >


                      HOLD acts at the message level, not the recipient level.
                      If one recipient of a multi-recipient message is put on HOLD, all
                      recipients of that message will be affected.


                      -- Noel Jones
                    • Miha Valencic
                      ... I see. I believe the HOLD is better suited to our scenario as a temporary reject and this (HOLDing messages for all recipients if one matches) is
                      Message 10 of 14 , Feb 14, 2013
                      View Source
                      • 0 Attachment
                        On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones <njones@...> wrote:
                        > HOLD acts at the message level, not the recipient level.
                        > If one recipient of a multi-recipient message is put on HOLD, all
                        > recipients of that message will be affected.

                        I see. I believe the HOLD is better suited to our scenario as a
                        temporary reject and this (HOLDing messages for all recipients if one
                        matches) is acceptable.

                        Thanks for the explanation Noel.

                        Miha
                      • Sahil Tandon
                        ... I do not understand your response; the HOLD action is not a temporary reject. Anyway, my involvement earlier in the thread is for others who might chance
                        Message 11 of 14 , Feb 19, 2013
                        View Source
                        • 0 Attachment
                          On Thu, 2013-02-14 at 13:13:54 +0100, Miha Valencic wrote:

                          > On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones <njones@...> wrote:
                          > > HOLD acts at the message level, not the recipient level.
                          > > If one recipient of a multi-recipient message is put on HOLD, all
                          > > recipients of that message will be affected.
                          >
                          > I see. I believe the HOLD is better suited to our scenario as a
                          > temporary reject and this (HOLDing messages for all recipients if one
                          > matches) is acceptable.

                          I do not understand your response; the HOLD action is not a temporary
                          reject. Anyway, my involvement earlier in the thread is for others who
                          might chance upon this chain in the archives, and prefer the alternative
                          (and IMHO more robust) approach.

                          --
                          Sahil Tandon
                        • francis picabia
                          ... Hello, I looked up the other thread where it is suggested to use transport_maps file with entry like: user@example.com retry:4.0.0 Mailbox being migrated
                          Message 12 of 14 , May 14, 2013
                          View Source
                          • 0 Attachment
                            On Tue, Feb 19, 2013 at 9:20 PM, Sahil Tandon <sahil+postfix@...> wrote:
                            On Thu, 2013-02-14 at 13:13:54 +0100, Miha Valencic wrote:

                            > On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones <njones@...> wrote:
                            > > HOLD acts at the message level, not the recipient level.
                            > > If one recipient of a multi-recipient message is put on HOLD, all
                            > > recipients of that message will be affected.
                            >
                            > I see. I believe the HOLD is better suited to our scenario as a
                            > temporary reject and this (HOLDing messages for all recipients if one
                            > matches) is acceptable.

                            I do not understand your response; the HOLD action is not a temporary
                            reject.  Anyway, my involvement earlier in the thread is for others who
                            might chance upon this chain in the archives, and prefer the alternative
                            (and IMHO more robust) approach.


                            Hello,

                            I looked up the other thread where it is suggested to use transport_maps
                            file with entry like:

                            user@... retry:4.0.0 Mailbox being migrated

                            I've tested it, and it works fine if I use the target address of virtual_alias_maps,
                            but not if I list the address in the email.  In our case this is to hold/suspend email
                            until the mailbox is copied to a second system, where we continue to
                            run mail on both mailbox systems.

                            If I set up entries like:

                            user@... retry:4.0.0 Mailbox being migrated

                            That will keep it in the queue all right, but how to release it so it
                            will deliver to user@... after mailboxes have
                            been moved?  I'd think we'd need a way to hold it prior to getting
                            processed by the virtual mapping.


                          • francis picabia
                            ... It is a bit of an ugly kludge, but here is how we are handling it. There are a few hundred mailboxes to move to the secondary server - we ll call the
                            Message 13 of 14 , May 14, 2013
                            View Source
                            • 0 Attachment
                              On Tue, May 14, 2013 at 10:37 AM, francis picabia <fpicabia@...> wrote:
                              >
                              > On Tue, Feb 19, 2013 at 9:20 PM, Sahil Tandon <sahil+postfix@...> wrote:
                              >>
                              >> On Thu, 2013-02-14 at 13:13:54 +0100, Miha Valencic wrote:
                              >>
                              >> > On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones <njones@...> wrote:
                              >> > > HOLD acts at the message level, not the recipient level.
                              >> > > If one recipient of a multi-recipient message is put on HOLD, all
                              >> > > recipients of that message will be affected.
                              >> >
                              >> > I see. I believe the HOLD is better suited to our scenario as a
                              >> > temporary reject and this (HOLDing messages for all recipients if one
                              >> > matches) is acceptable.
                              >>
                              >> I do not understand your response; the HOLD action is not a temporary
                              >> reject. Anyway, my involvement earlier in the thread is for others who
                              >> might chance upon this chain in the archives, and prefer the alternative
                              >> (and IMHO more robust) approach.
                              >>
                              >
                              > Hello,
                              >
                              > I looked up the other thread where it is suggested to use transport_maps
                              > file with entry like:
                              >
                              > user@... retry:4.0.0 Mailbox being migrated
                              >
                              > I've tested it, and it works fine if I use the target address of virtual_alias_maps,
                              > but not if I list the address in the email. In our case this is to hold/suspend email
                              > until the mailbox is copied to a second system, where we continue to
                              > run mail on both mailbox systems.
                              >
                              > If I set up entries like:
                              >
                              > user@... retry:4.0.0 Mailbox being migrated
                              >
                              > That will keep it in the queue all right, but how to release it so it
                              > will deliver to user@... after mailboxes have
                              > been moved? I'd think we'd need a way to hold it prior to getting
                              > processed by the virtual mapping.
                              >
                              >

                              It is a bit of an ugly kludge, but here is how we are handling it. There
                              are a few hundred mailboxes to move to the secondary server - we'll
                              call the secondary mailbox server server2.example.com here.

                              On the MX systems, we set up a dummy transport for a server which does
                              not handle mailboxes.

                              transport_maps = hash:/etc/postfix/transport, hash:/etc/postfix/migrating

                              The file 'migrating' contains:

                              dummy.example.com retry:4.0.0 Mailbox being migrated

                              The virtual_alias_maps file is set so the migrating users have this
                              dummy destination. (We have an automated set of scripts to
                              manage the mapping and generate postfix conf files.)

                              user@... user@...

                              Now emails for these users are held on the MX systems.

                              Once the mailboxes have been moved over, we can requeue, using a
                              temporary transport
                              redirecting entry for the occassion:

                              dummy.example.com relay:[server2.example.com]:25

                              The virtual mapping conf files are set to the proper target
                              of @... rather than dummy.

                              Then pass through the messages waiting in the queue. We have a perl
                              script which takes
                              the mailq output and puts each chunk on one line, called oneline.pl.

                              for qid in `mailq | oneline.pl | grep '@...' | cut -f1
                              -d' '`; do postsuper -r $qid; done

                              Maybe there is a more simple solution, but that's what I've got for now.
                            Your message has been successfully submitted and would be delivered to recipients shortly.