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]
Guten Tag zusammen,
ich erwecke dieses Thema erneut zum Leben, da ich zurzeit an derselben Fehlermeldung wie Bud hänge.
Domain wurde bei netcup als Externe Domain eingetragen.
Beim Orangenen Hoster, habe ich die geforderten Eintragungen durchgeführt.
Die Domain wird auch von netcup erkannt und auch entsprechend weitergeleitet.
Webmail wurde aktiviert. Mailadressen hergestellt, das versenden der Nachricht über Webmail läuft einwandfrei.
Allerdings erreiche ich keine Nachrichten, wenn ich eine Testmail schreibe, kommt die Rückmeldung.
Domain habe ich abgeändert.
<para@domain.email>: host mx2e30.netcup.net[91.204.46.XX] said: 554 5.7.1
<para@domain.email>: Relay access denied (in reply to RCPT TO command)Ich hab die obligatorischen 24h abgewartet, allerdings keine Verbesserung. Gibt es bestimmte Dinge, die ich beim Orangenen Hoster zu beachten habe?
Immerhin konnte ich bei der Domain nur ein A-Record erzeugen. Für die "mail.domain.email" habe ich separat eine Subdomain erzeugt und dort die A-Record erstellt, mit der von netcup definierten IP eingetragen.
Leider ohne Erfolg, selbst ohne dieser Subdomain hatte ich kein Erfolg.
Kurzum, die Punkte bei den DNS Records werden automatisch erzeugt, ich hab durch das Thema hier bereits drauf geachtet.
Beim Orangenen Hoster, habe ich die geforderten Eintragungen durchgeführt.
Da steht ein bisschen zu viel drinne, der relay.rzone.de muss da raus.
Mailadressen hergestellt, das versenden der Nachricht über Webmail läuft einwandfrei.
Allerdings erreiche ich keine Nachrichten, wenn ich eine Testmail schreibe, kommt die Rückmeldung.
Domain habe ich abgeändert.
Das ist für mich unverständliches Deutsch
Hallo H6G,
vielen Dank für deine schnelle Antwort.
Der relay.rzone.de, wurde automatisch eingetragen, weil ich bei der MX-Records den Backup-Mailserver vom Hoster ausgewählt hatte.
Ich hab das jetzt einmal deaktiviert und er Eintrag ist somit verschwunden.
Nach einer kurzen Testmail hat es zumindest noch nicht funktioniert, aber es kann ja noch etwas dauern, bis die Einstellungen übernommen werden.
Zu meinem unverständlichen Deutsch, hab vorhin in Eile geschrieben, da passiert mir solche "Gedankengänge" ziemlich häufig, sorry
Bei netcup habe ich die E-Mail-Adressen hergestellt und konnte erfolgreich E-Mails aus dem Webmail Oberfläche verschicken.
Allerdings kommen keine E-Mails ans Postfach an, sobald ich an para@domain.email eine Nachricht versende, erscheint folgende Fehlermeldung.
<para@domain.email>: host mx2e30.netcup.net[91.204.46.XX] said: 554 5.7.1
<para@domain.email>: Relay access denied (in reply to RCPT TO command)
weil ich bei der MX-Records den Backup-Mailserver vom Hoster ausgewählt hatte.
Ich hab das jetzt einmal deaktiviert und er Eintrag ist somit verschwunden.
Super. In dem Fall würde ich jetzt noch eine Weile warten, damit sich der Mailserver auch zuständig fühlt.
Es funktioniert, danke H6G.
Damit hätte ich zwar nicht gerechnet, aber nun funktioniert es.
Damit hätte ich zwar nicht gerechnet, aber nun funktioniert es.
Ich bin auch immer wieder von mir selbst überrascht. 
