Viktor Dukhovni:
> On Sun, Jan 30, 2022 at 03:33:16PM +0100, Christoph Pleger wrote:
>
> > > You're mistaken. On input, Postfix provides no LMTP server, and no
> > > support for receiving messages from external programs via unix-domain
> > > sockets.
> >
> > I have the following line in master.cf:
> >
> > usmtp unix n - - - - smtpd
>
> I forgot about that. In this case smtpd(8) pretends it got a connection
> from "localhost" and proceeds accordingly. Runnin smtpd(8) in this way
> may not be officially supported.
The SMTP daemon fakes a hard-coded localhost[127.0.0.1] so as to
keep everything from blowing up, but otherwise I don't recall that
the docs make any promise that this will work.
> A program with sufficient privileges to access /var/spool/postfix/public
> (restricted to the $mail_owner user and/or $setgid_group group) can
> inject messages via that UNIX-domain socket, and you can even specify
> some other directory via e.g.
Any program that has access to the public dierctory
> ../ext/usmtp unix ...
Hmm. Postfix uses some service names as prefixes for parameter
names (time limits etc.) and having parameter names starting with
"../ " seems a bit gross to me.
Perhaps the time has come to get away from giving non-Postfix
programs access to a directory with Postfix internal sockets.
We could redesign the master.cf 'private' field, so that for
UNIX-domain sockets:
master.cf directory mode
y private 0700 (no change)
n protected 0710 (was: public)
x public local policy
Postfix sockets are moved from the 'public' to the 'protected'
directory, and the 'public' directory no longer contains any Postfix
sockets.
Then we can remove the 'public' directory from /etc/postfix/postfix-files,
and leave the dirctory owner/group and permissions up to local
policy. Each application can have its own subdirectory under 'public'
with permissions that allow access to only that app and postfix.
With inet sockets, 'y' and 'n' behave as before, and 'x' behaves
like 'n'.
Wietse
