Tutorial Fehlermeldungen - Setting up Univention to allow multiple e-mail addresses per user

mail
kopano
german
postfix

#1

@fbartels

Zusammen,

Ist dieses Tutorial noch aktuell mit dem UCS 4.2.2?
ich habe das Tutorial von hier peinlich genau auf einer neuen VM befolgt, leider bekomme ich trotzdem
Fehlermeldungen, dass fängt schon beim erstellen der folgenden Dateien an.

/etc/postfix/sasl_password
/etc/postfix/sender_dependent
/etc/postfix/sender_canonical

wenn ich dann ein postmap absetze spuckt er den Fehler wie folgt aus (hatten auch schon andere Anwender):

postmap: warning: /etc/postfix/main.cf, line 102: overriding earlier entry: sender_dependent_relayhost_maps=yes

Wenn ich testweise in der main.cf die eine Zeile sender_dependent_relayhost_maps = yes auskommentiere gibt es mit postmap keine Fehler mehr.
Kann es sein, dass der Eintrag falsch ist oder doppelt gemoppelt, da ja weiter unten noch mal auf die sender_dependet hingewiesen wird?

Dann geht es mit 'ucr set mail/maps/transport/adomainmails="adomain.com smtp:[smtp.provider.com]"'
mit diesem Kommando kann jeweils nur ein Eintrag erstellt werden, wenn man mehrere Server eingibt, wird der schon vorhandene durch den neuen ersetzt.
Muss die transport nicht auch mit postmap gemapt werde?
Müsste ja eigentlich in die transport.db geschrieben werden?

Wenn ich dann versuche mails an ein google Testmail Account zu versenden gibt das Mailsystem immer dieses zurück
Undelivered Mail Returned to Sender von Mail Delivery System

Unfortunately, I was unable to deliver your mail to the/some of the recipient(s).
You may need to contact your e-mail administrator to solve this problem.

Recipients that failed permanently:
	 <hh@gmail.com>

oder wenn es an eine andere Domain geht die nichts mit google zu tun hat von MAILER-DAEMON@domain.intranet

This is the mail system at host ucs.domain.intranet.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.
 The mail system

<mail@domain-name.de>: host mail.domain-name.de[178.254.4.101] said: 550-host
    xxx.xxx.xxx.xxx is listed at zen.spamhaus.org (127.0.0.10); see 550
    https://www.spamhaus.org/query/ip/84.133.41.104 (in reply to RCPT TO
    command)

Hatte eigentlich die Hoffnung, dass die Anleitung out of the box umzusetzen ist.

Gerne liefere ich dazu noch Logfiles wenn gewünscht…habe nur zwei drei Ausschnitte hier um es nicht unnötig aufblähen.

Z.Bsp. steh in der /var/log/mail.info
Apr 26 11:09:38 ucs postfix/smtpd[4410]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 <hh@gmail.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<mailtests@gmail.com> to=<hh@gmail.com> proto=ESMTP helo=<ucs.domain.intranet>

oder unter /var/log/kopano/spooler.log

Wed Apr 26 11:01:05 2017: [error  ] [ 4291] SMTP: Error while executing command 'DATA'. Response: 554 5.5.1 Error: no valid recipients
Wed Apr 26 11:01:05 2017: [warning] [ 4291] E-mail for user haraldtest could not be sent, notifying user: cancel message (40580)
Wed Apr 26 11:09:37 2017: [error  ] [ 4407] Unable to create store entryid for representing user 'gmailsend': not found (8004010f)
Wed Apr 26 11:09:38 2017: [error  ] [ 4407] RCPT line gave SMTP error 550 5.1.1 <hh@gmail.com>: Recipient address rejected: User unknown in virtual mailbox table. (no retry)

Die Mail an die andere Domain steht nur im spoller.log

Wed Apr 26 11:09:38 2017: [error  ] [ 4407] SMTP: Error while executing command 'DATA'. Response: 554 5.5.1 Error: no valid recipients
Wed Apr 26 11:09:38 2017: [warning] [ 4407] E-mail for user haraldtest could not be sent, notifying user: cancel message (40580)

