Hello Steffen,
The bug is not in policyd configuration but in Postfix, as I found out
(It's not a bug, it's a feature).
In all howtos to policy services (also in postfix itself) it is written,
that you have to put "check_policy_service" AFTER
permit_sasl_authenticated, because you could become an open relay
othewise (which is right, if the policy service is coded badly and
returns PERMIT or OK to postfix....
Explanation:
A policy services returns to postfix the text "REJECT and some message",
in case, postfix shall reject the email. If the email is ok from the
policy's point of view the service has to return the text "DUNNO", what
means, continue in the chain to the next rule.
permit_sasl_authenticated returns "OK" or "PERMIT", as written in the
postfix docs and thus terminates the chain, i.e. check_policy_service is
never reached, if somebody has logged into with sasl authentication, it
is reached only, if the email is received WITHOUT sasl authentication.
In case of permit_sasl_authenticated relaying is without limits, even if
you have activated check_policy_service!!!!!
I would therefore put check_policy_service BEFORE
permit_sasl_authenticated, in which case the policy service is called
each time, an email is received.
This is my smtpd_recipient_restrictions section (I have working inbound
and outbound quotas):
smtpd_recipient_restrictions =
reject_unlisted_sender,
reject_sender_login_mismatch,
## localhost and LAN (if required)
permit_mynetworks,
## NOW check, if the user is not sending
## too much emails, block, if so
## this service has to return "DUNNO", if permitted
check_policy_service inet:127.0.0.1:10031,
## permit, if quotas ok and logged in
## the processing chain stops here if sasl_auth...
permit_sasl_authenticated,
## all other relaying is denied,
## only emails to our own mailboxes are accepted
reject_unauth_destination,
## the recipient is on our server
## lets do other inbound checks
## e.g. blacklists etc...
Hope, that I could help you.
Kind regards
Christoph
Am Sonntag, den 03.11.2013, 19:13 +0100 schrieb Urban Loesch:
> Hi Steffen,
>
> you can put "check_policy_service,inet:127.0.0.1:10031" in your "smtps"
> section in "master.cf" after "smtpd_client_restrictions=" and then
> restart postfix. This should activate policyd for smtps on port 465 too.
> Check your logs after restart to be sure all is running correctly.
>
> Are you sure roundcoube connects via smtps to postfix and smtps?
> The first row of the logs below say something else. "uid=33" tells me
> that the mail was submitted by the webservers user id. On Debian user id
> 33 is the user on which apache is running (www-data).
>
> Am 03.11.2013 17:41, schrieb Steffen Wegner:
> > Nov 3 17:08:17 server1 postfix/pickup[3329]: 76EB034006F: uid=33
> > from=<[email protected]>
> > Nov 3 17:08:17 server1 postfix/cleanup[6730]: 76EB034006F:
> > message-id=<[email protected]>
> > Nov 3 17:08:17 server1 postfix/qmgr[1843]: 76EB034006F:
> > from=<[email protected]>, size=522, nrcpt=1 (queue active)
> > Nov 3 17:08:17 server1 postfix/smtp[6736]: 76EB034006F:
> > to=<[email protected]>, relay=mx-ha03.web.de[213.165.67.104]:25,
> > delay=0.44, delays=0.03/0.01/0.2/0.21, dsn=2.0.0, status=sent (250
> > Requested mail action okay, completed: id=0M71LJ-1VpQMm3FJN-00wknM)
> > Nov 3 17:08:17 server1 postfix/qmgr[1843]: 76EB034006F: removed
>
>
> If I read your logs correctly it seems that roundcube does not connect
> via smtps, but it uses the local php mail function.
> See here for a explanation of local submissions:
> http://www.postfix.org/OVERVIEW.html
>
> I have no experience with roundcube but you should check your roundcube
> config to see if it uses the local sendmail command or really the smtps
> port 465.
>
> Reagards
> Urban
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> [email protected]
> http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
--
Mit freundlichen Grüßen
Christoph Christ
CHCNET | Am Röhrgraben 2, A-2410 Hainburg/Donau
Phone: +43-1-3361333 | Fax: +43-1-3361333-339
UID-Nr: ATU61214947
_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
