Re: [exim] Sharing mta

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Lennart Ackermans
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: Re: [exim] Sharing mta
Thanks for your suggestions.

When mail is sent inside containers, the same sendmail binary is used as
outside the containers, so technically itis Exim that's writing into the
queue - nobody is writing directly into the queue. So let me try to clarify
the situation.

The containers run the same linux distro and use the same Exim version and
configuration files. The containers do not and should not run an smtp
daemon. The /var/spool/exim4 directory is shared among containers and host
node. My question is, how does the Exim sendmail binary (which according to
the man page seems to be called "receiving process") tell the smtp daemon
to process emails in the queue? E.g., is there a socket or pipe I don't
know of?

Restricting the container's Exim binaries may not be required for my setup,
but sounds very interesting!

Regards,

Lennart Ackermans

On Fri, Mar 9, 2012 at 5:56 PM, W B Hacker <wbh@???> wrote:

> 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?
>>
>> Thanks.
>>
>> Regards,
>>
>> 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...
>
> Bill
> --
> 韓家標
>
> --
> ## List details at https://lists.exim.org/**mailman/listinfo/exim-users<https://lists.exim.org/mailman/listinfo/exim-users>
> ## Exim details at http://www.exim.org/
> ## Please use the Wiki with this list - http://wiki.exim.org/