"mail transport unavailable" seit Update auf 4.2.0 errata 45

Zwei Server, davon einer als DC mit Mailrelay, der andere als Mailserver, wurden gestern upgedated. Einmal von 4.2.0 errata 4, einmal von 4.2.0 errata 25 (ca.).

Seitdem werden über beide Server keine Mails mehr zugestellt, aber es kommen auch keine Bounce Mails. Vorher funktionierte alles prima.

Laut UCM läuft Postfix auf beiden Systemen. Neustart der Dienste / der Server hat nichts gebracht. Rufe ich nmap localhost auf, werden mir Ports für smtp und smtps angezeigt.

Hier mein postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
always_bcc = mailcopy@xxx.de
append_dot_mydomain = no
broken_sasl_auth_clients = yes
canonical_maps = hash:/etc/postfix/canonical
command_directory = /usr/sbin
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
daemon_directory = /usr/lib/postfix
disable_vrfy_command = no
inet_interfaces = all
inet_protocols = ipv4
local_header_rewrite_clients =
masquerade_domains = $mydomain
masquerade_exceptions = root
message_size_limit = 10240000
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = vserver.xxx.local
mynetworks = 192.168.0.0/24
myorigin = vserver.msbe.local
relayhost = smtp.strato.de
relocated_maps = hash:/etc/postfix/relocated
smtp_helo_name = vserver.msbe.local
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth
smtp_sasl_security_options = noanonymous
smtp_tls_exclude_ciphers = RC4, aNULL
smtp_tls_loglevel = 0
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3
smtp_tls_security_level = encrypt
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unlisted_recipient, check_policy_service inet:127.0.0.1:12340
smtpd_sasl_local_domain =
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_starttls_timeout = 300s
smtpd_timeout = 300s
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/univention/ssl/vserver.xxx.local/cert.pem
smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = RC4, aNULL
smtpd_tls_key_file = /etc/univention/ssl/vserver.xxx.local/private.key
smtpd_tls_loglevel = 0
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols =
smtpd_tls_received_header = no
smtpd_tls_session_cache_timeout = 3600s
smtpd_use_tls = yes
tls_preempt_cipherlist = yes
tls_random_source = dev:/dev/urandom
transport_maps = hash:/etc/postfix/transport, ldap:/etc/postfix/ldap.transport
virtual_alias_domains =
virtual_alias_maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/ldap.groups, ldap:/etc/postfix/ldap.distlist, ldap:/etc/postfix/ldap.virtual, ldap:/etc/postfix/ldap.external_aliases, ldap:/etc/postfix/ldap.sharedfolderremote, ldap:/etc/postfix/ldap.sharedfolderlocal_aliases
virtual_mailbox_domains = ldap:/etc/postfix/ldap.virtualdomains
virtual_mailbox_maps = ldap:/etc/postfix/ldap.virtual_mailbox, ldap:/etc/postfix/ldap.sharedfolderlocal
virtual_transport = lmtp:unix:private/dovecot-lmtp

Wo kann ich nachsehen, was hier plötzlich schief läuft ?

Gruß Martin

Findet sich etwas dazu in /var/log/mail.*?

z. B.:

Jun 16 12:09:15 vserver postfix/smtpd[11842]: connect from mserver.xxx.local[192.168.0.9]
Jun 16 12:09:15 vserver postfix/smtpd[11842]: EC1262D01086: client=mserver.xxx.local[192.168.0.9]
Jun 16 12:09:15 vserver postfix/cleanup[11352]: EC1262D01086: message-id=<201706161009.v5GA9FJQ015420@mserver.xxx.local>
Jun 16 12:09:16 vserver postfix/qmgr[7430]: EC1262D01086: from=<fax@xxx.local>, size=1728, nrcpt=3 (queue active)
Jun 16 12:09:16 vserver postfix/qmgr[7430]: EC1262D01086: to=<xxx@xxx..de>, orig_to=<faxoffice@xxx.de>, relay=none, delay=0.11, delays=0.07/0.03/0/0, dsn=4.7.4, status=deferred (delivery temporarily suspended: TLS is required, but was not offered by host 127.0.0.1[127.0.0.1])
Jun 16 12:09:16 vserver postfix/smtpd[11842]: disconnect from mserver.xxx.local[192.168.0.9]
Jun 16 12:09:16 vserver postfix/qmgr[7430]: EC1262D01086: to=<mailcopy@xxx.de>, relay=none, delay=0.13, delays=0.07/0.06/0/0, dsn=4.7.4, status=deferred (delivery temporarily suspended: TLS is required, but was not offered by host 127.0.0.1[127.0.0.1])
Jun 16 12:09:16 vserver postfix/qmgr[7430]: EC1262D01086: to=<posteingang@xxx.de>, orig_to=<faxoffice@xxx.de>, relay=none, delay=0.15, delays=0.07/0.08/0/0, dsn=4.7.4, status=deferred (delivery temporarily suspended: TLS is required, but was not offered by host 127.0.0.1[127.0.0.1])
Jun 16 12:09:38 vserver postfix/smtpd[11456]: connect from mserver.xxx.local[192.168.0.9]