Beste Grüße Carmen


#2

Die andere Frage die mich gerade noch rumtreibt is, inwieweit funktioniert dass beschriebene Setup dann via Activesync von mobile Geräten.
Hat dass jemand so umgesetzt und kann was dazu sagen?

Einen schönen Tag Carmen


#3

Hallo @ckraut,

ich habe das Tutorial selber nie ausprobiert und kann daher nichts dazu sagen.


#4

@fbartels Danke für die Info…schade, dachte nur, da Ihr NAme als Autor drüber stand…

Viele Grüße C.


#5

Nein, ich hatte tatsächlich nur die Seite angelegt, tatsächlich mit Leben gefüllt wurden diese von @rob (hoffe ich habe den richtigen Benutzernamen erwischt, finde leider den Ursprünglichen Thread gerade nicht).


#7

Hallo,
ich bin derjenige, der das Tutorial geschrieben hat. Leider habe ich seither keine Zeit gehabt von meinem alten Zarafa ganz zu UCS/Kopano umzuziehen. Bei den Updates von UCS habe ich gesehen, dass seit UCS 4.2 und Kopano 8.2 die von Carmen beschriebenen Fehler auftauchen. Das macht mich auch nicht glücklich, ich hatte jedoch noch keine Not mich darum zu kümmern, denn meine Mails laufen ja noch alle auf der alten Installation.

Sobald ich dazu komme mache ich einen Vermerk ins Tutorial (Hab’ da gerade ein Login-Problem) und werde es aktualisieren, wenn ich soweit bin.


#8

Also ich hab’ mich doch gleich damit befasst und habe folgenden Hinweis:

Für jede Domain muss das Kommando unten ausgeführt werden.

ucr set mail/maps/transport/adomainmails=“adomain.com smtp:[smtp.provider.com]”

Dabei ist für jede Domain eine andere Bezeichnung ‘adomainmails’ zu wählen. Also nur als Beispiel, gogglemails=“goggle.de smtp:[smtp.goggle.de]”, webmails=“web.de smtp:[smtp.web.de]”. Dann werden die Einträge auch nicht überschrieben. Das wird aus dem Tutorial vielleicht nicht klar genug.

Die Einträge, die wie oben über die Univention Registry angelegt werden, müssen nicht gemappt werden. Wenn Sie sich /etc/postfix/transport ansehen, dann steht da drin, dass die Datei automatisch angelegt wird und daher wird auch für das Mappen automatisch gesorgt. Natürlich darf ‘postfix reload’ nicht vergessen werden.

Bezüglich der Warnungen in main.cf denke ich, dass sie von einer neuen Postfix Version kommen, die es noch etwas genauer nimmt, und das Auskommentieren reichen wird.

Leider kann ich noch keine Lösung anbieten. Mir scheint, dass der Hauptfehler dadurch gekennzeichnet ist:

Beim googeln dazu bin ich auf https://superuser.com/questions/743769/recipient-address-rejected-user-unknown-in-virtual-mailbox-table-when-sending gestoßen. Dort steht:

If it happens immediately when trying to send (as opposed to coming back later in a bounce message from a mailer-daemon), it would mean that your SMTP server “thinks” of itself as the final destination for the domain of your client.

Eventuell hat die Registrierung der Domains unter UCS etwas damit zu tun, ich weiß es aber noch nicht. Vielleicht hilft das ja weiter, denn heute kann ich nicht weiter daran sitzen.


#9

