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

293156Re: HOLDing certain recipients during migration

Expand Messages
  • francis picabia
    May 14, 2013
      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.
    • Show all 14 messages in this topic