Gordon Messmer wrote: >> * whitelist forwarders, as in my quote above; and > > I'm not even really sure what you were suggesting. You can use > RELAYCLIENT to allow forwarding without authentication, or rely on > authentication to control forwarding. This seems to be much more > complicated in your mind than you are communicating. Could you > enlighten us what kind of "restrictive policy" you had in mind?
I'm thinking of an external forwarded; mildly trusted, in the sense that it may blindly forward messages to one (or some) of our local users, but we would never grant it relaying. The forwarder is whitelisted after it authenticates, but then it can only send those forwarded messages that we gave it a userid for. It could be a single local address, and only that. Or, if it forwards for more users at ours, perhaps we could get away with a single userid for targeting any of them, rather than giving the same sender a different userid for each forwarding recipe it has: The granularity of the restriction has to match the forwarder's esmtpauthclient granularity. >> * protect internal addresses: For example, as an alternative to >> Courier's outbox, a user may configure her client to store sent mail >> by adding a bcc:[email protected]. Then the problem is to >> enforce the policy so that only [email protected] can send mail to >> her Sent folder. More use cases may come to mind, e.g. guard >> children's mailboxes, limit a vip's direct reachability, et cetera. > > Now you're talking about accepting mail to local addresses, which is > completely unrelated to controlling relaying mail. A policy mechanism > exists for that already. It's documented as "localmailfilter". Yup, that's correct. However, a policy that says how to do depending on the authenticated (or anonymous) sender and the target recipient, overlaps with localmailfilters quite "naturally". Maybe. It may be more or less convenient to configure. Just thinking freely. To control forwarders that way requires some other extra-SMTP implements (applying for and granting those userids, e.g.) That might then result in a policy affecting both incoming and outgoing messages. The question is, would such a policy be useful in general --that is, beyond controlling forwarders? ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
