On Tue, May 14, 2013 at 10:37 AM, francis picabia <fpica...@gmail.com> wrote: > > On Tue, Feb 19, 2013 at 9:20 PM, Sahil Tandon <sahil+post...@tandon.net> > 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 <njo...@megan.vbhcs.org> 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: > > u...@example.com 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: > > u...@server1.example.com 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 u...@server2.example.com 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.) u...@example.com u...@dummy.example.com 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 @server2.example.com 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 '@dummy.example.com' | cut -f1 -d' '`; do postsuper -r $qid; done Maybe there is a more simple solution, but that's what I've got for now.
