Ronald F. Guilmette:
>
> In message <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Wietse Venema) wrote:
>
> >Ronald F. Guilmette:
> >>
> >> I'd like to propose a small enhancement for the Policy Server protocol.
> >> I'll code up a first cut of it, if nobody else is willing.
> >>
> >> Basically, I think it would be very useful if the protcol included a
> >> line like:
> >>
> >> trusted_client=[yes/no]
> >>
> >> where the value would be set to "yes" if and only if the client had
> >> either authenticated (SASL) _or_ the client connected from some IP
> >> specified in $my_networks.
> >
> >You are assuming that mynetworks, SASL and TLS will grant identical
> >privileges to the client
>
> I don't believe that I was making such an assumption, but in any case,
> I think the rest of what you said may make that debate moot anyay.
>
> >For this reason, combining multiple different things in one name
> >is not a good idea.
>
> As a general design principal, I would have to agree with you 100% on that.
> But of course, there are always times when one has to be a bit flexible about
> one's design principals, in order to achieve the objective most succinctly
> (e.g. reject_unauth_destination, which combines multiple kinds of checks
> into a single name). But here again, we could save this philosophoical
> debate for another day, because I think what you proposed (below) will
> solve my original problem neatly, and it wouldn't violate your design
> principal.
>
> >Perhaps it is better to extend the existing
> >sasl_ and cert_ attributes where needed
>
> OK. That would work for me. Could I just have something like this?
>
> 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:
permit_mynetworks=yes
reject_unauth_destination=no
reject_rhsbl_sender=yes
reject_non_fdqn_helo=no
> >(for example, sasl_method
> >and sasl_username already tell you if someone used SASL successfully).
>
> Yes. Quite so. So that takes care of the SASL part of the problem. Now
> I'd just like my policy server to have enough information so that it can
> also properly deal with the case where the client is trused on account of
> where he is, not on account of his having been formally authenticated.
Wietse
