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

Re: HOLDing certain recipients during migration

Expand Messages
  • 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 1 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 2 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 3 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.