postfix hängt sich immer wieder auf

foobar42

New Member
Hallo zusammen

Ich habe einen neuen Mailserver mit postfix und dovecot aufgesetzt, unter Debian Buster.
Dabei habe ich mich weitestgehend an diese Anleitung gehalten:

Das Problem ist nun, dass er für eingehende Mails immer wieder mal nicht erreichbar ist. Das passiert vollkommen unregelmäßig. Mal läuft er drei Tage durch, mal passiert das mehrmals pro Tag. Das sieht dann so aus:

Jan 8 12:27:22 hiceju postfix/smtpd[23222]: connect from mailings.doccheck.com[195.82.66.249]
Jan 8 12:27:22 hiceju postfix/smtpd[23222]: lost connection after CONNECT from mailings.doccheck.com[195.82.66.249]
Jan 8 12:27:22 hiceju postfix/smtpd[23222]: disconnect from mailings.doccheck.com[195.82.66.249] commands=0/0
Jan 8 12:27:22 hiceju postfix/smtpd[23222]: connect from mta3-219.knickmystery.com[51.68.107.219]
Jan 8 12:27:22 hiceju postfix/smtpd[23222]: disconnect from mta3-219.knickmystery.com[51.68.107.219] quit=1 commands=1
Jan 8 12:27:22 hiceju postfix/smtpd[23222]: connect from vafilo.han-solo.net[83.138.88.56]
Jan 8 12:27:22 hiceju postfix/smtpd[23222]: lost connection after CONNECT from vafilo.han-solo.net[83.138.88.56]

Ich kann keine Einträge in keinem Log finden, die das irgendwie erklären könnten. Am Anfang dachte ich noch als SSL-Probleme. Diesbezüglich hagelte es immer wieder Fehler. Die Konfiguration in der Anleitung war das wohl ziemlich strickt, mind. TLS 1.2 zum Beispiel. Das habe ich ein wenig entschärft. Kaum noch SSL-Fehler.

Wie dem auch sei, nur ein "systemctl restart postfix" löst das Problem. Vorher temp. abgewiesene Mail trudeln nach und nach ein. Bis zum nächsten mal.

In meiner Verzweiflung starte ich postfix nun per cron regelmäßig neu. Das kann aber nicht die Lösung sein.
Wie finde ich das Problem? Was tun? Ich hätte auch kein Problem, einen Profi zu beauftragen.
 
Code:
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 1h
disable_vrfy_command = yes
inet_interfaces = 127.0.0.1, 83.138.88.70
local_recipient_maps = $virtual_mailbox_maps
mailbox_size_limit = 0
maximal_backoff_time = 15m
maximal_queue_lifetime = 1h
message_size_limit = 52428800
milter_default_action = accept
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_protocol = 6
minimal_backoff_time = 5m
mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject
mua_relay_restrictions = reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
mua_sender_restrictions = permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
myhostname = hiceju.han-solo.net
mynetworks = 127.0.0.0/8
non_smtpd_milters = inet:localhost:11332
proxy_read_maps = proxy:mysql:/etc/postfix/sql/aliases.cf proxy:mysql:/etc/postfix/sql/accounts.cf proxy:mysql:/etc/postfix/sql/domains.cf proxy:mysql:/etc/postfix/sql/recipient-access.cf proxy:mysql:/etc/postfix/sql/sender-login-maps.cf proxy:mysql:/etc/postfix/sql/tls-policy.cf
queue_run_delay = 5m
recipient_delimiter = +
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_ciphers = high
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_policy_maps = proxy:mysql:/etc/postfix/sql/tls-policy.cf
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_client_restrictions = permit_mynetworks check_client_access hash:/etc/postfix/without_ptr reject_unknown_client_hostname
smtpd_data_restrictions = reject_unauth_pipelining
smtpd_helo_required = no
smtpd_helo_restrictions = permit_mynetworks reject_invalid_helo_hostname reject_non_fqdn_helo_hostname reject_unknown_helo_hostname
smtpd_milters = inet:localhost:11332
smtpd_recipient_restrictions = check_recipient_access proxy:mysql:/etc/postfix/sql/recipient-access.cf
smtpd_relay_restrictions = reject_non_fqdn_recipient reject_unknown_recipient_domain permit_mynetworks reject_unauth_destination
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/letsencrypt/live/hiceju.han-solo.net/fullchain.pem
smtpd_tls_ciphers = high
smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem
smtpd_tls_key_file = /etc/letsencrypt/live/hiceju.han-solo.net/privkey.pem
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
tls_high_cipherlist = !aNULL:!eNULL:!CAMELLIA:HIGH:@STRENGTH
tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
tls_preempt_cipherlist = yes
tls_ssl_options = NO_COMPRESSION
virtual_alias_maps = proxy:mysql:/etc/postfix/sql/aliases.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/accounts.cf
virtual_transport = lmtp:unix:private/dovecot-lmtp
 
