Kolab Mailversand extern

SirTux · July 2, 2013, 1:00pm

Hallo,

Postfix akzetiert keine externen Mail-Adressen als Empfänger:

postfix/submission/smtpd[23505]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 554 5.7.1 <extern>: Relay access denied; from=<intern> to=<extern> proto=ESMTP helo=<servername>

mail/relayhost und mail/relayauth sind gesetzt und die Authdatei existiert und die Daten stimmen auch. Das Relay sollte ja auch nicht Ursache sein, denn der würde doch eher den Sender abweisen?

SirTux · July 2, 2013, 10:35pm

ANscheinend bin ich wohl nicht allein:

wickert · July 3, 2013, 8:08am

Hallo,

die beiden Fälle sind nicht zu vergleichen, denn bei dem anderen Nutzer ging es um Nutzer aus UCS@School, die nicht unter cn=users liegen. Bei denen verhindert der kolab Policy Filter das Versenden externer Mails. Ist das hier auch der Fall? Kann ich mal einen LDAP-Auszug des betreffenden Nutzers sehen?

Besten Dank,
Christoph Wickert

SirTux · July 3, 2013, 9:19am

Ja können Sie haben:

[code]uid=username
DN: uid=username,cn=users,dc=top2,dc=top1
ARG: None
certificateSubjectOrganisationalUnit: top2.top1
top2drive: None
CtxKeyboardLayout: None
certificateSerial: 29
disabled: none
postcode: 79295
CtxWFProfilePath: None
CtxRASDialin: E
certificateIssuerCommonName: Univention Corporate Server Root CA
title: None
mailAlternativeAddress: username@extern
fetchmailUsername:
organisation: None
CtxMaxIdleTime: None
certificateDays: None
certificateIssuerCountry: DE
lastname:
employeeNumber: None
certificateIssuerMail: ssl@top2.top1
password:
passwordexpiry:
certificateVersion: 2
fetchmailServer:
sambaRID: 5016
profilepath: None
certificateDateNotBefore:
certificateSubjectState:
mobileTelephoneNumber:
sambatop2: None
CtxWFHomeDirDrive: None
certificateSubjectCommonName: username
CtxCallback: None
street:
CtxShadow: 00000000
certificateIssuerLocation:
e-mail: username@top2.top1
CtxWorkDirectory: None
CtxNWLogonServer: None
CtxMaxConnectionTime: None
umcProperty: None
top2PostalAddress:
certificateSubjectMail: username@top2.top1
KolabDeliveryToFolderName: None
groups: cn=Domain Users,cn=groups,dc=top2,dc=top1
groups: cn=nxusers,cn=groups,dc=top2,dc=top1
groups: cn=opsifileadmins,cn=groups,dc=top2,dc=top1
certificateSubjectLocation:
overridePWHistory: None
pwdChangeNextLogin: None
KolabVacationText: None
fetchmailUseSSL: 1
secretary: None
certificateDateNotAfter:
KolabVacationActive: None
KolabForwardKeepCopy: FALSE
primaryGroup: cn=Domain Users,cn=groups,dc=top2,dc=top1
CtxInitialProgram: None
createRevokeCertificate: 1
scriptpath: None
sambaPrivileges: None
city:
CtxStartprogramClient: 0
fetchmailKeep: None
pagerTelephoneNumber: None
userCertificate:

certificateIssuerOrganisationalUnit: top2.top1
userexpiry: None
fetchmailProtocol: IMAP
sambaUserWorkstations: None
username: username
departmentNumber: None
shell: /bin/bash
CtxMinEncryptionLevel: None
certificateIssuerOrganisation:
CtxCallbackNumber: None
mailHomeServer: master.top2.top1
CtxCfgFlags1: 00800000
phone:
gidNumber: 5001
sambaLogonHours: None
CtxBrokenSession: None
locked: none
CtxReconnectSession: None
KolabForwardActive: FALSE
roomNumber: None
top2Share: cn=top2s,cn=master.top2.top1,cn=shares,dc=top2,dc=top1
gecos:
KolabVacationResendInterval: None
CtxCfgClientPrinters: 0
KolabVacationAddress: None
KolabDeliveryToFolderActive: FALSE
jpegPhoto: None
uidNumber: 2008
KolabVacationNoReactDomain: None
fetchmailPassword: None
employeeType: None
top2SharePath: username
CtxCfgPresent: 551e0bb0
CtxWFHomeDir: None
unixtop2: /top2/username
certificateIssuerState:
top2TelephoneNumber:
description: None
firstname:
KolabForwardUCE: FALSE
KolabForwardAddress: None
certificateSubjectCountry: DE
birthday:
KolabVacationReplyToUCE: None
overridePWLength: None
CtxMaxDisconnectionTime: None
CtxCfgDefaultClientPrinters: 0
renewCertificate: 0
certificateSubjectOrganisation:
displayName:
mailPrimaryAddress: username@top2.top1
CtxCfgClientDrivers: 1
CtxCfgTSLogon: 1
univentionPolicyReference: cn=username,cn=pwhistory,cn=users,cn=policies,dc=top2,dc=top1
univentionPolicyReference: cn=username_uv0,cn=thinclient,cn=policies,dc=top2,dc=top1[/code]

