HOLDing certain recipients during migration

[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:

[hidden email] HOLD

[hidden email] 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.

[Reindl Harald-2]

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:
> [hidden email] <mailto:[hidden email]> HOLD
> [hidden email] <mailto:[hidden email]> 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

On Feb 11, 2013 7:56 PM, "Miha Valencic" <[hidden email]> 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:

[hidden email] HOLD

[hidden email] 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.

[Noel Jones-2]

> On Feb 11, 2013 7:56 PM, "Miha Valencic" <[hidden email]
> <mailto:[hidden email]>> 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:
>     [hidden email] <mailto:[hidden email]> HOLD
>     [hidden email] <mailto:[hidden email]> 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]

On Tue, Feb 12, 2013 at 4:28 PM, Noel Jones <[hidden email]> 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-2]

Am 12.02.2013 17:07, schrieb Miha Valencic:

> On Tue, Feb 12, 2013 at 4:28 PM, Noel Jones <[hidden email]> 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-2]

On 2/12/2013 10:07 AM, Miha Valencic wrote:

> On Tue, Feb 12, 2013 at 4:28 PM, Noel Jones <[hidden email]> 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-4]

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:
> [hidden email] HOLD
> [hidden email] 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]

On Thu, Feb 14, 2013 at 4:34 AM, Sahil Tandon <[hidden email]> 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-2]

On 2/14/2013 3:43 AM, Miha Valencic wrote:

> On Thu, Feb 14, 2013 at 4:34 AM, Sahil Tandon <[hidden email]> 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]

On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones <[hidden email]> 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-4]

On Thu, 2013-02-14 at 13:13:54 +0100, Miha Valencic wrote:

> On Thu, Feb 14, 2013 at 1:01 PM, Noel Jones <[hidden email]> 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]

On Tue, Feb 19, 2013 at 9:20 PM, Sahil Tandon <[hidden email]> 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 <[hidden email]> 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:

[hidden email] 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:

[hidden email] 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 [hidden email] 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]

On Tue, May 14, 2013 at 10:37 AM, francis picabia <[hidden email]> wrote:

>
> On Tue, Feb 19, 2013 at 9:20 PM, Sahil Tandon <[hidden email]> 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 <[hidden email]> 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:
>
> [hidden email] 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:
>
> [hidden email] 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 [hidden email] 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.)

[hidden email]        [hidden email]

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.