Re: best practices for workstations that occasionally disconnect

[Noel Jones]

William Yardley wrote:

I was thinking that setting $defer_transports might avoid
$maximal_queue_lifetime, but from my tests, looks like that's not the
case. What about holding the messages? Same thing?


Messages on hold never expire (postfix ignores messages in the 
hold queue).  When they are released from hold, they get one 
"free" delivery attempt before $maximal_queue_lifetime is tested.



I'd like to avoid DSNs for messages that can't be delivered because a
smarthost can't be reached. Since the DSNs also go through the relayhost
(there's no local delivery), and won't get through til the network is
back up anyway, they don't serve any purpose for us. On the other hand,
in the best of all worlds, I'd like the messages themselves to stick
around.


Sounds like the best solution is just set a really long 
$maximal_queue_lifetime


  -- Noel Jones

Re: best practices for workstations that occasionally disconnect

[William Yardley]

On Wed, Jun 24, 2009 at 11:39:15PM -0700, William Yardley wrote:
> On Thu, Jun 25, 2009 at 12:25:41AM -0500, Noel Jones wrote:

> Maybe setting $bounce_queue_lifetime to 0 but leaving
> $maximal_queue_lifetime set to 5d+ would do the trick?

[The main issue with this approach is that it will get rid of *all*
DSNs / bounces, even those in $notify_classes; I only want to avoid the
ones due to being unable to connect to $relayhost]

w

Re: best practices for workstations that occasionally disconnect

[Victor Duchovni]

On Thu, Jun 25, 2009 at 12:25:41AM -0500, Noel Jones wrote:

> The best practice for "occasional" fairly brief (less than a couple days) 
> outages is just ignore them.  Postfix should handle things pretty well up 
> to several thousand deferred messages.  If you're expecting tens of 
> thousands of deferred messages, then maybe a script to defer_transports or 
> to put everything on HOLD until the network is back up.

Make that several tens of thousands of deferred messages, but as the
queue starts growing to 100,000+ deferred messages, the congestion can
get too severe (retries of the deferred queue can dominate the active
queue and gum everything up).

-- 
Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:


If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.

Re: best practices for workstations that occasionally disconnect

[Noel Jones]

William Yardley wrote:

I'm just wondering if anyone has a good suggestion for how to deal with
workstations, setup with a $relayhost for all outbound mail, which
occasionally get unplugged from the network or otherwise taken offline.
While this doesn't happen to our machines a lot, it does cause some
annoyance when a machine gets unplugged for a long time and a flood of
messages (and the resulting bounces) come through.


What bounces?  Are you talking about a machine that's 
unplugged longer than $maximal_queue_lifetime but less than 
$bounce_queue_lifetime?


maybe a really long maximal_queue_lifetime would avoid that 
problem.



I could just set $maximal_queue_lifetime and $bounce_queue_lifetime to
really short values, but I'd rather preserve the original mail.


Throwing mail away sooner doesn't sound like a good solution 
to anything.



I guess another approach would be to have a cron job that changes
$defer_transports and reloads Postfix if the network is down (and
reverses it when the network comes back up).


Yes, or just do nothing and let postfix figure it out.


Anyone have a better / less kludgy approach to this problem? Am I just
thinking of it all wrong?


I may not understand what problem you're trying to solve. 
Maybe describe your problem a little better rather than 
proposed solutions.



Disabling DNS lookups doesn't change anything, does it?


No.

The best practice for "occasional" fairly brief (less than a 
couple days) outages is just ignore them.  Postfix should 
handle things pretty well up to several thousand deferred 
messages.  If you're expecting tens of thousands of deferred 
messages, then maybe a script to defer_transports or to put 
everything on HOLD until the network is back up.


  -- Noel Jones

best practices for workstations that occasionally disconnect

[William Yardley]

I'm just wondering if anyone has a good suggestion for how to deal with
workstations, setup with a $relayhost for all outbound mail, which
occasionally get unplugged from the network or otherwise taken offline.
While this doesn't happen to our machines a lot, it does cause some
annoyance when a machine gets unplugged for a long time and a flood of
messages (and the resulting bounces) come through.

We don't mind getting the mail sent while the system is offline, but
(in cases where the sender is "root", which also forwards offsite), we
don't want to get all the bouncse. $notify_classes is set to the
default, but since most of the system messages (cron, etc.) come "from"
root, there's still a single bounce when a message can't be sent.

I could just set $maximal_queue_lifetime and $bounce_queue_lifetime to
really short values, but I'd rather preserve the original mail.

My other thought was to follow the suggestions in
http://www.postfix.org/STANDARD_CONFIGURATION_README.html#dialup

However, since there's no dialup script, I'd probably have to write a
cron job that flushes the queue every minute or two, which seems dumb.

I guess another approach would be to have a cron job that changes
$defer_transports and reloads Postfix if the network is down (and
reverses it when the network comes back up).

Anyone have a better / less kludgy approach to this problem? Am I just
thinking of it all wrong?

Disabling DNS lookups doesn't change anything, does it?

w