Author: Mike Cardwell Date: To: exim-users Subject: Re: [exim] Restricting a user's email destinations?
* on the Fri, Jul 14, 2006 at 07:09:51AM +0800, W B Hacker wrote:
>> iptables -t nat -A OUTPUT -p tcp --dport 25 -d ! 127.0.0.1 -m owner ! --uid-owner exim -j DNAT --to-destination 127.0.0.1
>> Someone might find that useful...
>
> The intent is good, but that specific rule is not necessary on Unix, nor will it
> block outbound traffic.
>
> - ports below 1024 are reserved to 'root' anyway.
>
> - an(y) MTA running as a daemon will have been given that port (by initial
> invocation as root).
>
> - once a daemon has bound to port 25, the next entity (even root) that attempts
> to bind to it will be denied. Demo this by manually attempting to onvoke Exm a
> second time, and tailing /var/log/messages /var/log/maillog,
> /var/log/exim/paniclog (wherever you are logging).
>
> But perhaps most of all - an MTA ordinarily *listens* on port 25, and initiates
> outbound smtp on ports above 1024.
>
> And w/r user-installed mailing code - any port that they can get the use of
> will do.
>
> I'll presume you have a rule eleswhere that blocks that.
What you've just described there doesn't bare any resemblance to what
the iptables rule I wrote does. "man iptables" should help.
>> As for limiting which addresses can be emailed by certain users, you
>> should be able to do this in the acl's.
> - and routers
Routers would probably be better actually yes. That way you don't have
to deal with multiple recipients in the non smtp acl.
>> There are
> at least
At least? We've already determined that exim is the only user that can
now make outgoing port 25 connections. So surely the only way you can
invoke exim to send an email is by connecting to it via a tcp
connection, or running the exim binary... What's the third method of
sending an email using exim...
>> two ways they could
>> send the email, either by calling the exim binary directly, or by making
>> a local connection to port 25. There are different ways to identify the
>> sending user in both circumstances.
> Careful crafting of the exim setup can prevent 'smtp incoming' from other ports
> on your own IP, and control non-smtp as well - long before acl's come into play.
> Careful crafting of routers, with or without acl aid, can add to that control.
Yes it could I suppose. But I don't get how that's a response to my
text, or how it's related to the problem in question...
>> If the sending is being done by calling the exim binary directly, you
>> can access the users uid inside $caller_uid.
>> If the sending is being done by the user connecting to port 25 locally,
>> you should install an identd server and use $sender_ident
> An identd is not required,
Er... I suppose you could force the use of asmtp. Installing an identd
daemon seems the easiest way though.
> and usually brings more headache than relief.
It does? It's one of the simplest services you can have installed. It
just works...
> - properly configured, authentication should be required for any traffic not
> destined for on-host users. Non-authenticated smtp traffic addressed to off-host
> destinations should be treated as unauthorized relay attempts.
Sounds just like my suggestion. Except yours requires each email client
to use authenticated smtp.
> At the end of the day, Exim rulesets can restrict 'proper' users to specific
> destinations and/or prohibit specific destinations.
>
> But the 'challenge' remains that a shell account holder who has either the
> ability to install and use executables or even to simply acess telnet, can
> connect to a destination server without ever touching Exim.
