554 5.7.1 / Relay access denied (in reply to RCPT TO command)

    Guten Morgen zusammen,

    ich habe ein Problem beim Empfangen von E-Mails, und bei der Problembehebung, bzw. bei der Recherche zur Problembehebung, verstehe ich nur Bahnhof.

    Bzw. ist die Fehlermeldung für mich zum eigentlichen Problem nicht passend.

    Ich habe die Domain example.com extern bei einem Webhosting bei netcup eingebunden:

    Soweit kann ich hier erstmal keine Fehler entdecken. In der DNS der Domain beim externen Hoster ist zwar noch ein A-Record für webmail hinterlegt (Bild 3, letzte Zeile), allerdings ist webmail für meine Domains deaktiviert. Diesen Record muss ich noch löschen, aber das sollte aber keine Auswirkung auf folgendes Problem haben:


    Wenn ich von der E-Mail-Adresse bud@netcup.de eine E-Mail an problem@example.com oder irgendeine andere Adresse (Catchall ist ja aktiv, siehe Screenshots) sende, bekomme ich folgende Fehlermeldung:

    Code
    <problem@example.com>: host mail.example.com[XX.XXX.XX.XXX] said: 554 5.7.1
<problem@example.com>: Relay access denied (in reply to RCPT TO command)

    Wenn ich nach dieser Fehlermeldung suche, wird mir als Lösungsansatz immer vorgeschlagen, meine SMTP-Einstellungen zu überprüfen, was für mich aber absolut keinen Sinn ergibt, da die Mails auf example.com ja nur weitergeleitet werden an beispiel.de, und dort funktioniert alles. Wenn ich von bud@netcup.de an postfach@beispiel.de sende, geht das einwandfrei.

    Übersehe ich etwas, oder habe ich gar einen Denkfehler?

    Ich bin für jede Hilfe dankbar.

    Bud

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

  • Zur hilfreichsten Antwort springen
    Zitat von andreas.

    Vor dem Versenden einer E-Mail mußt du dich zuerst an dem SMTP-Server mit deinen Zugangsdaten anmelden. Dann sollte es gehen.

    Ja, aber genau das ergibt für mich ja keinen Sinn, da es sich um eine reine Weiterleitung handelt (siehe die letzten zwei Spoiler in meinem ersten Beitrag)


    Zitat von andreas.

    Die TTL der einzelnen Einträge des DNS-Servers würde ich von 86400 auf 3600 ändern.

    Generell? Ich ändere das immer auf 3600, wenn ich an den DNS-Einstellungen etwas geändert habe, und einen Tag später setze ich das wieder auf 86400.

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Mit der ganzen Zensiererei ist nicht klar, welcher Server von wo angesprochen wird, aber klar ist, dass der Server, der die Mail dort einliefert, wo der Fehler auftritt, sich nicht mit Zugangsdaten dort anmelden wird. DAS ist sicher nicht der Fehler.


    Die Fehlermeldung kommt typischerweise, wenn der Server nicht für die Domain im RCPT-TO zuständig ist, also davon ausgeht, dass die Mail unter der Zieladresse weitergereicht werden muss (im Gegensatz zum Annehmen und an eine andere Adresse weiterleiten). Deswegen ist "Anmelden" oft die Lösung, weil diese Konstellation meist dann auftritt, wenn Clients Mail für externe Adressen bei ihrem Smarthost abliefern. Der macht das natürlich nur für angemeldete Einlieferer. Wenn das irgendwo in der Kette der MTAs auftritt, ist die Zuständigkeit das Problem.

    Zitat von Bud

    Ja, aber genau das ergibt für mich ja keinen Sinn, da es sich um eine reine Weiterleitung handelt (siehe die letzten zwei Spoiler in meinem ersten Beitrag)

    Ja. Da ansonsten jede andere Person auch über diesen SMTP-Server ohne Zugangsdaten E-Mails an beliebige Personen versenden dürfte.


    Zitat von Bud

    Generell?

    Ja. Da dann auch neue Änderungen schneller bzw. nach einer Stunde greifen.

    Zitat von NaN

    Mit der ganzen Zensiererei ist nicht klar, welcher Server von wo angesprochen wird

    Oh... warum? Ich habe extra deswegen nicht nur simpel zensiert, sondern ausgetauscht, damit logische Zusammenhänge bestehen bleiben.

    Zitat von NaN

    Die Fehlermeldung kommt typischerweise, wenn der Server nicht für die Domain im RCPT-TO zuständig ist, also davon ausgeht, dass die Mail unter der Zieladresse weitergereicht werden muss (im Gegensatz zum Annehmen und an eine andere Adresse weiterleiten). Deswegen ist "Anmelden" oft die Lösung, weil diese Konstellation meist dann auftritt, wenn Clients Mail für externe Adressen bei ihrem Smarthost abliefern. Der macht das natürlich nur für angemeldete Einlieferer. Wenn das irgendwo in der Kette der MTAs auftritt ist die Zuständigkeit das Problem.

    Wie kann ich diese Zuständigkeit korrigieren? Bzw. kann ich das beim Webhosting überhaupt?

    Alternativ könnte ich unter example.com ein echtes Postfach einrichten und mit Sieve einfach alles weiterleiten, aber das ist ja auch nicht Sinn der Sache...

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Ist mail.example.com wirklich bei Korea Telecom? Ist das ein externer Server oder ein Mailserver von Netcup oder dein eigener?


    Anyway, der Server sagt: Ich bin nicht für example.com zuständig und weiterleiten ohne Anmeldung ("relaying") mache ich nicht*. Wenn du ein Postfach einrichtest statt einer Weiterleitung, ist der immer noch nicht zuständig. Vielleicht musst du nur etwas warten, bis die Konfigurationsänderung angekommen ist. Vielleicht ist es etwas anderes.


    *) Der Server denkt, er soll die Email an problem @ example.com durchreichen. Das ist nicht die konfigurierte Weiterleitung an eine andere Adresse.

    der 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; }

    »Hauptsache BogoMIPS!«

    Fleischfresser

    Einmal editiert, zuletzt von Olivetti ()

    Gefällt mir 2
    Zitat von NaN

    Korea Telecom

    What. Wo kommt das denn her? ^^

    Zitat von NaN

    Ist das ein externer Server oder ein Mailserver von Netcup oder dein eigener?

    Die Domain example.com ist als externe Domain zu 100% beim Webhosting eingebunden, sprich: Der Standard-Mailserver von Netcup für mein Webhosting.

    Zitat von NaN

    Vielleicht musst du nur etwas warten, bis die Konfigurationsänderung angekommen ist.

    Ich habe eigentlich nichts geändert, die DNS-Einstellungen sind schon mehrere Monate so.


    Zitat von NaN

    Der Server denkt, er soll die Email an problem@example.com durchreichen. Das ist nicht die konfigurierte Weiterleitung an eine andere Adresse.

    Nope, aber ich habe ja keine Möglichkeit (im Webhosting) das selbst anders zu konfigurieren?

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Zitat von Bud

    What. Wo kommt das denn her? ^^

    von deiner 222.111.222.111.

    es wäre grundsätzlich besser zu X'en, als mit vermeintlichen fantasie-IPs zu arbeiten.

    noch besser, die ersten echten triplets stehen zu lassen und hinten zu X'en.

    »Hauptsache BogoMIPS!«

    Fleischfresser

    Einmal editiert, zuletzt von Olivetti ()

    Gefällt mir 3
    Zitat von NaN

    Ist mail.example.com wirklich bei Korea Telecom? Ist das ein externer Server oder ein Mailserver von Netcup oder dein eigener?

    Zitat von Bud

    What. Wo kommt das denn her? ^^

    Die Nutzung öffentlicher IP-Adressen zur Anonymisierung ist so ungünstig wie die Nutzung von Nicht-Beispiel-Domänennamen (anstelle von bspw. example.org) :

    pasted-from-clipboard.png

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    2 Mal editiert, zuletzt von m_ueberall ()

    Danke 2 Ente gut, alles gut 1 Gefällt mir 1
    Zitat von Olivetti

    es wäre grundsätzlich besser zu X'en, als mit vermeintlichen fantasie-IPs zu arbeiten.

    noch besser, die ersten echten triplets stehen zu lassen und hinten zu X'en.

    Dann mache ich es das nächste mal so, danke dir :)

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    Ich habe das ganze mal mit einem Postfach test@example.com versucht, und webmail aktiviert.

    In das Postfach einloggen funktioniert, allerdings bekomme ich die gleiche Fehlermeldung, wenn ich eine E-Mail an test@example.com sende. E-Mails von test@example.com an bud@beispiel.de zu versenden geht allerdings ohne Probleme.

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    um bei deinen obigen IPs zu bleiben:

    wenn dein @    A 80.40.80.40 ist,

    sollte dein mail A 80.40.80.42 sein.


    regeln:

    db   = [@ IP last triplet] + 1

    mail = [@ IP last triplet] + 2

    »Hauptsache BogoMIPS!«

    Fleischfresser

    Einmal editiert, zuletzt von Olivetti ()

    Danke 1

    es geht um's verwendete beispielhafte prinzip, wie netcup ihre IPs vergibt.

    mit den obigen aus Buds screenshot ist's einfacher und ich fang' ned an wieder andere IPs zu verwenden.

    Das ist bei mir auch so. Die DNS Einstellungen habe ich ja 1:1 von netcup übernommen. Ich kann ja mit der externen Domain auch E-Mails versenden.

    Zitat von NaN

    Leute...

    Es wurde jetzt schon dreimal erwähnt, und wie auch schon weiter oben geschrieben, werde ich es das nächste Mal anders machen. Ich wusste es vorher einfach nicht besser.Danke.

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE

    ich würde jetzt noch die priority vom mm123.netcup.net MX testweise auf 5 (fünf) setzen und damit 'höher' als den example.com-MX.

    ansonsten ist das ein eh' fall für den support.


    ist der tester-account bud@netcup.de / bud@beispiel.de unabhängig vom problem-webhosting, aber innerhalb des netcup-netzwerks?


    Zitat von Bud

    E-Mails von test@example.com an bud@beispiel.de zu versenden geht allerdings ohne Probleme.

    da könntest du auch noch prüfen, welcher sendende mailserver im header eingetragen ist.

    »Hauptsache BogoMIPS!«

    Fleischfresser

    2 Mal editiert, zuletzt von Olivetti ()

    Danke 1
    Zitat von Olivetti

    ich würde jetzt noch die priority vom mm123.netcup.net MX testweise auf 5 (fünf) setzen und damit 'höher' als den example.com-MX.

    Ich hab das mal gemacht. Mal abwarten...

    Zitat von Olivetti

    ist der tester-account bud@netcup.de unabhängig vom problem-webhosting, aber innerhalb des netcup-netzwerks?

    Yes. bud@netcup.de läuft auf meinem Webhosting 8000 SE BF 22, und die Domain ist bei netcup gehosted. Die example.com ist als externe Domain auf meinem Webhosting 4000 SE KI23 eingebunden, das aber schon über 6 Monate. Ich habe über das Webhosting 4000 SE KI23 noch eine andere Weiterleitung (einer Domain bei netcup) auf die bud@netcup.de laufen, welche allerdings funktioniert (Gerade nochmal getested.)

    Sollte das alles nicht funktionieren könnte ich die externe Domain nochmal rausnehmen und erneut einbinden, allerdings ist das dann auch mit ein wenig Arbeit und vor allem Ausfall (viel genutzte Website) verbunden.

    [RS] 2000 G9 | Cyber Quack

    [VPS] 2000 ARM G11 | 1000 G9 | 200 G8 | Secret | A | mikro G11s | 4x nano G11s
    [WH] 8000 SE | 4000 SE | 2000 SE