wickert · July 3, 2013, 9:26am

Welche Objektklassen hat der betreffende Nutzer? Sind inetOrgPerson und kolabInetOrgPerson vorhanden?

SirTux · July 3, 2013, 9:54am

Sind sie ja

bjectClass: top objectClass: person objectClass: univentionPWHistory objectClass: posixAccount objectClass: shadowAccount objectClass: univentionMail objectClass: univentionKolabInetOrgPerson objectClass: kolabInetOrgPerson objectClass: sambaSamAccount objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: simpleSecurityObject objectClass: uidObject objectClass: krb5Principal objectClass: krb5KDCEntry objectClass: pkiUser objectClass: univentionPerson objectClass: automount objectClass: univentionPolicyReference objectClass: univentionManageCertificates objectClass: univentionFetchmail objectClass: univentionObject

ahrnke · July 3, 2013, 12:00pm

Ich versuche gerade zu verstehen, wie der Mailversand eigentlich funktionieren soll.
In meiner Konfiguration kann ich das Verhalten mit Roundcube als auch mit TB reproduzieren.
Weder in der main.cf noch in der master.cf sehe ich bei den recipient_restrictions ein “permit_sasl_authenticated”.
Auf einem System mit Standard-UCS-Mailstack ist eine UCR-Variable gesetzt:

mail/postfix/smtpd/restrictions/recipient/30: permit_sasl_authenticated

Wenn man das mal testweise in die main.cf setzt, funktioniert der Versand.

Bei der Kolab-Integration wird der Submission-Port über die master.cf definiert:

587 inet n - n - - smtpd -o syslog_name=postfix/submission -o mynetworks= -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_authenticated_header=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Hier fehlt m.E etwas wie:

  -o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject

Ansonsten dürften die Restriktionen der main.cf greifen.

@Christoph: Bitte korrigier mich umgehend, wenn ich das grundsätzlich falsch verstanden habe.

SirTux · July 3, 2013, 12:11pm

[quote=“ahrnke”]Auf einem System mit Standard-UCS-Mailstack ist eine UCR-Variable gesetzt:

mail/postfix/smtpd/restrictions/recipient/30: permit_sasl_authenticated

Hm hier war sie auf “reject_unknown_recipient_domain” gesetzt. Wenn ich sie auf obigen Wert ändere gibt es keine Fehlermeldung mehr. Angekommen ist sie zwar nicht, aber da wird vermute ich die Übersetzung der Absenderdomain von intern nach extern noch nicht funktionieren

wickert · July 3, 2013, 12:18pm

Hallo Dirk,

was Du schreibst hört sich erst mal sinnig an, aber ich habe mir das im Detail noch nicht befasst. Ich hoffe, dass ich morgen die Zeit finde, mir das anzuschauen.

Beste Grüße,
Christoph

ahrnke · July 3, 2013, 12:36pm

[quote=“SirTux”][quote=“ahrnke”]Auf einem System mit Standard-UCS-Mailstack ist eine UCR-Variable gesetzt:

mail/postfix/smtpd/restrictions/recipient/30: permit_sasl_authenticated

Hm hier war sie auf “reject_unknown_recipient_domain” gesetzt. [/quote]

Es gibt mehrere Variablen für die Recipient-Restrictions. Die Zahlen bestimmern die Reihenfolge. Sie sollten ggf. den vorhandenen Wert an dieser Stelle nicht überschrieben sondern eine zusätzliche Variable an passender Stelle setzen. Unter Kenntnisnahme von [bug]31738[/bug] wäre das nach reject_unauth_destination.

In meiner Installation habe ich den oben beschriebenen Weg über die master.cf gewählt und die Zeile als letztes bei Service 587 in /etc/univention/templates/files/etc/postfix/master.cf.d/10_services eingetragen

An dieser Stelle helfen nur die Postfix-Logs.

SirTux · July 3, 2013, 12:45pm

Das wäre dann nach 60, aber dann geht es nicht mehr. Ich hab es jetzt auf 29 gesetzt.

In der Tat. Der relay-Name war falsch.