Kein Mailempfang für teilweise bestehende und neue Konten mehr möglich (554 5.7.1 <..>: Recipient address rejected

andy1965

Member
Hallo Leute,

irgendwie hat sich mit den letzten Updates von Debian u.o. ISPConfig ein Fehler eingeschlichen zu haben. Betroffen sind einige bestehende Mailkonten und Neue.

Folgender Fehler wird beim Absender angezeigt.

Letzter Fehler: 450 4.1.1 <xxx@xxx.at>: Recipient address rejected: unverified address: host 127.0.0.1[127.0.0.1] said: 554 5.7.1 <xxx@xxx.at>: Recipient address rejected: Access denied (in reply to RCPT TO command)
Empfänger: xxx@xxx.at;3;2;[{LED=450 4.1.1 <xxx@xxx.at>: Recipient address rejected: unverified address: host 127.0.0.1[127.0.0.1] said: 554 5.7.1 <xxx@xxx.at>: Recipient address rejected: Access denied (in reply to RCPT TO command)}

Ich werde nicht schlau daraus warum der Server teilweise Empfänger ablehnt.

Checks: DB OK, ISPConfig OK, Update 10 auf 11 war seinerzeit auch OK. Einstellungen überprüft OK.


Wäre für Tipps sehr dankbar!
 

Till

Administrator
Hast Du manuell etwas an der postfiux config geändert? Hast Du nach dem Debian dist upgrade ein ISPConfig update mit 'reconfigure services = yes' gemacht? Kommen gar keine mails an, oder nur einige nicht?
 

andy1965

Member
Ja in der main.cf hab ich einige Limitierungen ergänzt, In der master.cd nur nach Anleitung.

smtpd_recipient_limit = 100
smtpd_client_recipient_rate_limit = 100
smtpd_client_connection_rate_limit = 30
smtpd_client_message_rate_limit = 100
default_extra_recipient_limit = 100
duplicate_filter_limit = 100
default_destination_recipient_limit = 100
smtp_destination_recipient_limit = $default_destination_recipient_limit

reconfigure services = yes, hab ich auch gemacht

Bei bestimmten und neuen Konten kommen keine Emails mehr an, hängen in der Warteschlange bei den Absenderservern. Es wird zwar wiederholt versucht diese zuzustellen aber es geht nicht.
 

andy1965

Member
Ergänzung,
Nachdem ich gestern ein "resync" durchgeführt habe, sind jetzt alle Konten betroffen

SQLAbfrage auf die Datenbank funktioniert grundsätzlich. Die Tabelle ist nicht beschädigt.
 
Zuletzt bearbeitet:

Till

Administrator
Hmm, an den Limits sollte es an sich nicht liegen. Mach bitte nochmal ein ISPConfig update mit:

ispconfig_update.sh --force

und lass den Updater die Dienste rekonfigurieren.
 

andy1965

Member
Ich glaube ich habe den Fehler gefunden, jetzt funktioniert es wieder.
Wenn man die Parameter ansieht, findet man überflüssige Leerzeichen und , , , kann das der Fehler gewesen sein?

smtpd_helo_restrictions = permit_mynetworks, check_helo_access regexp:/etc/postfix/helo_access, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, check_helo_access regexp:/etc/postfix/blacklist_helo, , permit
smtpd_sender_restrictions = check_sender_access proxy:mysql:/etc/postfix/mysql-virtual_sender.cf, check_sender_access regexp:/etc/postfix/tag_as_originating.re, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unlisted_sender, check_sender_access regexp:/etc/postfix/tag_as_foreign.re
smtpd_client_restrictions = check_client_access proxy:mysql:/etc/postfix/mysql-virtual_client.cf, permit_inet_interfaces, permit_mynetworks, permit_sasl_authenticated, reject_unauth_pipelining , permit
 

Till

Administrator
Hmm, dann musst Du mal schauen was Du unter System > Server config > mail stehen hast, insbesndere im Feld für Realtime Blacklists. ist da vielleicht keine blacklist drin sondern ein leerzeichen oder so?
 

tom.1

New Member
Ich habe das gleiche Problem wie der Threadstarter, allerdings waren bei mir keine überflüssigen Leerzeichen oder aufeinanderfolgende Kommata in der main.cf zu finden. Ein ispconfig_update.sh --force mit Neukonfiguration der Dienste war auch erfolglos.

Im gesprächigeren Log sieht es so aus, als gäbe es ein Problem bei der Überprüfung der Empfängeradresse. Der Server versucht eine Mail vom Absender double-bounceXXXX@server-url.tld an die Empfängeradresse zu senden - das ist das Standard-Verfahren zur Überprüfung der Empfängeradresse. Allerdings will er das scheinbar über eine Relay-Verbindung machen und findet dafür keine Authentifizierungs-Informationen. Der entsprechende Abschnitt im Log sieht so aus:

Code:
connect to subsystem private/proxymap
send attr request = lookup
send attr table = mysql:/etc/postfix/mysql-virtual_sender-relayauth.cf
send attr flags = 540736
send attr key = double-bounceXXXX@example.com
private/proxymap socket: wanted attribute: status
input attribute name: status
input attribute value: 1
private/proxymap socket: wanted attribute: value
input attribute name: value
input attribute value: (end)
private/proxymap socket: wanted attribute: (list terminator)
input attribute name: (end)
dict_proxy_lookup: table=mysql:/etc/postfix/mysql-virtual_sender-relayauth.cf flags=lock|fold_fix|utf8_request key=double-bounceXXX@example.com -> status=1 result=
maps_find: smtp_sasl_password_maps: double-bounceXXXX@example.com: not found

Das gleiche versucht er dann jeweils noch einmal erfolglos für den Teil der double-bounce-Adresse vor und nach dem @.

Weil in der main.cf unter mynetworks nur 127.0.0.0/8 und [::1]/128 eingetragen waren, habe ich versucht, die Relay-Weiterleitung der Proben-Mail zu umgehen, indem ich dort alle IP-Adressen des Servers eingetragen habe. Leider hat das nichts gebracht. Ich habe für die Einzel-IP-Adressen das Format W.X.Y.Z/32 verwendet. Vielleicht ist das /32 falsch oder nur nicht notwendig.
Ich habe nach jeder Änderung der main.cf service postfix reload und nach einem fehlgeschlagenem Test zur Sicherheit auch service postfix restart ausgeführt und die Datei /var/lib/postfix/verify_cache.db gelöscht.

Letztlich habe ich in der main.cf unter dem Eintrag smtpd_recipient_restrictions den Wert check_recipient_access proxy:mysql:/etc/postfix/mysql-verify_recipients.cf aus der Liste der Parameter gelöscht. Das unterbindet den Test der Empfängeradresse.

Ich kann aber auch nicht nachvollziehen, was an dieser Stelle überprüft wird, denn wenn man in MariaDB
Code:
SELECT 'reject_unverified_recipient' FROM mail_domain WHERE domain = 'example.com' AND active = 'y' AND server_id = 1;
ausführt, kommt nichts zurück. Müsste da nicht irgendwie die Empfängeradresse einbezogen werden? Das sieht so unvollständig aus. Vielleicht ist die Abfrage nur eine Vorstufe für eine anschließende Prüfung, aber irgendwie ergibt sich der Sinn nicht ohne weiteres. Ob für die Domain überhaupt E-Mails empfangen werden sollen wird schon vorher mit reject_unknown_recipient_domain überprüft.

Falls das trotz des gleichen Problems wie im Eröffnungspost ein neuer Thread werden soll, darf das gern verschoben werden.
 

Till

Administrator
Soweit ich sehen kann hast Du ja ein anderes Problem als der Thread Starter, denn sein Problem lag an einem falschen Eintrag bei den RBL Listen der zu leeren Einträgen in der main.cf geführt hat, und Du hast diese Einträge ja nicht.

Ich kann aber auch nicht nachvollziehen, was an dieser Stelle überprüft wird, denn wenn man in MariaDB
Code:
SELECT 'reject_unverified_recipient' FROM mail_domain WHERE domain = 'example.com' AND active = 'y' AND server_id = 1;
ausführt, kommt nichts zurück. Müsste da nicht irgendwie die Empfängeradresse einbezogen werden?

Schau doch mal in die Tabelle mail domain rein mit phpmyadmin, ob es da einen Eintrag mit domain = 'example.com' AND active = 'y' AND server_id = 1 gibt. Und 'reject_unverified_recipient' ist ein String und keine Tabellenspalte.
 

tom.1

New Member
Schau doch mal in die Tabelle mail domain rein mit phpmyadmin, ob es da einen Eintrag mit domain = 'example.com' AND active = 'y' AND server_id = 1 gibt. Und 'reject_unverified_recipient' ist ein String und keine Tabellenspalte.
In der Datenbank sind alle Maildomains mit active=y und server_id=1 aufgeführt. Dass 'reject_unverified_recipient' ein String ist, hattest Du an anderer Stelle schon mal geschrieben - ich habe den entsprechenden Thread gestern aber nicht mehr gefunden und konnte mich nicht erinnern, ob die dort erwähnte Abfrage dieser hier entspricht.
Ich habe bei dieser Abfrage mit meinem bescheidenen Kenntnissen nicht direkt nachvollziehen können, wie sie unterschiedliche Ergebnisse für existente und nichtexistente E-Mailkonten auswerfen kann. Weil das aber mglw. gar nicht der Zweck dieser Abfrage ist und sie bei allen anderen gut funktioniert, gehe ich davon aus, dass der Fehler bei meinem System woanders liegt.
Ich mache heute abend noch einmal ein paar Tests und eröffne einen neuen Thread im englischen Forum.
 

Werbung

Top