Re: [courier-users] Policy for SMTP access
Gordon Messmer
> That still stalls at RELAYCLIENT being a yes/no value. Tying it to a
> policy might result in some additional features; I can recap three:
>
> * restrict some local users, as in Alexander's quote above;
>
Yeah... by not setting RELAYCLIENT.
> * 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?
> * protect internal addresses: For example, as an alternative to
> Courier's outbox, a user may configure her client to store sent mail
> by adding abcc:user...@example.com. Then the problem is to
> enforce the policy so that only...@example.com 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".
------------------------------------------------------------------------------
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
courie...@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Alessandro Vesely
>> * 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:user...@example.com. Then the problem is to
>> enforce the policy so that only us...@example.com 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?