Re: [exim] Sharing mta

Lennart Ackermans wrote:
> Aah, I was incorrectly assuming before that the smtp daemon would take care
> of sending all outgoing emails. (As a sidenote, is there not some logic in
> my way of thinking: why would a program so complex allow setuid as root?)

Short answer is so it can:

A) Grab the (ordinarily) 'privileged' ports it needs and

B) change identities to do delivery.

Neither are absolute requirements.

Exim can be 'handed' the port by a management toolset - several of which
exist for that sort of need - AND/OR the few ports it needs may be
'conveyed' to it (and no other) at a less-than-root level.

Exim can also deliver or otherwise work with storage under a 'lesser'
privileged ID than root, simply by careful assignment and use of 'group'
privs. Add-in OS tools of 'noexec' and 'nosuid' mounting of parts of the
storage, and life gets quieter.

But all that can be extra work, and IF not carefully implemented, make
security worse, not better. Do your homework thoroughly before moving
off the 'vanilla' model.

>
> Anyways, this means I have to rethink my setup. The considerations are:
> route outgoing smtp traffic from the containers correctly to the internet,
> make some construction to allow containers to spawn sendmail on the host
> node or use an smtp connection from container to host as Bill Hacker
> suggested. Feel free to comment. Thanks for your help so far.
>
> Regards,
>
> Lennart Ackermans

An 'acl_not_smtp' being the equivalent of STARTING already at the 'DATA
phase (there being no 'session', and nothing apparently to be gained as
all the bytes to be handled really ARE already 'on box'), is not a weak
tool. But ..

..HAVING a 'full' smtp session, even if only cross-box (in and out of
the stack/loopback interface, OR a physical NIC, cabled or not,
internal-only or not, gives back 'the rest of' the tools we are
accustomed to having. I can then craft IP and/or port relevant rulesets
in a more familiar manner, and from 'conect' onward, not just 'data'.

And/or ACTUALLY run that traffic off to a different box, and via one of
more firewalls, 'throttles', traffic shapers, rate-limiters, etc.

Flexibility isn't REALLY all that greater - but it makes re-use of the
more common and well-proven techniques easier.

Bill
--
韓家標