Hier wird TLS verlangt, was der Server irgendwie nicht liefert. Ist hier eine Einstellung falsch ?

Danke, Martin

Ist die Domain als lokale Mail-Domain konfiguriert? Welcher Port ist konfiguriert? Wird Authentifizierung verwendet?

Evtl. Errata 36:
https://errata.software-univention.de/ucs/4.2/36.html

* When a relay host with authentication is used (mail/relayauth=yes),
  the Postfix option smtp_tls_security_level will automatically be set
  to "encrypt", unless mail/postfix/tls/client/level is set to "none"
  (Bug #44589).

Genau das war es. Ich habe die Ausgabe von postconf -n mit einem dritten UCS 4.2 Server verglichen und bemerkt, dass sich der Eintrag für smtp_tls_security_level bei diesem Server unterschied. Hier stand als Parameter “may”. Dies wird jetzt offenbar automatisch auf “encrypt” gesetzt, sofern man ein Relay betreibt. Immerhin steht diese Erklärung so auch in der UCS-Registry, das ist top.

Nachdem ich den UCS Registry - Wert /mail/postfix/tls/client/level auf “none” geändert und postfix neu gestartet hatte, arbeiteten die Server alle Mails ab und stellten sie zu.

Aber: Habe ich jetzt ein Sicherheitsproblem ?

Danke, Martin

Hallo,

wir haben ein ähnliches Problem:

Nach dem Update kommen keine E-Mails mehr in Kopano an, versende geht auich nicht.

Sobald die Variable mail/postfix/tls/client/level = none geetzt wird können E-Mails gesendet werden.

Der Empfang der E-Mails funktioniert auch wieder, allerdings werden die E-Mails nicht dem “User” zugestellt sondern einer Catch-All Adresse zugewisen.

In der Benutzerverwaltung von Univention sind die E-Mail Adressen als “Primäre E-Mail-Adresse” hinterlegt.

Wenn ich die entsprechende E-Mail-Adresse unter Erw. Einstellungen-Mail-Alternative E-Mail-Adresse nochmals anlege funtioniert das ganze wieder problemlos.

Wie kann dem Sytsem beigebracht werden, dass es wieder die Pimäre E-Mail-Adresse verwendet?

1 Like

Ich habe hier das gleiche Problem, direkt nach dem update auf Errata-45 ging die Email nicht mehr, wegen TLS error.

status=deferred (delivery temporarily suspended: TLS is required, but was not offered by host 127.0.0.1[127.0.0.1])

Bitte führen Sie aus:

ucr set mail/postfix/tls/client/level=none
postfix reload

bis wir eine bessere Lösung gefunden haben.

Gruß
Daniel Tröder

Guten morgen!

Gibt es evtl noch eine alternative? Denn i dem Fall habe ich das Problrm, dass der Relay-Server drausen die Mails abweist.

Grüße

Hallo,

wir arbeiten gerade mit Hochdruck an einem Erratum, um dieses Problem zu lösen.

In der Zwischenzeit kann die Datei /etc/postfix/main.cf manuell editiert werden und die Zeile

smtp_tls_security_level = encrypt

auf

smtp_tls_security_level = may

geändert werden. Anschließend muss der Postfix neu gestartet werden:

invoke-rc.d postfix restart

Dabei ist zu beachten, dass die manuelle Anpassung durch das Ändern von UCR-Variablen ggf. automatisch wieder rückgängig gemacht wird.

Viele Grüße,

Sönke Schwardt-Krummrich

Hallo - nach den händischen Anpassungen wie oben beschrieben, gehe die eMails wieder rein und raus.
FYI - die Einstellung via UCS web registry (auf none stellen) hat bei mir nicht funktioniert - da kamen nur die eMail rein - gingen aber nicht raus über den externe Provider.

Besten dank - diese Lösung klappt.
Vielen Dank für eure Hilfe!

Beste Grüße

Hallo,

ein offizieller bug fix wurde veröffentlicht: http://errata.software-univention.de/ucs/4.2/49.html
Bitte updaten Sie und stellen Sie die UCR Variable wieder auf ihren Standard zurück:

ucr set mail/postfix/tls/client/level=may
postfix reload
univention-upgrade

Der fix trägt eine gesonderte Regel für das was in mail/relayhost steht in /etc/postfix/tls_policy ein. So wird die Sicherheit der ausgehenden Verbindung für das Relay gewährleistet, ohne die Einstellungen anderer Verbindungen zu ändern.

Beste Grüße
Daniel Tröder

yes its working! Now I am on errata 52.

THX,
Stefan

Hallo,

nach unseren Update auf 4.4-6 errata758 gehen keine Mails mehr über unseren relayhost raus.

Bei den Logfile mail.log kommt immer
„dsn=4.7.4, status=deferred (TLS is required, but was but was not offered by host smtp.*****.de[...]“

Im Mail Requests sind jetzt mehrere Mails wo immer
„(delivery temporarily suspended: TLS is required, but was not offered by host smtp.mwb-*****.de[...])“ kommt.

Bei postsuper -s kommt
“postsuper: warning: bogus file name: incoming/41988.12819”

Wie bekomme ich den Mailausgang wieder zum laufen?

Danke

Mastodon