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
--
韓家標

--
## List details at 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/

Reply via email to