[systemd-devel] exim4 only queues mails sent by systemd service
Mantas Mikulėnas
grawity at gmail.com
Mon Sep 24 16:51:39 UTC 2018
On Mon, Sep 24, 2018, 16:29 Kamil Jońca <kjonca at o2.pl> wrote:
> Lennart Poettering <lennart at poettering.net> writes:
>
> > On Mo, 24.09.18 12:04, Mantas Mikulėnas (grawity at gmail.com) wrote:
> >
> >> > Uh, this looks like something you need to ask the exim community,
> >> > systemd can't make exim mail queueing decisions, that's entirely
> >> > internal to exim.
> >> >
> >> > One question though: are you sure you have started the exim service
> >> > properly beforehand? I am pretty sure exim won't process the mail
> >> > queue if it's not running...
> >>
> >> exim's a bit oldschool, and whenever you pipe a message to 'sendmail',
> it
> >> immediately forks a worker to deliver the message synchronously,
> regardless
> >> of the main daemon running.
> >
> > Uh, what? Are you saying exim is forking off privileged daemon code
> > from unprivileged user command invocations? Christ, that's ugly. They
> Yes. exim is suid root to deliver mails.
>
> > really really shouldn't do that.
>
> But they do.
>
> >
>
> > It appears to me exim should figure out some way how clients such as
> > 'sendmail' invocations can trigger queue dispatching some other way,
> > for example, by making exim listen on some IPC of some form, or using
> > inotify or anything else.
> IIRC postfix is written that way, but I want to use exim, as it is more
> configurable.
> KJ
>
When I was writing exim systemd units for Arch a few years ago, I
experimented with using queue_only=true and no permanent daemon at all, but
triggering the queue runner via systemd.path units (start as soon as spool
is non-empty) and timers (to replace the usual -q15m).
.path units are inotify-based and can start exim as soon as
/usr/bin/sendmail puts something in the queue.
This didn't work well enough IIRC, but if it did, then it'd provide almost
postfix-like architecture.
--
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180924/afe87457/attachment.html>
More information about the systemd-devel
mailing list