Yes. bud@netcup.de läuft auf meinem Webhosting 8000 SE BF 22, und die Domain ist bei netcup gehosted.
ok, damit sollten Änderungen im DNS schneller testbar sein.
du kannst mit dig MX example.com im ssh vom webhosting 8000 ja ganz einfach testen, ob änderungen schon im netcup-netz durch sind.
ist aber halt trotzdem keine garantie, ob die zugehörigen netcup-mailserver änderungen dann ebenfalls sofort 'sehen' oder länger benötigen.
du kannst mit dig MX example.com im ssh webhosting 8000 ja ganz einfach testen, ob änderungen schon durch sind.
Well...
bash: dig: command not foundach stimmt, sorry.
aber du hast doch mindestens einen server bei nc. dort sollte dig oder dog installiert oder installierbar sein.
Well...
Code bash: dig: command not found
ja. du musst im DNS mm123.netcup.net. (mit abschliessendem punkt) eintragen.
-
Alles anzeigender vorgeblich zuständige mailserver für example.com fühlt sich einfach (noch) nicht zuständig.
prüfe deine DNS-einträge nochmal auf korrektheit und die einrichtung eines test-postfachs hilft auch beim ausschließen von weiterleitungsproblemen.
der empfehlung (vor solchen änderungen) die TTLs runterzusetzen, schließe ich mich an.
edit: lahm() { sleep ten minutes; }
Das sich der Server nicht zuständig fühlt, kann grundsätzlich mehrere Ursachen haben:
1. DNS (wie genannt)
2. Fehlender „Grounding-Alias“ auf dem „zuständigen“ Mailserver, sprich Domain nicht als Alias eingetragen. (Du hast keinen lokalen Benutzer aber eine Weiterleitung für Catchall UND virtuellen Benutzer. Damit sind die Mails nur im virtual-Table vorhanden und loopen dort eventuell auch nach problem@...)
Und mit
3. SPF und DKIM bei der Weiterleitung schaut das auch nicht optimal aus. mm123 kann man auch per IP-Adresse "ip4:1.2.3.4 in SPF direkt einfügen, wenn er nicht über den SPF-inklude eingebunden ist. Könnte ja vorkommen.
Siehe u.a. https://support.google.com/mail/answer/175365?hl=de
ja. du musst im DNS mm123.netcup.net. (mit abschliessendem punkt) eintragen.
Ich bin etwas verwundert, da ich mir sicher bin, dass der externe Provider damals explizit darauf hingewiesen hat, dass der Punkt am Ende weggelassen werden soll, da er automatisch gesetzt wird. So war meine Erinnerung, und es hat ja auch 6 Monate lang funktioniert... Auf jeden Fall habe ich aufgrund deines Hinweises dann trotzdem mal in dessen Doku geschaut, und siehe da:
Entschuldigt meine Dummheit, aber da es aus dem Nichts heraus nicht mehr funktioniert hat, hätte ich nicht gedacht, dass es an einem der „Klassiker“ liegt.
Trotzdem vielen Dank an jeden, der versucht hat mir zu helfen 
hätte ich nicht gedacht, dass es an einem der „Klassiker“ liegt.
wirklich kein ding.
was mich noch interessieren würde, ist es der orangene berliner hoster?
ist es der orangene berliner hoster?
Nope, der grüne Domain Hoster aus Dresden 
Ich bin etwas verwundert, da ich mir sicher bin, dass der externe Provider damals explizit darauf hingewiesen hat, dass der Punkt am Ende weggelassen werden soll, da er automatisch gesetzt wird. So war meine Erinnerung, und es hat ja auch 6 Monate lang funktioniert... Auf jeden Fall habe ich aufgrund deines Hinweises dann trotzdem mal in dessen Doku geschaut, und siehe da:
Entschuldigt meine Dummheit, aber da es aus dem Nichts heraus nicht mehr funktioniert hat, hätte ich nicht gedacht, dass es an einem der „Klassiker“ liegt.
Trotzdem vielen Dank an jeden, der versucht hat mir zu helfen
Die Provider handhaben das leider unterschiedlich. Während bei einer Zone als Textfile auf der Festplatte Deines DNS-Servers der abschließende Punkt verpflichtend ist, wenn Du nicht haben möchtest, dass die Domain der SOA, um die es geht, hinten angehängt wird, sind einige Provider bei ihren Domainverwaltungstools der Meinung, dass sie ihren unbedarften Kunden den abschließenden Punkt ersparen möchten - was dann dazu führt, dass fortgeschrittene User, die absichtlich den Punkt angeben oder weglassen, weil sie RFC 1035 (Sektion 5) und RFC 1034 (Section 3.6.1) gelesen haben, dann schon einmal wie der Ochs vorm Scheunentor stehen. [Smiley: achselzuckendes Männchen]
