Beiträge von tab

    Vorstellen kann ich mir das nicht, da dies die Zielgruppe nicht hergeben wird... Ich befasse mich seit über zehn Jahren mit Webhosting, und bin dabei nie über den Begriff PostgreSQL gestoßen. Erst als ich mich mit Servern befasst habe…

    Findet man wohl eher selten in einem Shared Webhosting, möglich sein sollte es z.B. bei ubersp*ce. Da habe ich aber auch lange nicht mehr reingeschaut.

    Was hast du denn an AAAA-Records alles eingetragen im DNS der Domain? Möglicherweise die falsche IPv6, nämlich die vom Webhosting, was automatisch passiert, wenn die Domain einem Webhosting zugewiesen wird. Und das hast du ja wohl gemacht, sonst wäre es mit der Mailnutzung schwierig ;) . Falls du aber A und AAAA -Records für @ und * auf die IPv4 bzw IPv6 des Servers änderst, sollte LE auf dem Server klappen. Jedenfalls sofern du das Debian 12 minimal Image von netcup als Grundlage genommen und IPv6 nicht totkonfiguriert hast. Ansonsten sollte der Server unter IPv4 und IPv6 erreichbar sein. Die vorkonfigurierte IPv6 findest du z.B. mit "ip address" als root per SSH oder auch in der Datei /etc/network/interfaces.d/50-cloud-init.cfg

    Dafür musst du dann bei MX und eventuell mail und webmail Subdomans aufpassen, wenn du die Mailfunktion des Webhostings nutzen willst. Falls du nur per IMAP/SMTP von einem lokalen Client zugreifst, reicht ein MX mit dem entsprechenden Namen deines Mailservers (siehe Übersicht im CCP) eigentlich aus, wenn auch mail.deinedomain.tld als MX angegeben wird, muss die Subdomain mail natürlich A und AAAA Records mit den IPs deines Webhostings haben.

    Ist natürlich alles (außer DANE) richtig eingestellt. Die Probleme meines Accounts bei der Mailbox ais Berlin sind mittlerweile weg. Ich muss aber doch feststellen, dass schon einige Mails heute beim zweiten MX mit Prio 50 angekommen sind. Und das waren keine Spammer, die sowas gern mal absichtlich machen (Gerade schreib ich es, schon passierts, gerade ist eine Spam-Mail auf dem zweiten MX aufgeschlagen). Deswegen vermute ich jetzt doch, dass es mit dem fehlenden DNSSEC beim ersten MX zu tun hat, während mein Mailserver als zweiter MX in meiner Serverdomain mit DNSSEC liegt. Darauf habe ich freilich gar keinen Einfluss, die Serverdomain von webg0 ist (noch :evil: ) nicht unter meiner Kontrolle.

    Also werde ich den zweiten MX nachher löschen, der ist bei einem erneuten Notfall dann schnell wieder gesetzt und deSEC propagiert Änderungen in den Zonen auch wirklich sehr zügig. Bis morgen früh sollte der von allen relevanten Resolvern (außer vielleicht dem von der Telekom :) ) vergessen sein (TTL 1 Stunde) und zumindest keine seriösen Mails mehr bekommen.

    Irgendwie habe ich auch den Verdacht, dass manche Mailserver sich da nicht (nur) auf ihre Nameserver verlassen. Gestern Abend Mail geschickt vom Webmail der Mailbox, kam auf MX 2. Dann nochmal selber Absender, selbe Mail, aber zusätzlich ein weiterer Empfänger der selben Domain, für den ich gar keine Mailbox eingerichtet hatte auf MX 2, weil da eh nie Mail kommt. Und siehe da, beide Mails wurden über MX 1 ausgeliefert, der für beide Adressen Mailboxen hat. Gerade mal zwei Minuten nach der ersten Mail und die zweite Mail kam bei beiden Empfängern praktisch gleichzeitig an. Naja, der Herr Heinlein wird sich bei seiner Versandstrategie schon was gedacht haben ;) .

    Ja, sollte mal ersetzt werden oder man lässt es halt ganz bleiben. Rein preislich ist es ja durchaus konkurrenzfähig, aber bei den Features und beim Interface ist es wohl nicht mehr ganz zeitgemäß. Vom zuverlässigen Mailversand reden wir erst gar nicht ;) .

    DNSSEC ist nicht im Eimer, sondern dank deSEC absolut in Ordnung laut Tests. Dass der webg0 MX eben nicht aus einer Domain mit DNSSEC kommt, kann ich ja nicht beeinflussen und auch sonst niemand außer webg0. Und das mit einem MX wie z.B. mail@kundendomain.de zu ersetzen würde mir dann vermutlich an anderer Stelle um die Ohren gehauen, weil sich der webg0 MX nicht mit dem Namen melden wird. Ich werde denen mal eine nette Anfrage stellen wegen DNSSEC, ahne aber schon die Antwort. Ihre eigenen authoritativen Nameserver bieten glaube ich kein DNSSEC an. Selbst DKIM konnte man nicht selbst aktivieren, als ich das letzte Mal reingeschaut habe.

    Dass dem mailb0x.org SMTP keine IP zurückgeliefert wird kann eigentlich auch nicht sein. Er hat schon einige Mails bei webg0 abgeliefert in der Zwischenzeit. Würde er die IP nicht bekommen, würde er das wohl nicht tun.

    Naja, ich warte jetzt mal ab, solange ich kein Kundenmail auf meinem Server empfange bleibt es erst mal so. Sowie irgendwas bei mir ankommt was ich da nicht haben will, fliegt der neue MX wohl erst mal wieder raus. Dann dauert es halt im Notfall etwas, bis auf den zweiten Server umgestellt ist. Aber da müssen dann ja auch erst die Clients oder zumindest einer umgestellt werden (per Fernwartung, das bekommen die sonst nicht hin).

    Was mich daran verunsichert ist, dass normalerweise da, wie Du ja schriebst, eine undeliverable Message (D.S.N. )per Mail zurückkommen müsste, Du das aber schon beim Versuch zu senden bekommst. Aber offenbar nur für ausgewählte Empfänger.

    Jetzt frag ich mich, das die Fälle sind, wo das passieren kann: Recipient Mailbox läge am selben Server, SASL hat schon für den _Absender_ nicht hin (Relay, Positivliste, Mapping), oder wird geblockt. Es könnte auch eine falsche Fehlermeldung für ein lokales rDNS-Problem ür deine Absenderadresse bei Dir sein. Ich hatte sowas schon ewig nicht mehr.

    Das wären Möglichkeiten, die allerdings nicht zutreffen. Möglicherweise kommt jetzt Licht in die Geschichten. Im Moment fehlen mir da noch ein paar Teile des Puzzles. Soeben ist eine Mail von heute Nacht eingetroffen, von einem Konto der Kundendomain und bei mailbox.org aufgeschlagen. Eine Testmail des Kunden. mailb0x.org nimmt also zumindest mal wieder Mail von der Kundendomain an. Also wohl doch DNS. Aber, ABER, in der Gegenrichtung klappt es jetzt grundsätzlich auch, aber auch mailb0x.org schickt an den zweiten MX mit Prio 50. Sollte ja eigentlich nicht sein, aber ich habe da so eine Idee. Die Kundendomain ist ja jetzt mit DNSSEC gesichert. Aber der FQDN des MX von webg0 ist ja damit nicht abgesichert, weil die ihre Serverdomain eben nicht mit DNSSEC absichern.

    Wenn jetzt ein Server Mail abladen will und sich die MXe anschaut, berücksichtigt er (bzw sein Resolver) dann bei seiner Auswahl außer der Prio eventuell die zusätzliche Sicherheit durch DNSSEC? Sowohl netcup als auch mailb0x.org werden wohl DNSSEC auswerten...

    Edit:Auch schon wieder Makulatur. Es trudeln jetzt immer mehr Testmails ein und gerade habe ich von mailb0x.org nochmal ein Mail losgeschickt zu meiner Kundenadresse. Und es ist bei webg0 gelandet. Hmm, also wie jetzt? ^^^^;(;)

    Vielleicht doch mal was zum Background,mit der Frage wollte ich eigentlich nur endgültig ausschliessen, dass das "domain not found" nicht von einem der beiden MXe der Empfängerdomain kommt. Davon bin ich mittlerweile auch überzeugt. Mails von anderen Mailadressen mit anderem SMTP-Server kommen auch bei der Adresse an. Ein weiteres Detail ist, dass die umgekehrte Richtung von Kundendomainadresse zu meiner Adresse bei mailb0x.org auch nicht funktioniert und die Mail offenbar in einem schwarzen Loch landet, wie ja auch von MS bekannt.

    Das Ganze ist das Ergebnis einer Notfallmassnahme anlässlich des Ausfalls von webg0 gestern. Die Kundendomain ist bei webg0 im Webhosting des Kunden als externe Domain eingebunden, registriert bei d0.de und ich habe zwei Dinge gemacht

    1. Die Nameserver der Kundendomain von d0.de auf deSEC umgestellt
    2. Einen zweiten MX mit höhererem Prio-Wert auf meinem obigen Mailserver eingerichtet

    Damit wollte ich vorbeugen für den Fall, dass webg0 morgen nicht wieder funktioniert hätte (hatte bis dahin immerhin schon ca 12 Stunden gedauert) und auch für mögliche künftige Ausfälle.

    Die netcup Adventsstory dabei ist, dass eine Mail aus einem meiner Webhostings beim MX mit den höheren Kosten (Prio 50) aufschlägt, während beim Rest (also eigene Server, GMX, outlook.de, ...) die Mails wie geplant beim Haupt-MX (Prio 20) ankommen, was ich mir auch nicht so recht erklären kann. Bei den allermeisten klappt es ja.

    Solche Meldungen gibt das Mailrelay, dem Dein Thunderbird die Nachricht als Postausgangsserver aufdrücken möchte. Wäre der Fehler beim SMTP-Server der Gegenstelle des Empfängers aufgetreten, gäbe das eine Mail mit 5.5.0 Code oder bei temporären Problemen entprechend 4.5.0. 4.7.0.

    Das Mailrelay kann die Domain des Empfängers nicht auflösen. Das deutet entweder auf lokale DNS-Probleme dort oder auf DNSSEC-Probleme oder eben eine tatsächlich nicht existente Domain hin.

    So sehe ich das auch, wollte mich nur noch mal rückversichern, bevor ich nach Ursachen suche, warum der Empfängerserver die Domain nicht kennt. Ich hoffe, es ist eine vorübergehende Geschichte wegen der DNS-Umstellungen. Dass allerdings die Änderungen von gestern Abend (ca 20 Uhr) fast überall weltweit schon längst durch sind und ausgerechnet bei mailb0x.org nicht, gibt mir jetzt schon etwas zu denken. Leider kenne ich deren verwendete Resolver nicht, sonst könnte ich ja nachschauen was die da so ausliefern im Moment. Der alte MX war schon zuvor vorhanden und es gab da auch nie ein Problem, auch nicht von mailb0x.org aus. Eventuell ist tatsächlich DNSSEC und die neuen Nameserver hier das Problem, wenn die Änderungen bei der grünen Mailb0x noch nicht angekommen sind.

    Immerhin hat der Kunde heute schon einige Mails empfangen und verschickt, außer mit mir kann er wohl bisher auch mit all seinen Kunden Mails austauschen. Naja, ich stelle mich trotzdem mal auf einen potenziell stressigen Montag ein und teste alle paar Stunden mal wieder.

    kannst du den empfänger-mx antesten? (dig mx …)

    Ja, wird bei mir(!) korrekt ausgegeben. Bei der SMTP-Logging Geschichte bekomme ich 4 leere Dateien.

    Ok, habe mal zwei andere Dinge zur Aufklärung der Frage gemacht.

    1. Über den selben Alias und mailb0x.org eine Mail an eine nicht existente Mailadresse mit nicht existierender Domain (gecheckt ;) ) geschickt. Und es passiert exakt das selbe.
    2. Von einer Adresse auf meinem Server die selbe Mail an die selbe Mailadresse wie unter Punkt 1 geschickt. Hier bekomme ich dann den erwarteten Non-Delivery Report per Mail.

    Also so:

    Ja, den Mailserver und die Empfängeradresse :D habe ich dringelassen, die sind nicht besonders geheim.

    Benutzt die grüne Mailb0x etwa einen Exchange-Server? =O Muss ich schon wieder wechseln? :/ Beim Googeln der Fehlermeldung habe ich auch nur Ergebnisse aus dem Exchange-Umfeld bekommen.

    Wenn du diese Fehlermeldung als Mail erhältst, müßtest du mehr auch über den Header der Mail erfahren können. Denn im Header kann man sehr schön den Verlauf einsehen.

    Leider bekomme ich das nicht als Mail, sondern direkt als Popup von Thunderbird nach dem Absenden. Weil das auch sehr schnell geht, gehe ich davon aus, dass der "Mail-Server" maximal der SMTP sein kann. Alles andere müsste eigentlich länger dauern.

    Fehlermeldung.jpg

    Ich habe da schon mit angefangen auf einem kleinen Strota Server (VC2-2). Jaja, wie immer überdimensioniert :D, aber er soll eventuell nebenher noch UltraVNC-Server werden für gelegentliche Fernwartungen. Wireguard ist bereits auf dem Server installiert und bis auf die Clients und die Firewall (Weiterleitungen) konfiguriert. Aber wie es eben so ist, momentan habe ich dringenderes zu tun.

    Zunächst mal eine hoffentlich einfache Frage:

    Ich bekomme beim Versuch, eine Mail über einen meiner Mail-Aliase bei mailb0x.org mit Thunderbird an eine bestimmte Domain zu versenden, mehr oder weniger sofort die folgende Nachricht in Thunderbird:

    Zitat

    Senden der Nachricht fehlgeschlagen.

    Fehler beim Senden der Nachricht: Der Mail-Server antwortete:

    <it@kundendomain.de>: Recipient address rejected: Domain not found.

    Bitte überprüfen Sie die E-Mail-Adresse des Empfängers "it@kundendomain.de" und wiederholen Sie den Vorgang.

    Welcher Mail-Server gibt diese Antwort, die mir bisher in der Form noch nie begegnet ist? Ich vermute mal der SMTP-Server der grünen Mailb0x, der ein Problem damit hat, die Domain aufzulösen. Ich wäre mir da aber gern sicher, damit ich nicht weiter in alle möglichen Richtungen grabe, die nichts mit der Ursache zu tun haben.

    Alles Weitere später, abhängig vom Ergebnis der Frage, inklusive einem mit diesem Problem zusammenhängenden Adventsmysterium von netcups Mailservern.

    Wenn man aber justament kein Guthabensystem möchte, dann wäre vielleicht die Umstellung auf monatliche Rechnung für bestehende Kunden mit guter Zahlungsmoral eine Lösung. So würde nur am Ende des Monats eine Gesamtrechnung gelegt werden und in der Folge auch nur eine Buchung veranlasst werden, die dann wahrscheinlich auf über dem 50 Cent-Limit der Kreditkarte läge.

    :/?(

    In Teilen ist das ja sogar bereits realisiert. [netcup] Lars S. hat das vor einiger Zeit mal hier irgendwo geschrieben. Kleinstbeträge von z.B. Domains werden nicht sofort in Rechnung gestellt, sondern es wird gewartet (maximal bis zum Monatsende) bis der nächste, größere Betrag fällig ist und ggf. dann die aufgelaufenen Kleinstbeträge zusammen mit dem größeren Betrag in Rechnung gestellt.

    Es gab in den letzten Monaten immer mal wieder Hänger beim Umzug von Domains u netcup. In der Regel klemmt es beim Eintragen der neuen authoritativen Nameserver von netcup bei der Registry. Normalerweise kann da der Support helfen, indem der Vorgang nochmal angestossen wird.

    Siha. Mochst afoch a API dafia und schon san die am läängsten dauernden Aktionen nur no aan Entendruck entfeant.
    Press Ente to order VPS. Press Ente to stop RS Cyber Duck. Press Ente to complain to support. Pressente for Präsente and press ente to continue.

    Press ENTE to stop countdown for self destruction.

    Mal was anderes, bei meinem Hamburger Anbieter W3bg0 scheinen heute Nacht irgendwie die Lichter ausgegangen zu sein, vielleicht hat da jemand die falsche Ententaste gedrückt. Die Website und alle Server sind vom Netz und die Störung scheint deutschlandweit zu sein, also liegt die Ursache wohl eher in Hamburg. Schön, dass netcup noch zu funktionieren scheint.

    Edt: Da wäre es gut gewesen, wenn einer meiner kleinen Server mein dortiges Webhosting überwacht hätte. Ok, dann wüsste ich jetzt auch nur seit wann da nichts mehr geht.

    Also Strota will auch einen Public Key und auch ein Passwort für den User Root haben vor der Installation. Das root Passwort nur für die VNC-Konsole, per SSH ist dann der Zugriff für alle User nur mit Key möglich. Ich lege mir dann einen normalen User an, sobald der mit Key (mit Passphrase) funktioniert erlaube ich den root-Login per SSH auch mit Key nicht mehr. Den normalen User erstelle ich meist sogar ohne sudo, und mache ihn nötigenfalls per su zu root. Da außer mir sowieso niemand Zugang zu den Servern hat sehe ich den Sinn von sudo nicht so wirklich. Klar, ich könnte versehentlich die Installation zerstören durch einen als root falsch eingetippten Befehl. Aber gut ... ich kann mir auch ein Loch ins Knie bohren, mit oder ohne root. Der einzig wirklich sinnvolle Einsatz wäre höchstens für irgendwelche Installationsskripte mit sudo.

    Du meinst statt

    mein-name/community

    So eingeben:

    mein-name/community/

    Der Schrägstrich ist derzeit nicht da.

    Nein,

    /mein-name/community

    Oder ist das mein-name gar kein Unterverzeichnis, sondern soll die Domain darstellen? Aber die ist ja eigentlich "mein-name.at". Das ".at" wirst du schwerlich wegbekommen in der URL.