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

Re: HOLDing certain recipients during migration

Expand Messages
  • 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 1 of 14 , Feb 14, 2013
    • 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 2 of 14 , Feb 14, 2013
      • 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 3 of 14 , Feb 14, 2013
        • 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 4 of 14 , Feb 19, 2013
          • 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 5 of 14 , May 14, 2013
            • 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 6 of 14 , May 14, 2013
              • 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.