Und die Firewall ist auf allen drei Systemen gleich konfiguriert?
Ich persönlich würde ja einmal alle Dateien in /etc mit einem rekursiven Diff-Tool vergleichen und schauen, ob da etwas anders ist, was gleich sein sollte. Und zusätzlich die dpkg Liste aller installierten Pakete vergleichen. Vielleicht taucht die Ursache so schneller auf.
MfG Christian
Ja, die aktuelle 7-er Ausgabe.
Versand käme wahrscheinlich auf 4-6 Euro, laut Post.de. Kommt drauf an, wie schwer die Ausgabe ist und ob sie in einen großen Briefumschlag passt.
Melde Dich nächste Woche mal per PN oder E-Mail, wenn Du sie wirklich loswerden willst! 
Meine Systeme im Heimnetzwerk haben alle einen korrekten FQDN, der auch außerhalb aufgelöst werden kann. Die verweisen zwar auf private IPs, aber das ist fast jedem Spamfilter egal. Dadurch muss ich schon mal nichts bei den Adressen umschreiben.
Die Mails gehen dann über einen lokalen Postfix mit minimaler Konfiguration an ein zentrales System, das fürs interne Netzwerk ein offenes Relay ist. Von dort gehen sie wiederum zu einem meiner vServer, der sich um die finale Zustellung kümmert.
In Deiner Situation würde ich einfach ssmtp o.ä. Alternativen nutzen, das klingt vernünftig. Ich habe mich damals dagegen entschieden, u.a. weil ich explizit überall einen vollständigen Postfix haben möchte. Manche Mails bleiben rein lokal und werden auch nur lokal gelesen.
Eine Queue zu haben bedeutet halt auch wieder Wartungsaufwand… 
Es waren mehrere interessante Artikel, sonst hätte ich sie sowieso einzeln gekauft. Ist aber nicht so tragisch…
Wenn jemand mit seinem gelesenen Magazin in den nächsten Tagen € 6,90 inkl. Versand nach AT unterbieten kann, dann kaufe ich das PDF nicht… 
(bitte keine Raucherhaushalte)
Da will man einmal die iX lesen und dann ist das Ding ausverkauft. Jetzt bleibt mir nur noch die PDF-Ausgabe… 
Man erlebt immer wieder neue Dinge: Verschwundene Mails bei Dovecot mit NFS…
Ursache und Mails gefunden!
Die Mails sind auf der lokalen Platte gelandet, im normalerweise leeren Mountpoint-Directory. Dieser hatte die falschen Rechte, wodurch Dovecot dort fälschlicherweise schreiben durfte. Das ist wohl bei einer früheren Migration passiert. Auf die Idee bin ich leider erst jetzt gekommen, dass die im quasi versteckten Ordner liegen könnten, über den drüber gemountet wird. Der jahrealte Timestamp aus der Logmeldung kam mir dann doch zu verdächtig vor.
Mails in den (richtigen) new-Ordner vom Maildir kopiert » alles da. Dass die Sieve-Regeln dadurch umgangen wurden, ignoriere ich einfach mal.
Und beim Mointpoint darf jetzt korrekterweise nur noch root schreiben. Dadurch sollte das nicht mehr passieren… 
Man erlebt immer wieder neue Dinge: Verschwundene Mails bei Dovecot mit NFS… 
12 Mails wurden mittels Fetchmail abgerufen, an Dovecot übergeben und erfolgreich gespeichert. Was dann passierte, ist mir schleierhaft. Die einzige Spur sind jene Fehlermeldungen. Offenbar kam es da zu einer Art Race-Condition, weil der NFS-Server durch eine Netzwerkstörung kurzfristig (<1 Minute) nicht erreichbar war und das Handy gleichzeitig über IMAP zugegriffen hat.
Bei einem anderen Account, bei dem zur selben Zeit 3 Mails über Fetchmail abgerufen wurden, liegen alle wohlbehalten im "new" Ordner.
Wenn Du zuerst alles blockierst, greifen die Regeln danach natürlich nicht mehr. Also entweder die Reihenfolge umdrehen (ACCEPT vor DROP) oder statt -A (Append) mit -I (Insert) arbeiten. Alles gut zu sehen, wenn Du Dir alle Regeln einmal anzeigen lässt.
Sehr interessant, da es ja nicht alle Ziele betroffen hat… 
Dann würde ich mich einmal mit dem Support vom Internetanbieter und eventuell auch netcup in Verbindung setzen. Vielleicht gibt es da irgendwo ein schlechtes Peering/Routing. Das sollte sich eigentlich aufklären lassen.
Und vorher eventuell noch einmal im Rettungssystem testen, nur für den Fall, dass der netcup Support es später so möchte… 
Sollte 1 Gbit/s sein.
seyfidin Ok, dann sollte es daran nicht liegen.
Dann würde ich mich einmal mit dem Support vom Internetanbieter und eventuell auch netcup in Verbindung setzen. Vielleicht gibt es da irgendwo ein schlechtes Peering/Routing. Das sollte sich eigentlich aufklären lassen.
MfG Christian
SFTP/SSH/usw. verbrauchen wesentlich mehr Ressourcen als ein simpler HTTP(S) Download. Wie sieht denn die CPU-Auslastung aus, während so ein Upload läuft?
MfG Christian
Verwendest Du IPv4 (A) und IPv6 (AAAA) Records für Den Hostnamen hinter dem MX-Record oder nur eines davon?
100% CPU-Last könnte auch auf eine Kernel Panic hindeuten. Und sofern der "Bildschirmschoner" an ist, sieht man dann afaik über die VNC-Konsole auch nichts davon, außer viel Schwarz.
MfG Christian
Zeigen die Logs irgendwelche Auffälligkeiten? Was stand als letztes vor dem Ausfall drinnen?
MfG Christian
Das klingt stark danach, als ob die UTC-Zeit von extern kommt, wie oder woher auch immer. Bei Linux landet z.B. standardmäßig UTC in der RTC und nicht wie bei Windows üblich in der jeweiligen Zeitzone. Teste einmal, ob die folgende Registryänderung nach einem Neustart etwas bringt: UTC in Windows
MfG Christian
Sollte prinzipiell egal sein, weil jeder halbwegs vernünftige Serverdienst (die hinter SMTP/IMAP/POP3/… stecken) keine leeren Passwörter bei der Anmeldung entgegen nimmt.
MfG Christian
Ich frage mich gerade, welchen Zweck diese Angabe hat. Wird das überhaupt irgendwo (öffentlich) angezeigt? Oder dient das rein einer Statistik?
MfG Christian
