Beiträge von Rudi78

Man wir sehen ... Besten Dank @all für den Input jedenfalls. Das Problem ist jetzt anderweitig gelöst: Beim Anbieter kommunizieren jetzt über die iCloud eMail mit mir.

Man wird sehen ob ich an anderer Stelle über das Problem stolpern werde. Es betrifft ja - interessanterweise - nicht den eMail Schriftverkehr mit dem Support, sondern immer nur die automatischen eMails (PW-Reset bei ERC.edu sowie checkyeti - bei letzteren auch die automatische Bestätigung eines Skikursbuchung und der mehrfachen, erneuten Anforderung).

DNSSEC ist jetzt sowohl für die Domain wo der MX liegt als auch für A/AAAA Record des Mailservers aus seit 48h.

Im TCP Dump kommt nix an auf Port 25. IPv6/IPv4 sind per Telnet problemlos erreichbar.

Ich glaube das Problem muss jemand anders lösen. Wobei es mir das erste mal im Januar aufgefallen ist. im Dezember bin ich auf nen Server in Wien gewechselt; ggf. erwarten irgendwelche Anbieter das .de Domains in Deutschland gehostet werden...

Zitat von KB19

Spontaner Schnellschuss: Eventuell mal einen DNSSEC-Test bei der Domain durchführen? Inaktiv wäre kein Problem, aber mit Fehlern aktiv wäre eine mögliche Ursache.

Danke. Da hat gerade eine Testseite ein Fehler ausgeworfen; ein Timeout bei „All Queries to third-dns.netcup.net„

Werde DNSSEC deaktivieren. Bin morgen keine Besserung, nehme ich mir den TCPdump zur Hilfe.

Danke !

^Hallo,

ich Betreiben einen vServer mit Postfix als smtpd auf Ubuntu 22.04 LTS.

Es funktioniert alles einwandfrei; ein / ausgehend zu T-Online, Googlemail etc. sind seit Jahren kein Problem.

Nur von 2 Dienstleistern kommen automatisch erstelle eMails nicht an: checkyeti.com sowie cosy.erc.edu

Sie tauchen auch keine Verbindungsversuche im mail.log auf, und bleiben auch laut Syslog nicht in der Firewall hängen; es wird augenscheinlich gar nicht versucht mir die eMails zuzustellen.

Irgendwelche Tipps wo ich suchen soll - bevor ich in das Detail meiner Konfiguration gehe ?

Div. SMTP/SMTPD Tests passiert mein Server auch einwandfrei. SPF/DKIM/DMARC etc. sind auch korrekt. Wobei das nicht unbedingt erklärt, das es Nichtmals eingehend Verbindungsversuche gibt.

Die Anbieter sind leider ziemliche Monopolisten; bei checkyeti habe ich das ganze auf eine iCloud Adresse umgestellt, nachdem da Buchungsbestätungen hängen geblieben sind. Bei erc.edu wird das etwas schwieriger... Interessanterweise laufen Supportanfragen einwandfrei durch.

Zitat von engine

Relativ unverständlich wieso das eingestampft wurde.

Vermutlich weil es die Firewall im VCP nie für KVMs eigenen Kernel, sondern nur für VM mit Shared Kernel gab ?

Bei den alten VPS war ja selbst kein Firewall realisierbar; der musste vor der VM liegen; da wo der Kernel war.

Ich bin mit meinen Wunsch auch gescheitert.

"vielen Dank für Ihre Anfrage.
Sicherheitsbedingt können wir Ihrem Wunsch nicht entsprechen, da Änderungen an der Laufzeitumgebung, eines Webhostings, globale Auswirkungen auf alle Kunden der Node haben."

Hmm.

Solche "Firewalls" bringt aber nix, wenn durch einen Sicherheitslücke ein Script im Dokumentenroot abgelegt wird und direkt - also nicht über / => Index.php - aufgerufen wird. In sofern ist das nur Scheinsicherheit. Oben genanntes ist halt bei meiner Installation passiert.

Wirklich sicher ist es nur, auf PHP Ebene halt entsprechende Funktionen zu deaktivieren. Das mache ich auf dem vServer standartmässig. Das auf einem Webhostingpaket, wo keine Mail Account aktiv sind, trotzdem von local in alle Welt versendet werden kann, darauf muss man erstmal kommen.

@DeCysos: Man kann die Mail Funktion und auch ein sendmail_path = /dev/null leider nicht selbst nutzen. Habe es jetzt ausgiebig versucht. Habe den Support angeschrien. Die sollte es können bzw. wo anders i Forum wurde gesagt, das sie es auch Anfrage machen.

@DeCysos. Danke, das könnte helfen. In sehr begrenzen Umfang kann man tatsächlich PHP Variablen setzen.

Mal sehen ob es dafür reicht ...

Doch, änderte es. Da geht sendmail gegen /dev/null und der Mailserver nimmt Port 25 nur Mails für bekannter User an im sinne eines localen Relais und erfordert sonst Authenfizierung via SASLauth & TLS/SSL auf 587 sowie 465.

Das dieses eine große Sicherheitslücke ist, ist ja durchaus bekannt.

Was eine Firewall da bringen soll, nunja. Ist in meinen Augen ne rausgehauene Aussage. Spammails verhindert man damit nicht.

Ist auch meine einzige Erklärung.

Es gibt tatsächlich noch einen Hinweis mit "X-PHP-Originating-Script: 31136:infodata.php", das ein kompromittiertes Script eingeschleust wurde.

Das Wordpress wird in dem Fall nicht mehr zu retten sein. Sei es drum. Dann ist ja gut, das es aufgefallen ist. Die von Netcup bereitgestellten Informationen sind aber sehr dünn. Und eigentlich bilde ich mir ein, das man ESMTP auch auf dem Localhost mal mit SASLauth o.ae. absichern sollte und auf so eine vNode keinen sendmail Aufruf gestatten. Werde den Kram wohl wieder auf einen vServer legen.

Guten Tag,

heute wurde eines meiner Webhosting Pakete gesperrt, weil es gestern zu einen Spam Versand gekommen sein soll.

Halo ist die FQDN der Hosting Node.

Das Ganze spiele sich zwischen localhost:34318 sowie localhost:10025 via ESMTP ab, wo ja üblicherweise schon nen milter sitzt. Einen Eingang des Spams von extern ist mit den mir bereitgestellten Informationen nicht zu erkennen.

Denn:

Recived By sind keine angebende. Auch keine IP anders als 127.0.0.1.

Sender soll „hosting12345@hosting12345.node123.Netcup.de“ sein.

Email Benutzer gibt in dem Hosting Paket keine. Es läuft nur eine kleines WordPress Blog dadrauf, ohne große Plugins oder relevante Last.

Ich bin in sofern etwas ratlos, wie ich das Problem eingrenzen sollte, wo sich das alles auf dem localhost des offenbar Hostingserver/Node (nicht Mailserver …) abspielen soll, geschweige denn in Zukunft verhindern soll.

Tips ? Ich habe das netcup erstmal so geschrieben und hoffen das sich das klär.

Vielen Dank !

Es ist ja kein vServer. Wenn es einer wäre, wüsste ich schnell was da los ist.