Thomas wrote:
Hello,
i try to figure out how to restrict ACCESS to the SMTP daemon.
With that, i mean something like the tcpwrapper for SMTP/SMTPS ...
I found that about a similar solution:
http://archives.neohapsis.com/archives/postfix/2007-05/0343.html
There, the following is written:
########
There's no real need to run a proxy in-between in this scenario.
If you really want to have some control over connections before they're
handled
to postfix, use "standalone smtp" mode. Like this (inetd.conf):
smtp inet stream nowait postfix.postfix accept-conn -deny=/file/deny
-run=/usr/lib/postfix/smtpd -S ..
There are two drawbacks:
1) this your pre-accepting server has to run smtpd as postfix user.
Which means either it is running as postfix itself, or (worse) as root.
2) this approach requires fork+exec for each (non-blocked) connection.
And another approach, which eliminates both drawbacks, is to use
(unfinished)
passfd "port". Here's the patch for 2.3:
http://www.corpit.ru/mjt/postfix-2.3.2-passfd.diff
and for 2.4.0:
http://www.corpit.ru/mjt/postfix-2.4.0-passfd.diff
And here's a tiny program - a client side:
http://www.corpit.ru/mjt/sendfd.c
It works like this. In master.cf, instead of
smtp inet ... smtpd
use
smtpd pass ... smtpd
This will create /var/spool/postfix/public/smtpd AF_UNIX socket.
Now, continuing the above example:
smtp inet stream nowait nobody.postdrop accept-conn -deny=/file/deny
-run=sendfd /var/spool/postfix/public/smtpd
Which will just pass on the connection to postfix.
I wonder why this `pass' port type support is commented-out... ;)
#######
That mail was from 2007 - maybe there is now a better way to handle such
a situation?
BTW, i never figured out that inetd/xinetd may be such a bad way to
start programs!
At least, programs that do not run as root normally ...
