[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: switching from exim to postfix

As I'm not involved in developing dma at all, neither upstream nor in
Debian, I'm not the right one to discuss implementation details in depth

* Russ Allbery [2012-04-29 17:32 -0700]:
> Adam Borowski <kilobyte@angband.pl> writes:
> > On Sun, Apr 29, 2012 at 10:50:45PM +0200, Carsten Hey wrote:
> >> Looks like the DragonFly Mail Agent (dma), which already has been
> >> mentioned in this thread, could become a decent default for Wheezy+1
> >> after some small changes.
> >>
> >> In a nutshell: it's able to deliver locally and remotely, has a queue,
> >> supports TLS/SSL, does not listen on port 25 and instead of running as
> >> daemon, it if run every 5 minutes via cron to flush the queue.
> > I hope you mean: to run retries (in which case every 5 minutes is an
> > overkill).
> > Delaying every outgoing mail by 5 minutes doesn't sound like a good idea
> > to me.
> ... incron ... You'd still need timed handling of queued mail for retries.

There are two modes dma can run in, one is the deferred mode, which
seems to be basically how you think dma always works.  The other is the
immediate mode that is default in Debian and upstream and as the name
suggests it delivers immediately if possible and it forks for mails that
can not be delivered immediately.  The resulting processes then handle
besides obvious other things the timed handling of queued mail for

The rest of this mail is likely not interesting for most of you since it
only tries to answer the natural follow up question "Why does it need
a cronjob then?" and explains why I don't think anymore that a switch to
incron should be considered.

Two reasons for running dma -q via cronjob in my own words but stolen
from README.Debian are:
 * If the queue is not empty after reboot, dma -q needs to be run at
   least once to start delivering these mails.  A @reboot cronjob or an
   init script would also to this job.
 * Delivery processes might die for various reasons, but the mails still
   need to be delivered in a timely manner.

If dma would be the default MTA, then it should IMHO be as reliable as
possible and even try to prevent user errors.  If a user would
unintentionally enables deferred mode (which is useful if you are behind
a dial-up line) but would not set up dma -q to run periodically, then
the mails would not be delivered without such a default cronjob.
A comment that reminds users to adapt the cronjob if needed should be
added to the config file.  If dma -q is run every 5 minutes be default
anyway, the option -bq does not make that much sense anymore; this can
possibly be solved by implementing different ways of processing queued
mails.  All in all, enabling the cronjob by default, as it is already
done in Debian, seems to be sane.

> I think that was Carsten's point about switching to incron, which
> would then do the right thing for new outgoing mail.

This is a reasonable and logical assumption, but it is wrong ;)

Actually the reason to mention incron was that I thought that running
dma -q if triggered by inotify could be a bit cheaper than running it
every five minutes.  For a default MTA, the amount of systems that run
it could make considering even minimal differences in efficiency

The idea was to use incron to restart failed delivery processes, if this
would be possible at all depends on details of dma and incron/inotify
I'm not aware off.  An additional reason to the explanation above not to
use incron is that in rare cases dma might fail for example with ENOMEM
whilst reading its configuration file before it is able to open any file
in the spool dir, which would render running it by incron to be not 100%
bullet proof anyway.


Reply to: