Beiträge von cltrmx

Zitat von mainziman

verwechselst Du hier Ursache und Wirkung;

gäbe es keinen doofen Absender, dann bräuchte es diese Blacklisten überhaupt nicht;

ergo die Menge der Absender ist Schuld an der MIsere, nicht die Menge der Empfänger;

Das ist mir schon klar, bloß bin ich trotzdem als Anbieter nicht schuldig ;).

Zitat

eben, ohne Verifikation, dass der Absender ausschließlich gut gesinnt ist, keine Mailannahme

(Kollateralschäden nicht ausgeschlossen)

Ach so, klar, dass du mal eben 100k IPs blockst, weil eine Hand voll davon Spam verschicken. Dann sind aber trotzdem noch nicht die validen Absender schuld, dass ihre Mails nicht angenommen werden können.

Zitat von mainziman

ist Deiner Meinung nach dann jeder selbst schuld, wenn dessen Mailbox zugemüllt wird?

und es darf nicht persönlich genommen werden;

Nein, aber es sind diejenigen Schuld, die eine Blocklist verwenden, welche einfach großflächig ganze Netze sperrt, weil eine Hand voll IPs daraus Spam verschickt haben. Wenn ich als Mailserver-Betreiber den ganzen IPv4-Adressbereich sperre, darf ich mich auch nicht wundern, wenn mir die Nutzer:innen aufs Dach steigen.

Das Ganze muss ins Verhältnis gesetzt werden.

Zitat von mainziman

f. Unfug halte ich ehrlich gesagt, dass Absendende, welche durch Blacklists es nicht mehr schaffen Mails zuzustellen die Schuld den Empfängern in die Schuhe schieben.

Okay, dann kläre mich bitte mal zu folgendem Sachverhalt auf: Ich betreibe einen Mailserver bei einem Betreiber, dessen gesamtes AS auf der Blacklist steht. Ich habe keinerlei Einfluss darauf, da der Spam nicht von meiner IP kam. Was genau meinst du, wieso es dann meine Schuld sein sollte, wenn meine (legitimen) Mails nicht zugestellt werden können?

Zitat von mainziman

wie meinst des?

Zitat von sudo

Interessanter Artikel zu UCEPROTECT:

https://blog.sucuri.net/2021/02/ucepro…bls-go-bad.html

Zitate aus der Quelle:

Zitat

After a thorough investigation, we discovered that the RBL provider uceprotect[.]net has listed a wide range of IPs (including our own) as notable reputed spammers, despite the fact that many servers are not even set up or capable of sending email content

Zitat

I have port 25 (the service which servers use to relay emails) fully blocked, as it draws attention and fills up my logs with failed login attempts. That doesn’t prevent UCEPROTECT from listing that IP as malicious on their RBL as well.

Zitat von mainziman

und wenn UCEPROTECT die Daumenschrauben anzieht, dann sollte das doch den einen od. anderen Versender von Newslettern od. generell Massenmails

zu denken geben, dass sie evtl. doch etwas zu aggressiv sind/waren ,,,

Das bringt mir als Mailserver-Betreiber aber nichts, wenn UCEPROTECT gefühlt den halben Adressbereich des öffentlichen Internets sperrt, weil da eine Hand voll IPs Spam geschickt haben. Weiter oben wurden ja schon Beiträge verlinkt, durch die erkenntlich wurde, dass sogar IPs als gefährlich gesperrt werden, die nicht mal Mails verschicken können.

Zitat von mainziman

tab den Mailhostern darfst keine Schuld geben, es handelt sich hier um einen Systemfehler;

Ich denke schon, dass man Mailhostern, die UCEPROTECT verwenden, Schuld geben darf.

Zitat von mainziman

klar, nur was hat der Datenschutz damit zu tun ob man ein SMTP-Relay nutzt od. nicht?

Habe gehört es gibt da Leute, die das generell uncool finden, wenn ihre Daten bei Dritten vorbei geschoben werden.

Zitat von andreas.

Kannst du nicht wie eventuell schon viele andere Netcup Kunden auch einen SMTP-Relay-Server - ziemlich unprofessionell - von z.B. mai*ox.org nutzen?

Ich denke, dass das für viele z. B. aus Datenschutzgründen einfach nicht realisierbar ist oder?

Bei mir war es so, dass sich nach der ersten Bestellung innerhalb von ein paar Minuten ein Supportmitarbeiter telefonisch bei mir gemeldet hat. In dem Gespräch wurden dann (einfache) Fragen zu meiner Wohngegend gestellt um zu verifizieren, dass ich auch wirklich dort wohne.

Vermutlich wird das bei der auch der Fall sein.

Zitat von miednr

Entdecke gerade in Plesk folgenden Hinweis:

Könnte es an den SSL-Zertifikaten liegen? Ich habe mit dem Browser eine sichere Verbindung herstellen können.

Das war auch meine Vermutung. In einem anderen Thread hier im Forum passiert aktuell etwas ähnliches, deswegen bin ich drauf gekommen. Interessant, dass dein Mail-Programm nur so eine unspezifische Fehlermeldung ausspuckt!

Schließe mich aber DerRené an: Es wäre sinnvoll, wenn das mit dem Zertifikat mal jemand prüft. Biete mich dafür (per PN) auch gerne an.

Was hast du denn für Parameter für die Verbindungsdaten (Servereinstellungen) eingegeben?

Zitat von iggypop

ja, aber wo finde ich die daten (managed PS 8000 SSD G8.) bzw muss ich bei den dns einstellungen etwas ändern?

Die Daten findest du normalerweise im CCP oder bei den DNS-Einstellungen des entsprechenden Pakets. Die DNS-Einstellungen müssen nicht verändert werden, wenn ich das gerade richtig sehe.

Moin!

Ich kenne mich mit den managed Servern nicht aus, denke aber, dass das Verhalten ähnlich wie bei den Webhosting-Paketen ist.

Bei diesen gibt es auch immer die "eigene" Zone für den Mailserver (bspw. mail.domain.de), aber die Zertifikate laufen auf der Subdomain von Netcup (bspw. mx1234.netcup.net). Das Verhalten ist dann genau, wie du es beschrieben hast, da das Zertifikat nicht für die Subdomain mail.domain.de ausgestellt wurde.

Vielleicht kannst du herausfinden, wie der "richtige" Hostname deines managed Servers ist und diesen als Email-Server-Domain eintragen? Dann sollte der Zertifikatsfehler verschwinden.

Zitat von ArtCore7

Muss man vorsichtig sein, bin ich auch schon drauf reingefallen:

https://www.google.com/amp/s/www.tech…-security-flaw/

Wenn das Programm unter Docker läuft, kann der Port doch auch einfach nicht auf dem bridge-Device freigegeben werden oder?

Zitat von Ringelnatz

Aus Interesse, habt ihr inzwischen was gehört? So oft wie das Problem in letzter Zeit vorzukommen scheint sollte die Behebung für den Support doch längst Routine geworden sein ...

Mir hat der Support gestern geantwortet, siehe hier.

Update meinerseits bzw. des Supports:

Ab gestern Nachmittag (ca. 24h nach dem Ausfall) wurde die Domain durch die meisten Nameserver wieder korrekt aufgelöst. (Ich konnte Emails bekommen, juhu!) An den Einstellungen hatte ich nichts mehr geändert.

Der Support hat sich dann heute bei mir gemeldet und meine Anfrage an die entsprechende Abteilung weitergegeben. Dabei kam folgende Antwort heraus:

Zitat

Code

Es ist im Nachhinein natürlich immer ein wenig schwierig, den genauen Ablauf zu rekonstruieren. So wie ich es sehe, gab es eine Einschränkung bei der Registrierungsstelle, weswegen die Änderung nicht zeitnah übernommen wurde. Sollte so etwas nochmals auftreten, wechseln Sie am besten erst einmal zurück auf die netcup Nameserver und kontaktieren uns, dann untersuchen wir das gerne für Sie, bzw. nehmen auch Kontakt mit der Registrierungsstelle auf, falls nötig.

Meines Verständnisses nach ist das beschriebene Vorgehen genau jenes, was auch die Mitglieder des Forums empfohlen haben. Bleibt zu hoffen, dass dieser "Schluckauf" der Registrierungsstelle in Zukunft nicht mehr so häufig auftritt.

Danke noch mal an alle, die mir hier geholfen haben

Ich habe den Support am Sonntag per Kontaktformular im CCP wegen einer DNS-Sache kontaktiert und bisher noch keinerlei Antwort erhalten. (Der Fehler wurde in der Zwischenzeit aber scheinbar behoben.)

Wie lange wartest du bereits, masdot ?

Zitat von H6G

Ein Klassiker - den Bug gibt es öfter mal bei Netcup zu sehen.

cltrmx hier hilft es, wieder die Netcup Nameserver einzustellen und danach, mit Abstand von 1 bis 4 Stunden wieder die externen Server einzutragen.

Ggf. ist das auch ein Fall für den Netcup Support

Das hatte ich heute Nachmittag schon mal versucht (zugegeben ohne 4h zu warten). Da waren bei den "großen2 DNS-Servern überall wieder Netcup eingetragen und alles hat funktioniert.

Habe den Support kontaktiert, mal schauen, was da bei rum kommt.

Kleine Ergänzung: Interessanterweise scheint das aber nur der Fall zu sein, wenn noch gecachte Einträge vorhanden sind.

Frage ich z. B. das SuperTool (https://mxtoolbox.com/SuperTool.aspx), so bekomme ich folgende Antwort:

Zitat

Sorry, we couldn't find any name servers for '<domain>.com'

Ähnlich schaut es bei dnschecker.org aus (Screenshot).

mainziman

$ curl -I https://bitreporter.de/fritzbox/zugriff-zum-heimnetz-trotz-ds-lite-ohne-ipv4-adresse/
HTTP/2 200 
server: nginx
date: Sun, 31 Jan 2021 16:51:31 GMT
content-type: text/html; charset=UTF-8
content-length: 293756
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
last-modified: Sun, 31 Jan 2021 16:30:14 GMT
etag: "47b7c-5ba34c083fbde"
accept-ranges: bytes
vary: Accept-Encoding,Cookie
cache-control: max-age=3, must-revalidate
expires: Sun, 31 Jan 2021 16:51:34 GMT
strict-transport-security: max-age=31536000; includeSubDomains