Der netcup-Server verschickt stündlich immer wieder die gleiche Email

  • Die Antwort gibt's doch aber nur, wenn es den usernamen auch gibt, oder?

    Auf meine usernamen kommt man sicher nicht zufällig. ^^ (Für root habe ich kein ssh-Login mehr erlaubt)

    Entgegen vieler Meinungen hier nutze ich den direkten login per Root und das mit nem Passwort, ohne key file.


    Hatte früher mal so Spielereien wie Port knocking etc drin... aber war mir alles zu nervig. Und so komm ich eben immer von unterwegs dran. Das Passwort liegt in Bitwarden 😂


    Aber wie gesagt, bei mir handelt es sich ausschließlich um ein Hobby, hab da nix wirklich wichtiges auf den Servern.

  • Und so komm ich eben immer von unterwegs dran.

    Das ist auch mir wichtig.

    Ich bin deshalb bei (ungewöhnlichen) usernamen und (einigermaßen) langen Passwörtern geblieben.

    Zusammen mit Portänderung und ufw scheint mir durchaus schon sehr guten Schutz zu bieten.

    fail2ban habe ich zwar auch draufgelassen, aber seit der Portänderung ist das arbeitslos.


    Im übrigen hat die Beschäftigung mit meinem privaten rootserver auch schon positive Auswirkungen auf unseren "Bertriebsserver" gehabt

    Unser Admin hat sich von mir überzeugen lassen, den ssh-Port zu ändern. :)

    Ist sowieso der eigentliche Grund, warum ich das hier mache. Ich werde irgendwann (eher früher als später) dessen Aufgabe übernehmen müssen. Hab von allen Mitarbeitern das kürzeste Holz gezogen. ;-)


    btw:

    Ich bin hier auch auf lynis gestoßen. Empfehlenswert?

  • Ich glaube wenn ich vorschlage den ssh Port zu ändern (auf den "Betriebsservern") werde ich im RZ aufgehangen :D Aber wir haben (neben den normalen Servern) auch genug Kisten laufen, wo wir uns über Login Versuche freuen. Da wird dann alles schön protokoliert, durch Logserver/Datenbanken und SIEM Lösungen gemacht und analysiert.

  • Leider ist das Problem, welches ich im Eingangsposting angeführt habe wieder aufgetaucht. :(

    Ich bekomme wieder stündlich die gleiche E-Mail und das obwohl mein Server diesmal komplett ausgeschaltet ist.

    Kann also nicht jedesmal neu von dort kommen und ich kann somit auch nicht eingreifen.


    Ich habe diesbezüglich nochmal den Support angeschrieben.

    Schau mer mal...

  • Wird der Server im SCP als gestoppt angezeigt?

    Per default sind Server auf Autostart und wenn ein VPS auf einen anderen Node migriert wird, startet der ohne Zutun einfach wieder.

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Ja, der Server ist definitiv gestoppt.

    Das Problem hat sich allerdings nach 14 Zustellungen der eMail von selbst "gelöst".


    Die eMail ging von meinem vServer per smtp über das dort eingerichtete msmtp gestern Abend ab. (Ich verwende msmtp, da ich nur ausgehende eMails benötige, also keinen echten Mailserver)

    Die eMails werden also per smtp über eine meiner E-Mail-Adressen meines Hostingpaketes (auch bei bei netcup) verschickt. Von dort wurde diese E-Mail auch korrekt an die Zieladresse bei gmx übermittelt und kam dort an.


    Nach Beendigung meiner Arbeit auf dem Server habe ich diesen heruntergefahren. Danach trudelte diese eMail dann aber doch noch stündlich erneut bei gmx ein.

    Alle E-Mails hatten die gleichen Zeitstempel bezüglich Versendung von meinem Server, die Weiterleitung von mx2f83.netcup.net erfolgt aber offenbar stündlich neu. (Auch am Zeitstempel zu sehen) Im Konto der Versandadresse kein Hinweis darauf.


    Bis vorhin, da kam dort eine "Undelivered Mail Returned to Sender" eMail an von "MAILER-DAEMON@mx2f83.netcup.net" mit der Fehlermeldung:

    <#######@gmx.de>: lost connection with 46.38.225.35[46.38.225.35] while sending end of data -- message may be sent more than once


    Danach war der Spuk zuende.

  • Ja, der Server ist definitiv gestoppt.

    Das Problem hat sich allerdings nach 14 Zustellungen der eMail von selbst "gelöst".


    ...

    und weiter geht es mit den Dauer-eMails :)

    (Mittlerweile habe ich mich dran gewöhnt ;))


    Die Infomail vom weekly cron wird seit heute morgen stündlich vom netcup-Mailserver verschickt, ging aber nur einmal von meinem Server ab, wie man im (nun vorhandenen) logfile sehen kann.

    Support ist nicht hilfreich. Sinngemäß: "Problem liegt nicht bei uns".

    Mag ja vielleicht sein, aber wenn das auch weiterläuft, wenn mein Server komplett abgeschaltet ist, sehe ich nicht so viele Ansatzpunkt für mich..

    Ich werde nun erstmal die Adresse, über die per smtp verschickt wird, zu einem anderen Anbieter verlegen und dann auch mal die Zieladresse für die Systemmails ändern.

    Wenn das alles nix bringt, versuche ich mal nullmailer, statt mstmp. Vielleicht liegt es ja am Format der emails die msmtp rausschickt.

    Zum Schluss lande ich dann wahrscheinlich doch bei postfix.^^


    Ich sehe das mittlerweile gelassen, als sportliche Herausforderung und halte euch auf dem Laufenden. :)

  • Nein.

    Ist eine Systemmail von root (Cron daemon) an root ("/etc/cron.weekly/update-notifier-common: New release '18.04.3 LTS' available")

    Für root ist als alias meine gmx-Adresse angegeben und dorthin wird auch korrekt verschickt. Ging nach msmtp-logfile auch nur einmal raus, kommt aber stündlich neu an bei gmx, auch nach shutdown des servers.

  • Ich habe ja schwer den Eindruck, dass es an den From/To-Feldern in den E-Mails liegt.


    Auch bei den Tests mit mail() aus Skripten heraus, trat diese seltsame Verhalten (wenn ich das Recht in Erinnerung habe) nur dann auf, wenn dort keine korrekte eMail Adresse angegeben war. Kommen aber an diese emails.


    Auch hier steht ja wieder in der empfangenen E-Mail

    From: root (Cron Daemon) <>

    To: root <>


    Ebenso die Problememail von gestern:

    From: AndererBenutzer <>

    To: root <>


    Eine Testnachricht von der Konsole an root lief problemlos. Die kam an als

    From: <Meine SMTP-Adresse>


    Auch alle anderen eMails aus Anwendungen sind OK.


    Da muss ich irgendwo in der Konfiguration evtl. noch nachbessern. Muss nur noch rausfinden wo. Und warum bei den Nachrichten vom crondaemon an root da die Adresse nicht korrekt eingesetzt wird. Kann man evtl. dafür irgendwo defaults setzen?

  • Verwunderlicher Fall :D


    Sind die Header der Mails gleich, also auch Date, X-PPP-Message-ID und X-NC-CID und so?

    (kopiert aus Post #7)

    Vielleicht verwirren die erwähnten fehlenden Header den Netcup Mailer...


    Update: Gibt's evtl mehr als eine .msmtprc? VIelleicht lungert je nach User eine im Home, die Unsinn enthält (ist mir schon mal passiert)?


    Update 2: In der Crontab kannst du Sender und Empfänger definieren:

    Code
    1. MAILFROM=from@example.com
    2. MAILTO=to@example.com

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Deine Mail hat mehrere Empfänger, bzw eine falsch eingerichtete Weiterleitung.

    Einer der Empfänger schlägt fehl, also versucht das Relay wieder und wieder und wieder zuzustellen.

    Bei einem klappts, beim nächsten nicht.

  • "Vielleicht verwirren die erwähnten fehlenden Header den Netcup Mailer..."

    Der Verdacht drängt sich mir auch auf.


    Sieht wirklich so aus, als läge es am From-Feld


    Probleme z.B. bei:

    Code
    1. From: meinedomain.de // email über php-skript mit mail() - Da hatte ich das name@ vor der domain vergessen
    2. From: einuser // systemnachricht an root über falsche passworteingabe meinerseits auf der konsole
    3. From: root (Cron Daemon) // weekly cron nachricht


    Alle OK z.B. bei:

    Code
    1. From: Meine Domain <mail@meinsmtpaccount.de> // email über php-skript mit mail() - Diesmal mit korrektem Adressformat
    2. From: mail@meinsmtpaccount.de // Testemail von der Konsole aus (root) mit msmtp.
    3. // msmtp löst den alias root korrekt auf.
    4. From: ... Beta <ganzandereadresse@gmx.de> // Testemail der joomla-Installation


    Das sieht mir sehr danach aus, als würde es am From-Header liegen. (Oder an damit verbunden Feldern)

    Jetzt muss ich nur noch rausfinden, warum bei den Systemnachrichten (bei allen, nicht nur bei cron) "root" nicht durch den email-alias ersetzt wird. (Und während ich das schreibe, kommt mir da so ein Gedanke...)


    Kann natürlich sein, dass das nur eine Koinzidenz ist und ich auf der falschen Spur bin.


    Den anderen Hinweise gehe ich noch nach. Jetzt muss ich aber erstmal raus ins echte Leben. ;) Komme erst morgen Abend wieder an meinen PC

    Ich will auch nicht an zu vielen Stellschrauben auf einmal drehen, denn ich will das Problem nicht nur abstellen, sondern hinterher auch gerne wissen, woran es lag.

  • Letzter Stand der Dinge:
    Ich lasse msmtp nun über die eMail-Adresse eines anderen Providers per smtp verschicken und alles läuft (bis jetzt) reibungslos. Auch bei den Test-Emails, die vorher diese Wiederholungen ausgelöst haben. (Sehr ausführlich habe ich das allerdings nicht getestet)
    Nur wenn es über den netcup-Mailer läuft, gibt es dieses Verhalten bei einigen E-Mails.
    Für mich ist das Problem damit erstmal "gelöst".

    Verwunderlicher Fall :D


    Sind die Header der Mails gleich, also auch Date, X-PPP-Message-ID und X-NC-CID und so?

    Müsste ich mal nachsehen. Ich habe aber auch nicht mehr alle eMails.

    Hat jetzt für mich auch erstmal keine Dringlichkeit mehr. Sollte es mit der geänderten Adresse rund laufen, ist das nichts mehr worum ich mich unbedingt kümmern müsste.

  • Mittlerweile läuft alles rund.


    Ich habe bei der Beschäftigung damit auch festgestellt, dass ich ja gar keinen echten eigenen Mailserver aufsetzten musste, um eMails zu senden und zu empfangen, sondern dass es auch nur mit mstmp geht. Und das mit einer Adresse die zur Serverdomain gehört (mail@mydomain.de)

    Das ging ratzfatz, weil ich parallel auch ein Hosting-Paket bei netcup habe:


    Eine Inklusivdomain (mydomain.de) die ich übrig hatte auf den vServer zeigen lassen, im Hostingpaket eine email-Adresse dazu erstellt (mail@mydomain.de), auf dem Server in der msmtp-Konfiguration mail@mydomain.de als "from" eingetragen und dann über irgendeine beliebige andere Adresse als smtp verschicken.


    Funktioniert bis jetzt prima in beide Richtungen. :)

    Warum sich mit einem eigenen Mailserver rumquälen, wenn man den des Hostingpaketes für sich arbeiten lassen kann. ;)

  • Nur noch ein kurzer Nachtrag:


    Ich habe ja inzwischen etliche weitere Mailserver-Installationen und -konfigurationen auf mehreren Servern durchgeführt und mein ursprünglicher Verdacht hat sich dabei (fast zur Betonfestigkeit) erhärtet.


    Wenn man eMails mit msmtp, per smtp über einen externen Mailer verschickt (Ich will keinen kompletten, empfangenden Mailserver aufsetzen) und dafür den netcup-Mailer wählt, dann lässt der sich aus dem Tritt bringen, wenn im From-Header keine sinnvolle eMail-Adresse eingetragen ist. (z.B. nur "root")

    Der netcup-Mailer verschickt dann die gleiche eMail stündlich, obwohl diese korrekt zugestellt wird, bis er irgendwann (so nach ca 15 Versuchen) endlich aufgibt. (Heute bin ich wieder in diese Falle getappt)


    Am verschickenden Server liegt es nicht, denn das läuft weiter, auch wenn dieser komplett heruntergefahren ist.

    Am Empfänger liegt es auch nicht. Das tritt bei allen auf, an die ich verschickt habe.

    Das Phänomen tritt auch bei keinem anderen Mailer auf, den ich als smtp-Versender getestet habe.


    Da ich gerne weiterhin eine netcup-Adresse für diese Zwecke nutzen will (weil dann email und domain zusammen passen) bin ich jetzt doch von msmtp auf postfix umgestiegen, weil ich dort sicherer dafür Sorge tragen kann, dass die Header korrekt gesetzt sind.


    Der Support (über den ich ansonsten nicht klagen kann!) wollte davon ja nicht wirklich was hören. ("Problem liegt nicht bei uns")

    Ich will ja auch gar nicht meckern. Für mich habe ich das Problem ja zufriedenstellend gelöst. Wollte nur darauf aufmerksam machen und diesen (letzten) Beitrag setze ich nur ab, als Hinweis, falls jemandem mal das gleiche passiert. (Das das nicht öfter passiert, liegt wahrscheinlich nur daran, dass kein Schwein mstmp verwendet und alle auf postfix setzen)

    Wäre ich allerdings netcup, würde ich schon wissen wollen, woran das liegt. ;-)