Hi @rob,
sorry dass ich mich erst heute melde, dass ist große Klasse, wie Du gleich reagierts.
Großen Dank an Dich…ich muss mir dass in Ruhe ansehen, sobald ich zu Hause bin.
Was mir gerade in den Sinn kommt, ist was Du am Schluss geschrieben hast, was der SMTP “denkt”.
Ich habe es auf einem anderen Server den ich halb zum besten, halb produktiv nutze mit Deinem Tutorial probiert.
Dort gingen die Mails ebenfalls nicht raus.
Als ich die Domains wieder gelöscht habe ging es wieder.
Die transport hatte ich angelegt.
Was mir noch aufgefallen ist, dass ein ```
invoke-rc.d univention-management-console-server restart
postfix reload


Soweit schon mal wie gesagt Danke....

#10

Hier ein Zwischenbericht:

Zu den Warnungen:

Nach dem Update auf 4.2 sind in der Univention Configuration Registry (UCR) zwei Variablen auf yes bzw. true gesetzt. Dadurch werden in der main.cf von Postfix Einträge angelegt, die die Warnung bezüglich der sasl_auth hervorrufen und auch den Mailversand verhindern. Daher

mail/relayauth = false
mail/postfix/virtual/enabled = false

setzen.
relayauth führt zu den zusätzlichen Einträgen in der main.cf, die aber nur gebraucht werden, wenn auch mail/relayhost gesetzt ist, was für mehrere relayhosts eben nicht möglich ist. Also wird auch mail/relayauth nicht gebraucht.

mail/postfix/virtual/enabled macht zusätzliche Einträge in der main.cf, die für virtuelle Mailboxen sind. Es wird auch eine virtual.db angelegt. Dort steht aber nichts drin, doch postfix sucht beim Senden hier nach dem Empfänger. Daher der Fehler: [quote=“ckraut, post:1, topic:5590”]
RCPT line gave SMTP error 550 5.1.1 <hh@gmail.com>: Recipient address rejected: User unknown in virtual mailbox table.
[/quote]

Damit wäre auch ein Fehler beim Mailversand behoben. Es gibt aber noch einen zweiten siehe unten.

In /etc/univention/templates/files/etc/postfix/main.cf.d/31_sender_dependent_relayhostmaps ist der Eintrag
sender_dependent_relayhost_maps=yes überflüssig und kann gelöscht werden. Warum das zuvor keine Warnung ausgelöst hat, wundert mich. Danach auf der Kommandozeile

ucr commit /etc/postfix/main.cf
postfix reload

ausführen.

Die Warnungen sind nun behoben.

Mailversand:
Damit das Versenden an externe Adressen von registrierten Domänen funktioniert, dürfen keine transport maps für sie angelegt sein. Bei meiner vorigen Konfiguration funktionierte das trotzdem und war auch ein Punkt, den ich aus den Artikeln im Forum hatte. Nun frage ich mich warum es vorher überhaupt funktioniert hat. Denn die transport maps beziehen sich immer auf die Empfängeradresse. Postfix schaut also in den transport maps, um zu sehen über welchen Server der Empfänger erreicht werden soll. Das macht bei relayhosts eigentlich keinen Sinn, denn der Relayhost soll ja die Empfängeradresse auflösen. Wie dem auch sei, der Mailversand funktioniert, wenn es keine mail/transport/.* Einträge in der UCR gibt. Nachdem ich meine gelöscht habe, geht der Mailversand.

Was nun noch nicht funktioniert ist das Senden mit den angelegten externen Adressen untereinander. Beispiel: Es gibt zwei Mailaccounts, die über sender_dependent_relayhosts abgewickelt werden, a@web.de und b@gmx.de. Von beiden Adressen können beliebige Empfänger angeschrieben werden nur a@web.de kann nicht direkt an b@gmx.de schreiben und umgekehrt. Die Mails kommen nicht an, weil die jeweilige Empfängeradresse in eine lokale Adresse umgeschrieben wird, Beispiel: a@web.de -> b@gmx.de -> c@domain.local. Das hängt wohl damit zusammen, dass für die externen Mailadressen Gruppen angelegt sind, denen dann ein lokaler Nutzer zugewiesen wird, damit man sie mit Kopano nutzen kann. Zu diesem lokalen Nutzer wird die Empfängeradresse umgeschrieben und dann über den relayhost versandt. Das geht natürlich schief, weil der relayhost gmx.de ein c@domain.local nicht auflösen kann. Das ist nicht wirklich ein Beinbruch, aber im Eifer des täglichen E-Mail-Gefechts kann es schon mal vorkommen, dass eine E-Mail so weitergeleitet wird und dann nicht ankommt.

Ich hoffe, Du kannst damit etwas anfangen und kommst weiter. Ich hab’ das zwar getestet und meine bei mir funktioniert es. Ich würde mich aber freuen, wenn Du das bestätigst oder Deine Erfahrungen damit teilst.


Nach Update auf 4.2: Kopano nimmt keine Mails von extern mehr an
#11

Hi @rob wir haben hier nun einen fast funktionierenden Server am laufen.
Grundsätzlich funktioniert es auch mit der transport und ohne die oben erwähnte änderung.

Dass einzige Problem ist nun nur noch dieses:

May 12 12:10:08 ucs postfix/smtpd[18153]: connect from localhost[127.0.0.1]
May 12 12:10:09 ucs postfix/smtpd[18153]: 011B263E83A: client=localhost[127.0.0.1]
May 12 12:10:09 ucs postfix/cleanup[18154]: 011B263E83A: message-id=<kcim.59158a00.46e6
May 12 12:10:09 ucs postfix/qmgr[18119]: 011B263E83A: from=<mymail@domain.de>, size=1060, nrcpt=1 (queue active)
May 12 12:10:09 ucs postfix/smtpd[18153]: disconnect from localhost[127.0.0.1]
May 12 12:10:09 ucs postfix/smtpd[18159]: connect from localhost[127.0.0.1]
May 12 12:10:09 ucs postfix/smtpd[18159]: 8584463E83B: client=localhost[127.0.0.1], orig_queue_id=011B263E83A, orig_client=localhost[127.0.0.
May 12 12:10:09 ucs postfix/cleanup[18154]: 8584463E83B: message-id=<kcim.59158a00.46e6
May 12 12:10:09 ucs postfix/qmgr[18119]: 8584463E83B: from=<mymail@domain.de>, size=1748, nrcpt=1 (queue active)
May 12 12:10:09 ucs amavis[17597]: (17597-01) Passed CLEAN {RelayedInternal}, LOCAL [127.0.0.1]:41636 <mymail@domain.de> -> <gmailaccount@gmail.com>, Queue-ID: 011B263E83A, Message-ID: <kcim.59158a00.46e6.055910fa7bMay 12 12:10:08 ucs postfix/smtpd[18153]: connect from localhost[127.0.0.1]
May 12 12:10:09 ucs postfix/smtpd[18153]: 011B263E83A: client=localhost[127.0.0.1]
May 12 12:10:09 ucs postfix/cleanup[18154]: 011B263E83A: message-id=<kcim.59158a00.46e6
May 12 12:10:09 ucs postfix/qmgr[18119]: 011B263E83A: from=<mymail@domain.de>, size=1060, nrcpt=1 (queue active)
May 12 12:10:09 ucs postfix/smtpd[18153]: disconnect from localhost[127.0.0.1]
May 12 12:10:09 ucs postfix/smtpd[18159]: connect from localhost[127.0.0.1]
May 12 12:10:09 ucs postfix/smtpd[18159]: 8584463E83B: client=localhost[127.0.0.1], orig_queue_id=011B263E83A, orig_client=localhost[127.0.0.
May 12 12:10:09 ucs postfix/cleanup[18154]: 8584463E83B: message-id=<kcim.59158a00.46e6
May 12 12:10:09 ucs postfix/qmgr[18119]: 8584463E83B: from=<mymail@domain.de>, size=1748, nrcpt=1 (queue active)
May 12 12:10:09 ucs amavis[17597]: (17597-01) Passed CLEAN {RelayedInternal}, LOCAL [127.0.0.1]:41636 <mymail@domain.de> -> <gmailaccount@gmail.com>, Queue-ID: 011B263E83A, Message-ID: <kcim.59158a00.46e6.055910fa7b
May 12 12:10:09 ucs postfix/smtp[18155]: 011B263E83A: to=<gmailaccount@gmail.com>, relay=127.0.0.1[127.0.0.1]:100
May 12 12:10:09 ucs postfix/qmgr[18119]: 011B263E83A: removed
May 12 12:10:10 ucs postfix/smtp[18123]: 8584463E83B: SASL authentication failed; server smtp.gmail.com[74.125.206.109] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8  https://support.google.com/mai x126sm4620887wme.12 - gsmtp
May 12 12:10:10 ucs postfix/smtp[18123]: 8584463E83B: to=<gmailaccount@gmail.com>, relay=smtp.gmail.com[74.125.20smtp.gmail.com[74.125.206.108] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8  https://support.google.com/mai a73sm3279842wrc.58 - gsmtp)
May 12 12:10:09 ucs postfix/smtp[18155]: 011B263E83A: to=<gmailaccount@gmail.com>, relay=127.0.0.1[127.0.0.1]:100
May 12 12:10:09 ucs postfix/qmgr[18119]: 011B263E83A: removed
May 12 12:10:10 ucs postfix/smtp[18123]: 8584463E83B: SASL authentication failed; server smtp.gmail.com[74.125.206.109] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8  https://support.google.com/mai x126sm4620887wme.12 - gsmtp
May 12 12:10:10 ucs postfix/smtp[18123]: 8584463E83B: to=<gmailaccount@gmail.com>, relay=smtp.gmail.com[74.125.20smtp.gmail.com[74.125.206.108] said: 535-5.7.8 Username and Password not accepted. Learn more at?535 5.7.8  https://support.google.com/mai a73sm3279842wrc.58 - gsmtp)

Sprich die Mailaccounts die bei sagen 1blu gehosted werden mymail@domain.de wollen nach gmailaccount@gmail.com senden.
Dann gibt es irgendwie einen Loop und postfix versucht wohl ohne Account via smtp.gmail.com zu senden, was natürlich ohne Account nicht geht.

Irgendwie müssten vor der transport noch der relay abgefragt werden und nicht zuerst transport, damit die mails nicht generel via smtp.gmail.com rausgehen, sondern diese über den richtigen Account mit Zugangsdaten geroutet werden…wenn ich richtig verstanden habe, was mein Kollege meinte.

Hier die transport:

mailtestsystem@gmail.com  lmtp:127.0.0.1:2003
mailtestsystem345@gmail.com  lmtp:127.0.0.1:2003
mt@gmail.com lmtp:127.0.0.1:2003
dodo@googlemail.com lmtp:127.0.0.1:2003
dodo@gmail.com lmtp:127.0.0.1:2003
mymail@domain.de lmtp:127.0.0.1:2003
mymail@domain2.de lmtp:127.0.0.1:2003
domain1.de smtp:[smtp.1blu.de]
domain2.de smtp:[smtp.1blu.de]
gmail.com smtp:[smtp.gmail.com]
googlemail.com smtp:[smtp.gmail.com]

Wenn es läuft, versuche ich ein HowTo zu schreiben.
Nur daran scheitert es gerade noch.

Jemand eine Idee?

Gruß Carmen


#12

Hallo Carmen,
ich habe seit 2 Wochen leider keine Zeit mich dem Problem zu widmen. Allerdings bin ich auch kein Postfixspezialist und kann deshalb dabei nicht weiterhelfen. Wenn Mails zwischen zwei externen Adressen auf dem UCS Server nur lokal versandt werden sollen, dann braucht es meiner Ansicht nach eine Fallabfrage bei jedem Versenden.
Gesetzt a@gmail.com und b@1blu.de werden mit Kopano verwaltet c@1blu.de jedoch nicht, ist also wirklich extern, dann müsste wenn a@gmail.com der Absender ist in jedem Fall geprüft werden, ob die Empfängeradresse lokal verwaltet wird oder nicht. Beispiel:

  • Bei a@gmail.com -> b@1blu.de müsste der sender_dependent_relayhost übergangen werden, weil ja nur lokal verschickt werden soll, und die transport für 1blu.de auf lokal lauten, damit es keinen Fehler gibt.

  • Bei a@gmail.com -> c@1blu.de wird a@gmail.com über sender_dependent_relayhost gemappt und die transport für 1blu.de muss auf smtp.1blu.de lauten, damit es keinen Fehler gibt.

Das heißt, es braucht Fallunterscheidungen. Ich weiß nicht, ob die sender_dependent_relayhost map und die transport map sich auch für einzelne E-Mail-Adressen einrichten lassen.

Gruß
Robert