On Mon, Feb 08, 2016 at 08:32:31PM -0500, Peter Bisroev wrote: > Dear OpenSMTPD Developers! >
Dear Peter, > I think there is a little "bug/feature" with respect to handling "mask-source" > parameter with "listen on" directive in smtpd.conf. The behavior makes perfect > sense from the perspective of documentation. Unfortunately it is not uniform > from the perspective of the client. > You are right, the feature will apply to network connections only. > Basically, if the message is handled through smtp_accept() in smtp.c then > everything works as expected. If the message is enqueued from localhost (for > example through sendmail), the message is handled by smtp_enqueue() in smtp.c, > [...] > option for the "listen on" loopback interface directive. I suspect that if > mask-source is on for lo0, the client would probably want the same behavior > for the messages submited through the local queue. > You are correct. > I think this situation can be handled in one of three ways. A new special > directive can be created to influence the creation of this listener, however, > this feels a little messy. Another approach, is to create support for > "listen on local" or similar, which makes everything a bit more uniform. And > the last approach could mimick what "listen on lo0" or any other loopback > device does and apply the same policy to the "local" listener. For example, > this can be implemented by searching through env->sc_listeners for loopback > listeners, and if any of them have F_MASK_SOURCE flag, apply it to the local > listener as well. > > What are your thoughts? I am more than happy to provide the patch for any of > the above described scenarios assuming they would provide an adequate > solution. > We have faced a similar issue with filters and my thoughts are that we need a listen on socket of some kind, similar to your listen on local. This has several benefits over "listen on local", both in ambiguity and it new ways the ruleset can match sessions. If you're interested to work on it, I'd be happy to discuss this with you so you can come up with a diff :-) -- Gilles Chehade https://www.poolp.org @poolpOrg
