Liam:
> On Sun, Nov 7, 2010 at 5:13 AM, Wietse Venema <wie...@porcupine.org> wrote:
> > There are fundamental problems with on-demand delivery from the MTA
> > queue. There is a basic mis-match, because the typical MTA queue
> > (not just Postfix but any MTA that I am familiar with) is NOT
> > designed to be used as medium-term message store.
> >...
> > It would be much more efficient to deliver the mail from the MTA
> > queue to per-webclient intermediate "queues". Those intermediate
> > queues can be delivered quickly, on-demand, when a websocket client
> > comes along. Kind-of like using an IMAP message store.
> >
>
> Wietse, thanks for the discussion of MTA queuing design.
>
> In my case, most of the nodes are connected during most of the hours when
> they are likely to be mailed. So on-demand delivery isn't the general mode,
> it's maybe 15% of messages. Also the number of deferred msgs per node is
> typically <20. Is that a tolerable scenario?
The number of messages per client is not the problem. The problem
is having 15% of the daily email volume sitting in the mail queue.
These deliveries are relatively expensive and can end up dominating
the over-all system load.
> However, due to the unreliability of the connections, delivery transactions
> may be relatively slow and fail more often than typical of a backbone-linked
> SMTP service.
The Postfix scheduler tries to avoid sending mail to a destination
that is known to be down. That avoids wasting resources that could
be used to deliver mail to destinations that are up.
It sounds like you will be sending all mail to the same outbound
proxy, meaning that Postfix has no clue what destinations are up
and what are down, because that is hidden by your outbound proxy
(it just returns a 4XX error when delivery fails).
To make Postfix's back-off strategy work, you'd actually have to
hack the LMTP client and make it use your proxy's name or IP address,
so that the Postfix scheduler believes it is delivering to the
final destination.
For this to be a supported feature, it should be implemented with
a lookup table that is called by the delivery agent to override
the next-hop destination. Usage would be like:
lmtp -o nexthop_override_maps=static:192.168.254.2
> If I turn on postfix's per-domain lists of queue id's for all my nodes,
> there will be a LOT of rather short lists. Is that likely to cause problems?
It is just as bad as having 20 times that number of messages in
the mail queue.
These lists are per destination (i.e. they are maintained for the
destination that was down when Postfix tried to deliver to it). In
your case, all Postfix mail is destined for your outbound proxy
host, so all information would be appended to the same file.
Again, to make the per-destination lists work you'd actually have
to hack the LMTP client and make it use your proxy's name or IP
address, so that the Postfix scheduler believes it is delivering
to the final destination.
Wietse