Vorher temp. abgewiesene Mail trudeln nach und nach ein. Bis zum nächsten mal.

Du hast nicht zufällig für/im Rspamd das Greylisting aktiviert? Eventuell hilft da mal ein Blick ins Rspamd-Log bzw. das Rspamd-Webinterface.
 
Du hast nicht zufällig für/im Rspamd das Greylisting aktiviert? Eventuell hilft da mal ein Blick ins Rspamd-Log bzw. das Rspamd-Webinterface.
Habe ich, aber das ist es nicht. Greygelistete kommen halt später rein. Um die geht es nicht.
postfix lehnt hin und wieder jegliche Verbindung von außen ab und dann dauerhaft, alle, bis zum Neustart. Erkennbar übrigens auch in der mailqueue von einliefernden Servern. Da steht dann Connection timed out.
 
Wenn das Problem auftritt, kannst du dann von eigenen Server per

telnet 83.138.88.70 25
telnet 127.0.0.1 25

gegen den Postfix connecten?
 
Wenn man nicht erreichbar sein will, dann gibt es auch keinen Grund, darüber zu meckern, dass man nicht erreichbar ist...

PS: Die gesamte Konfiguration ist bestenfalls suboptimal...
Das ist der Standardwert für mynetworks und der ist schon richtig so. mynetworks ist für relaying ohne Authentifizierung. Wäre das falsch, käme keine wohl keine von tausenden Mails pro Tag an.

Aber was ist noch suboptimal? Ich verstehe ja auch nicht alles, will es aber, bin lernfähig.
 
OMG, ich vermute, ich habe den Fehler. In der master.cf
Code:
smtp      inet  n       -       y       -       1       smtpd

Nur eine Verbindung von außen zur Zeit? Warum hat der Typ in der Anleitung das so gemacht?
Aufgefallen ist mir das, als in per Telnet von außen getestet habe. Einfach nur connected und nichts weiter gemacht. Keine weiteren anderen Mails kamen rein.
Mal beobachten, ob das mit einem höheren Wert nun besser läuft.
 
Das ist der Standardwert für mynetworks
Nope, der Standardwert ist:
Code:
postconf -d mynetworks
Und basiert auf:
Code:
postconf -d mynetworks_style

Aber gut, Du hasst offensichtlich mehr Erfahrung mit Postfix als ich, also halte ich mich noch etwas zurück...
Good luck!
 
Aber gut, Du hasst offensichtlich mehr Erfahrung mit Postfix als ich, also halte ich mich noch etwas zurück...
Good luck!

Habe ich das? Nein, ganz bestimmt nicht. Sonst wäre ich wohl nicht hier.

Du hast geschrieben, dass ich mit mynetworks = 127.0.0.0/8 nicht erreichbar wäre. Das ist flasch. Der Server ist erreichbar, seit Wochen und empfängt, und leitet ggf. weiter, tausende Mails jeden Tag. Nur eben hin und wieder nicht. Siehe ersten Post. DAS ist mein Problem
Aber Du schriebst das sicher nicht aus Jux und Dollerei. Seit doch bitte so nett und erkläre mir, was daran falsch ist. Oder auch Dein "suboptimal". Ich bin doch hier, um was zu lernen. Deine Antworten helfen mir nicht. Vielleicht ist das ja gewollt. Du möchtest mir nicht alles vorbeten. Ich kenne die Gepflogenheiten in technischen Foren, schon aus dem Usenet. Ist mir schon klar, wie Geben und Nehmen läuft. Ein paar zielführende Hinweise darf ich aber schon erwarten. Oder nicht?
 
OK, hier findest Du meine über 20 Jahre gewachsene und mitlerweile tausendfach bewährte Basiskonfiguration für Postfix:
Ist zwar FreeBSD, aber mit angepassten Pfaden und den entsprechenden Paketen auch auf jedem Linux uneingeschränkt nutzbar (gilt auch für meine anderen FreeBSD-HowTos).

Wenn es mit meinen Configs nicht läuft, dann liegt das Problem in der Regel an irgendwelchen überflüssigen Apps wie Antispam/Antiviren-Apps oder es sind externe Probleme, welche sich nicht immer beheben lassen.
 
@foobar42: Ist das eventuell ein vServer auf Virtuozzo-Basis, dem gelegentlich einfach die Ressourcen dramatisch gekürzt werden?


