Author: W B Hacker Date: To: exim users Subject: Re: [exim] Sharing mta
Lennart Ackermans wrote: > Hi,
> I'm trying to share a single Exim smtp daemon on the host node on multiple
> virtual servers (openvz containers). Users in containers should only be
> able to send emails. What I have done so far is sharing the mail spool
> directory on the host node with all containers. However, when a message is
> sent inside a container it is not processed until runq on the host node is
> ran. So what does Exim's "receiving process" do to tell the daemon it
> should process the queue?
> Lennart Ackermans
Unless set to 'queue only', the master process or 'listener', having
spawned a 'child process' to handle a given arrival, expects each of
those potentially many such children to trigger a queue run as its last
act efore retiring.
When you write direclty into the queue, all you 'could' do is fire a
queue run with your external. IF it has the privs to call the Exim
binary at all..
I'd vote against all of that entirely.
What is 'safer', IMNSHO, than giving them privs to drop s**t directly
into the queue's fs, is to have each of those externals call [the | AN]
exim binary WITH restrictions, and code any steering and ring-fencing
into an acl_not_smtp structure.
Safer YET is to have them execute a full-court-press smtp session, even
though it is cross-same-box. I've always run MLM this way.
What you can do then is have Exim listen on, and the 'cousins' aimed at,
an internal-only, non-routable IP:PORT ifconfig'ed or aliased-up for the
purpose, be it to a hardware NIC or virtual.
One can THEN establish very different IP:PORT arrival based rulesets for
such traffic, and it is harder for one of them that may lose the faith
to do harm.
YMMV, but no one but Exim writes into MY queue...
This message was posted to the following mailing lists: