> Well your idea for a "listen on local" is very valid and the way to go
> in my opinion, however the keyword "local" is inappropriate here as we
> have a very different meaning for it: a message coming from an address
> that is also the address of a listener.
>
> A network connection from 127.0.0.1 or 192.168.1.1 is local on my box,
> even though it's not coming from the socket.
>
> If we introduced a "listen on socket" of some sort, then we could have
> params applied to the socket + possibly add support for multiple ones,
> we could also differentiate between local sessions initiated on the
> machine and local sessions initiated on the network to apply a finer
> ruleset matching.

That makes sense. So basically a new directive is added to be
supported in smtpd.conf, eg "listen on socket". Then, if this
directive is not present, then smtpd will not accept submission of
smtp messages through local socket connection that come through
smtp_enqueue(), right? Or do we make this enabled by default since
most likely it would be needed by system services that user mail/mailx
commands and this directive becomes the configuration of the local
socket listener?

As far as the name goes, maybe "listen on socket" sounds good from the
client perspective, it makes it evident to the client that they are
not configuring a network interface. Would it be a problem on the
developer side though? In general, I feel that client usability takes
priority here, and this can be nicely documented and described in the
man page.

> This would also solve a problem we have with filters where they are
> applied to network listeners but not to the local socket which requires
> a specific keyword (ok for now since they are experimental).

That would be cool, so if this new local socket listener is created as
part of create_listener() code for example, the filter code should
just work as well without any changes (of course I could be mistaken,
have not looked in the filter support code yet).

> Gilles Chehade
>
> https://www.poolp.org                                          @poolpOrg

Thanks,
--peter

Reply via email to