@Joe User
Aus deiner Config geht nur hervor, dass du "mynetworks" nicht explizit definiert hast. Der Standard ist in diesem Fall dann tatsächlich, die "eigenen" lokalen Präfixe zu trusten. Im Wortlaut aus der Beispielconfig der aktuellen Stable:
By default (mynetworks_style = subnet), Postfix "trusts" SMTP clients in the same IP subnetworks as the local machine.
Aber: In Serverhosting-Umgebungen, wo du dich mit anderen Kunden im selben Präfix befindest, willst du das nicht - denn sonst könnten die Kunden nebenan einfach über deinen Mailserver beliebig E-Mails an Dritte verschicken. Von daher ist es nicht vollkommen verkehrt, "mynetworks" auf 127.0.0.0/8 einzuschränken. Klar ginge auch "mynetworks_style = host" in diesem Fall, das Ergebnis ist aber im wesentlichen identisch.
Naja, man sollte halt neben dem IPv4-Loopback auch IPv6-Loopback und sämtliche eigenen IP-Adressen mit hinzufügen in diesem Fall...


Aber das hat nunmal alles nichts damit zu tun, auf welchen Interfaces/Adressen Postfix auf Port 25 lauscht oder mit wem Postfix redet.
Das wird, wenn man es konfigurieren will, über die master.cf für den jeweiligen Dienst/Transport konfiguriert.
Wenn also Postfix keine Verbindungen mehr annimmt, dann liegt es sicherlich nicht an diesem Konfigurationsparameter.
Mit "mynetworks" wird lediglich festgelegt, von welchen IP-Adressen du Mails an nichtlokale Empfänger akzeptierst. Würdest du dort beliebige IPs erlauben, hättest du ein offenes Relay.
Oder, um die Postfix-Doku zu zitieren:
mynetworks:
The list of "trusted" remote SMTP clients that have more privileges than "strangers".
 
@foobar42: Ist das eventuell ein vServer auf Virtuozzo-Basis, dem gelegentlich einfach die Ressourcen dramatisch gekürzt werden?
Es ist eine Art vServer, wie genau umgesetzt, weiß ich nicht. Hoster ist Hostnet, Produkt nennt sich BaremetalCloud. Dieser hier hat 6 CPUs und 12 GB RAM.
Wir fahren mit den Dingern eigentlich ziemlich gut. Unser eigentliches Portal mit nicht wenig Zugriffen und Last läuft sauber störungsfrei auf einem anderen.

@Joe User
Wenn also Postfix keine Verbindungen mehr annimmt, dann liegt es sicherlich nicht an diesem Konfigurationsparameter.
Mit "mynetworks" wird lediglich festgelegt, von welchen IP-Adressen du Mails an nichtlokale Empfänger akzeptierst. Würdest du dort beliebige IPs erlauben, hättest du ein offenes Relay.
Meinte ich ja auch und war deswegen ein wenig verwundert über diesen Einwand.
 
@ Lord Gurke
Der Default für mynetworks_style ist schon seit etlichen Jahren (20141009) host und nicht mehr subnet, vielleicht kommt das ja noch in diesem Jahrzehnt bei Debian und Co an...

Ansonsten ist dem Log im ersten Post zu entnehmen, dass die Verbindung zu Postfix auf Port 25 einwandfrei funktioniert, ansonsten würde nicht Postfix loggen, sondern der Kernel.
Und da foobar42 weitere Tools/Apps (u.A. per Milter) in seinen Mailworkflow einbindet, ist ein korrekt konfiguriertes mynetworks/mynetworks_style essentiell, um diesen Workflow überhaupt erst sauber zu ermöglichen.

Solange die Basics nicht sauber konfiguriert sind, braucht man sich um den Rest gar nicht erst kümmern...

Behebe die Ursache statt die Symptome zu verschleiern.
 
@ Lord Gurke
Der Default für mynetworks_style ist schon seit etlichen Jahren (20141009) host und nicht mehr subnet, vielleicht kommt das ja noch in diesem Jahrzehnt bei Debian und Co an...
Ich habe nicht bei Debian geguckt sondern in der main.cf (Zeile 250), die mit Postfix 3.5.8 mitgeliefert wird. Wenn, dann muss dort der Erklärungstext aktualisiert werden ;-)

Aber unabhängig davon müssten wir jetzt mal abwarten, ob bei neuerlichem Auftreten des Fehlers Postfix per Netzwerk irgendwas sagt und ob es sinnvoll ist.
@foobar42 Wenn du das testest, bitte wirklich warten, bis du Timeout oder Fehlermeldung vom Client bekommst. Wenn es ein Milter-Problem ist, wartet Postfix da unter Umständen sehr, sehr lange bis du überhaupt den SMTP-Banner bekommst. Andere Clients geben dann vielleicht vorher auf, das könnte zumindest das Log erklären.
 
Ich habe nicht bei Debian geguckt sondern in der main.cf (Zeile 250), die mit Postfix 3.5.8 mitgeliefert wird. Wenn, dann muss dort der Erklärungstext aktualisiert werden ;-)
Nice find, das sollte dann wirklich mal aktualisiert werden ;)
 
Back
Top