From: "Vernon A. Fort" on
I have a setup where the local deliver using cyrus-imapd is located on
an encrypted volume. When the server is rebooted, we will manually
mount the volume and start the cyrus application. However, until we
start cyrus, how can i configure postfix to accept email but defer or
hold the local deliver indefinitely?

we do have the maximal_queue_lifetime set to 1 day. I have set the
defer_transports = local, soft_bounce = yes but when i setup the
maximal_queue_lifetime to say 30 seconds, the message does get bounced
back. Any suggestions?

Vernon

From: Noel Jones on
On 3/31/2010 7:41 PM, Vernon A. Fort wrote:
> I have a setup where the local deliver using cyrus-imapd is located on
> an encrypted volume. When the server is rebooted, we will manually mount
> the volume and start the cyrus application. However, until we start
> cyrus, how can i configure postfix to accept email but defer or hold the
> local deliver indefinitely?
>
> we do have the maximal_queue_lifetime set to 1 day. I have set the
> defer_transports = local, soft_bounce = yes but when i setup the
> maximal_queue_lifetime to say 30 seconds, the message does get bounced
> back. Any suggestions?
>
> Vernon

Why in the world would you set maximal_queue_lifetime to
30s??? Please point the gun away from your foot.

The proper way to configure postfix to defer mail when cyrus
is not available is to ... do nothing. Let the connections to
cyrus fail and allow postfix to retry as it normally does.

Is there some reason normal postfix scheduling and defer/retry
won't work for you? Then describe the original problem and
maybe a better solution can be found.

-- Noel Jones

From: "Vernon A. Fort" on
On 3/31/2010 9:58 PM, Noel Jones wrote:
> On 3/31/2010 7:41 PM, Vernon A. Fort wrote:
>> I have a setup where the local deliver using cyrus-imapd is located on
>> an encrypted volume. When the server is rebooted, we will manually mount
>> the volume and start the cyrus application. However, until we start
>> cyrus, how can i configure postfix to accept email but defer or hold the
>> local deliver indefinitely?
>>
>> we do have the maximal_queue_lifetime set to 1 day. I have set the
>> defer_transports = local, soft_bounce = yes but when i setup the
>> maximal_queue_lifetime to say 30 seconds, the message does get bounced
>> back. Any suggestions?
>>
>> Vernon
>
> Why in the world would you set maximal_queue_lifetime to 30s???
> Please point the gun away from your foot.
>
> The proper way to configure postfix to defer mail when cyrus is not
> available is to ... do nothing. Let the connections to cyrus fail and
> allow postfix to retry as it normally does.
>
> Is there some reason normal postfix scheduling and defer/retry won't
> work for you? Then describe the original problem and maybe a better
> solution can be found.
>
> -- Noel Jones
The maximal_queue_lifetime-30s was for testing only - its normally set
for 1d. The sole issues is to prevent mail from bouncing back if we
don't get the encrypted volume mounted and cyrus started back up soon
enough. A reasonable example would be if the server rebooted due to a
power hiccup and we did not get the notifications quick enough.

For now, i have a startup script to set the maximal_queue_lifetime to 1w
using postconf -e. This seems to do the trick.

Vernon

From: Wietse Venema on
Vernon A. Fort:
> The maximal_queue_lifetime-30s was for testing only - its normally set
> for 1d. The sole issues is to prevent mail from bouncing back if we
> don't get the encrypted volume mounted and cyrus started back up soon
> enough. A reasonable example would be if the server rebooted due to a
> power hiccup and we did not get the notifications quick enough.
>
> For now, i have a startup script to set the maximal_queue_lifetime to 1w
> using postconf -e. This seems to do the trick.

Another option is

postconf -e "master_service_disable = unix.local"

Or even:

postconf -e "master_service_disable = qmgr.fifo"

(requires Postfix 2.6 or later).

Wietse

From: Larry Stone on
On 3/31/10 11:03 PM, Vernon A. Fort at vfort(a)provident-solutions.com wrote:


> The maximal_queue_lifetime-30s was for testing only - its normally set
> for 1d.

One day is pretty short. The default is five days. Although things are a lot
more reliable these days, it's still possible for an unattended destination
server to be down over a weekend or be down for long periods for an upgrade,
etc.

--
Larry Stone
lstone19(a)stonejongleux.com
http://www.stonejongleux.com/