Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Wietse Venema (wietseporcupine.org)
Date: Thu Aug 21 2008 - 17:08:52 CDT
Ronald F. Guilmette:
> In message <20080821012151.05B831F3EA1spike.porcupine.org>, Wietse wrote:
> >Ronald F. Guilmette:
> >> client_in_my_networks=[yes/no]
> >That might work (under a better name) but it should not encourage
> >requests to simply dump all the low-level Postfix predicates in
> >the policy protocol:
> Well, it's purpose is limited to just what I stated, which is likely to
> be a common problem/issue for many folks building policy servers, i.e.
> differentiating properly between "incoming" and "outgoing". So I doubt
> that it would be a basis for anybody asking for anything more. (But
> you never know.)
I doubt whether one can report in a policy protocol attribute
whether or not a client TLS certificate would grant mail relay or
other privileges; ditto with "pop before SMTP" and other mechanisms.
I also don't think that it makes sense to "bolt on" the concept of
inbound and outbound mail onto Postfix, because it was explicitly
designed not to have such a concept.
When a remote user sends mail to userporcupine.org, and when a
local porcupine.org user sends mail to that same address, it makes
no sense to call one inbound and the other something different.
Instead of inbound/outbound, Postfix uses the concept of mail relay
authorization in the SMTP server.
If the policy protocol is to provide the information needed to
determine mail relay authorization, then it would have to list all
the configured smtpd_recipient_restrictions as policy protocol
> So anyway, should I take a whack at trying to code up an implementation
> of this new protocol parameter and then send you some code patches for
> review? Or would you prefer just to take the ball and run with it yourself?
> Either way is fine by me.
I have no time, but I can proofread and suggest improvements.