Univention Bugzilla – Bug 26910
postfix listfilter (erlaubte Sender an eine E-Mailgruppe) wird als Benutzer cyrus ausgeführt
Last modified: 2014-04-30 08:48:47 CEST
Im master.cf wird die listfilter Policy als Benutzer cyrus ausgeführt, außerdem verwendet das Skript selbst /etc/cyrus-ldap.secret für den LDAP Zugriff. In einer Umgebung ohne cyrus funktioniert das alles natürlich nicht. -> Im master.cf sollte der listfilter als Benutzer postfix gestartet werdeb -> univention-mail-postfix sollte im Join Skript die machine,secret nach /etc/postfix-ldap.secret kopieren (Achtung! Passwortwechsel Hook mitbringen) -> listfilter.py sollte dann diese Datei für den LDAP Zugriff per getMachineConnection verwenden
(In reply to comment #0) > -> Im master.cf sollte der listfilter als Benutzer postfix gestartet werdeb Das funktioniert nicht. Aus der Postfix-Man-Page: user=username:groupname The external command is executed with the rights of the specified username. The software refuses to execute commands with root privileges, or with the privileges of the mail system owner. If groupname is specified, the corresponding group ID is used instead of the group ID of username.
In this case, a separate user should be created! This is highly non-obvious and very unpleasant for customers using Zarafa.
The test case 00_base/25check-permissions-etc-secret.test needs to be adjusted: http://jenkins.knut.univention.de:8080/view/Autotest/job/UCS%203.2%20Autotest%20MultiEnv/306/SambaVersion=s4,Systemrolle=slave/testReport/00_base/25check-permissions-etc-secret/test/
univention-mail-postfix now creates a system user listfilter and the listfilter postfix policy is executed as this user. There is also a new secret file "/etc/postfix/listfilter.secret", used by the listfilter policy to get a machine connection. 25check-permissions-etc-secret has been adjusted accordingly. YAML: 2014-03-12-univention-mail-postfix.yaml QA: Please test this in an environment with and without univention-mail-cyrus (e.g., with the zarafa app). The mail restrictions should work in both cases now.
@Jan Christoph The restrictions will still not work in zarafa4ucs. Zarafa sends mails to groups to all the members not to the group. This behaviour bypasses the listfilter policy, but zarafa will work on that, see https://jira.zarafa.com/browse/ZCP-12148 Until this is configurable, we will hide the corresponding attributes (allowedEmailUsers, allowedEmailGroups) in zarafa4ucs.
(In reply to Felix Botner from comment #5) > @Jan Christoph > > The restrictions will still not work in zarafa4ucs. Zarafa sends mails to > groups to all the members not to the group. This behaviour bypasses the > listfilter policy, but zarafa will work on that, see > https://jira.zarafa.com/browse/ZCP-12148 > > Until this is configurable, we will hide the corresponding attributes > (allowedEmailUsers, allowedEmailGroups) in zarafa4ucs. What about incoming e-mails that are delivered from external MTAs? These mails appear to me as a bigger threat than internal group mails that can't be restricted. Am I able to restrict these incoming e-mails even when Zarafa is installed?
(In reply to Jan Christoph Ebersbach from comment #6) > (In reply to Felix Botner from comment #5) > > @Jan Christoph > > > > The restrictions will still not work in zarafa4ucs. Zarafa sends mails to > > groups to all the members not to the group. This behaviour bypasses the > > listfilter policy, but zarafa will work on that, see > > https://jira.zarafa.com/browse/ZCP-12148 > > > > Until this is configurable, we will hide the corresponding attributes > > (allowedEmailUsers, allowedEmailGroups) in zarafa4ucs. > > What about incoming e-mails that are delivered from external MTAs? These > mails appear to me as a bigger threat than internal group mails that can't > be restricted. Am I able to restrict these incoming e-mails even when > Zarafa is installed? I think you are able to reactivate the settings in UMC, see Bug #34323. But by default we have to hide the attributes because it is really confusing.
> What about incoming e-mails that are delivered from external MTAs? These > mails appear to me as a bigger threat than internal group mails that can't > be restricted. Am I able to restrict these incoming e-mails even when > Zarafa is installed? e-mails from external MTAs are correctly checked by the listfilter policy, but not the e-mails from the zarafa webinterfaces. Unless we can configure zarafa to send mails to groups to the groups e-mail address (instead of all the members) we should deactivate the restrictions in zarafa4ucs, because it is really confusing to have a check that depends on from where the e-mail was send.
(In reply to Stefan Gohmann from comment #7) > I think you are able to reactivate the settings in UMC, see Bug #34323. But > by default we have to hide the attributes because it is really confusing. Thanks, that was the answer I was looking for.
OK: policy filter werden mit und ohne installierten cyrus angewendet. OK: Passwortwechsel funktioniert OK: Aufruf Passwortwechsel script im joinscript. -> wichtig im uss-boot OK: 25check-permissions-etc-secret, listfilter.secret hinzugefügt OK: Yaml Noch ein Hinweis zu Zarafa: Als Workaround kann der Haken bei Zarafa Gruppe entfernt werden. Die Gruppe taucht dann nicht in der Zarafa-Kontaktliste auf, E-Mails können aber trotzdem dorthin versendet werden. Dann wird die Policy korrekt angewendet.
http://errata.univention.de/ucs/3.2/99.html