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 with.
* Russ Allbery [2012-04-29 17:32 -0700]: > Adam Borowski <kilob...@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 retries. 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 worthwhile. 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. Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120430095818.ga6...@furrball.stateful.de
