Univention Bugzilla – Bug 12418
Scalix: Non-Delivery-Reports für unbekannte Mailadressen
Last modified: 2011-12-16 14:17:02 CET
Laut Scalix-Support läuft die Mailauslieferung in der standard Sendmail Konfiguration derzeit wie folgt ab: <Zitat> - Mail an Nutzer, der Scalix namentlich bekannt ist -> von Scalix verarbeitet. - Mail unbekannten Nutzer, dessen Domain Sendmail bekannt ist -> user unknown - Mail an Nutzer in unbekannter Domain -> Smarthost Relay oder MX-Lookup, je nach Sendmail-Konfiguration. - Mail an Nutzer, der lokal auf dem Linux-System existiert, mit einer Domain, die Sendmail kennt -> lokale Zustellung (/var/spool/mail/<user> oder ähnlich) - Mail an lokalen Linux-Nutzer, aber mit unbekannter Domain -> Smarthost Relay oder MX-Lookup, je nach Sendmail-Konfiguration. </Zitat> Bei der Integration in UCS ist dabei der vierte Punkt kritisch, da standardmäßig auf dem Mailserver die Benutzeraccounts bekannt sind. Dadurch werden Mails an lokal bekannte Benutzernamen mit Adressen, die zwar im lokalen Maildomain liegen, aber Scalix weder per mailPrimaryAddress noch emailAlternativeAddress bekannt gegeben sind, von sendmail als lokal erkannt und nach /var/spool/mail ausgeliefert. Konzeptionell ist das Problem, daß Sendmail sich für Domains verantwortlich fühlt, Scalix allerdings generell nur für einzelne Adressen. Um Sendmail anzuweisen, pro Addresse zu entscheiden, kann man das 'ldap_routing' Feature von Sendmail verwenden. Etwas ähnliches macht auch Scalix, um Adressen umzuschreiben, man kann jedoch auch mit 'reject' antworten, wenn die Adresse nicht per LDAP gefunden wird: LDAPROUTE_DOMAIN_FILE(`/etc/mail/local-host-names') FEATURE(`ldap_routing',`ldap -h localhost -p 5757 -b "" -1 -T<TMPF> -M simple -v scalixInstanceName -k (mail=%0)', null, `reject')dnl Abgewiesen würde dadruch auch "postmaster@<domainname>", wenn man es nicht im LDAP als Adresse einträgt (könnte auch in einem extra-Attribut geschehen). Für 'root' und andere lokale Adressen, die nicht im Scalix-LDAP Stehen muss man dann vermutlich auch eine Alias anlegen. Da Scalix perspektivisch seinen LDAP-Server abschalten will, wäre ggf. sinnvoll statt dessen direkt den UCS-Verzeichnisdienst zu fragen, vermutlich mit: FEATURE(`ldap_routing',`ldap -h localhost -1 -T<TMPF> -M simple -v mailPrimaryAddress -k (&(mailPrimaryAddress=%0)(mailAlternativeAddress=%0))', null, `reject')dnl Das Vorgehen ist analog zu der Transports-Map in univention-mail-postfix-kolab2. Zusätzlich sollte Bug #11539 mit gefixed werden.
Die Pflege von Scalix4UCS soll direkt durch Scalix erfolgen: http://www.univention.de/univention/presse/pressemitteilungen/univention-und-scalix-definieren-kooperation-neu/ Hier ist von uns keine weitere Aktion notwendig, deshalb WONTFIX.