[Kolab-devel] [issue1779] kolab 2.1 private/kolabpolicy: Socket operation or non-socket

[Alain Spineux]

On 6/21/07, ComCept Net GmbH Andrea Soliva <soliva at comcept.ch> wrote:
>
> Hi all
>
> Now I found a solution but this solution is probably dirty.
> Troubleshooting
> has brought up the issue meaning in main.cf.template is defined following:
>
> ## Kolab Policy Server
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated,
>         reject_unauth_destination, reject_unlisted_recipient,
>         check_policy_service unix:private/kolabpolicy
> smtpd_sender_restrictions = permit_mynetworks,
>         check_policy_service unix:private/kolabpolicy
> kolabpolicy_time_limit = 3600
> kolabpolicy_max_idle = 20
>
> Here is the issue meaning after successful authentication the request
> would
> be forwarded/hand over to unix:private/kolabpolicy and here we have the
> issue that postfix can not talk to privat/kolabpolicy if the user comes
> from
> outside world (funny that it works if the users comes from trusted
> network).
> Probably this has something to do with the implemenation of zones under
> Solaris 10. I changed also the position to inet but in this case all users
> are not anymore able to deliver mails. At least I fully commented out the
> positions meaning:
>
> ## Kolab Policy Server
> smtpd_recipient_restrictions = permit_mynetworks,
> permit_sasl_authenticated,
>         reject_unauth_destination, reject_unlisted_recipient
> #        check_policy_service unix:private/kolabpolicy
> smtpd_sender_restrictions = permit_mynetworks
> #        check_policy_service unix:private/kolabpolicy
> kolabpolicy_time_limit = 3600
> kolabpolicy_max_idle = 20
>
> If this would be done all users including the outside world user can
> deliver
> mails through kolab2. I do not know what private/kolabpolicy is
> responsible
> for etc. but I can imagine that from security point of view it would be
> worse.


No because to reach this peace of code, your user must be authenticated :-)
It verify that a authenticated user donnot use the identity of someone else.
The Form field should be the same as the login name.


Can somebody explain me what this position does? Is there a way to
> change this meaning that unix:private/kolabpolicy would be handled in
> another way?
>
> In the meantime I will proceed with 2.2.0beta1 but I'm pretty sure I have
> also with this version the issue.
>
> Any help really appriciated.
>
>
> Andrea
>
>
>
>
>
>
> Bernhard Reiter <bernhard at intevation.de> added the comment:
>
> Thomas, Steffen,
> are we sure that this is working on non-solaris machines?
> What would be the next debugging step for Andrea?
>
> ----------
> assignedto:  -> thomas
> nosy: +bernhard, steffen, thomas, wilde
> status: unread -> chatting
> topic: +server
> ________________________________________________
> Kolab issue tracker <kolab-issues at intevation.de>
> <https://intevation.de/roundup/kolab/issue1779>
> ________________________________________________
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
--
Alain Spineux
aspineux gmail com
May the sources be with you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20070621/b0d4f01e/attachment.html>