Remote server returned not permitted to relay -> 554 5.7.1 Relay access denied?
Hallo zusammen,
seit einiger Zeit versuche ich, den oben genannten Fehler bei der E-Mail-Weiterleitung zu einer Zendesk-Support-Adresse zu beheben.
Leider war ich bislang erfolglos.
Folgende Situation:
- E-Mail-Absender: max.mustermann@outlook.com
- E-Mail-Empfänger: ticket@mustergmbh.de
- ticket@mustergmbh.de leitet alle eingehenden E-Mails zu support@muster.zendesk.com weiter
- DKIM & DMARC Einträge sind richtig gesetzt.
Nun wenn der Absender eine E-Mail zum Empfänger sendet, wird er mit einer Bounceback-Email belohnt die den o.g. Fehler zurückgibt.
Sobald jedoch der Absender direkt eine E-Mail zu support@muster.zendesk.com sendet, wird diese nicht rejected und alles verläuft fehlerfrei.
Als E-Mail-Server bei der mustergmbh wird Mailcow verwendet, bei der über "sogo" eine dauerhafte E-Mail-Weiterleitung eingerichtet ist. Eine Transport-Map hat bislang nicht geholfen.
Ich hoffe, jemand kann mir mit diesem Problem weiterhelfen.
Grüße
Philipp
1 Antwort
Wenn ich davon ausgehe, daß der MTA bei mustergmbh.de, den Relay-Fehelr ausgibt, dann sollten auch die Logs des dortigen MTA auskunft geben, warum er das Relay ablehnt resp. das als Relay betrachtet.
Mailcow nutzt AFAIK doch postfix? Dann sollte Postfix doch Logs anlegen und ggf. auch Debuglogs - ferner könntest Du schauen, ob die eigentliche MTA-Config korrekt ist. (d.h. ob die SOGO Weiterleitung überhaupt wirkt und wie.)
Ich hab mir das nochmal angesehen und bin die Logs nochmal durchgegangen, jedoch kann ich keine Einträge zu dem Relay Fehler, bzw. überhaupt Logs diesbezüglich finden. Genau genommen returned in8.pod29.euw1.zdsys.com den Fehler.
Das wäre dann also Zendesk, das Relaying ablehnt. Die Kernfrage ist also, warum deren MTA das als Relayversuch ansieht, bzw. worin sich die weitergeleitete Mail ggü. der direkten unterscheidet.
Ich hatte schon Kontakt mit Zendesk und der teilweise wochenlange Chat hat leider auch nichts geholfen. Zendesk behauptet auch, dass keine Logs vorliegen.
Daß keine Logs vorliegen kann gut sein. Das Ablehnen von einem Relay ist ja aus eigener Sicht kein Fehelrzustand, also muß auch nichts gelogged werden (tatsächlich sollte es auch nicht, zumindest in der EU).
Letztlich kannst du nur eines machen:
Eine Mail die ankommt (inklusive aller Header) mit dem vergleichen was Dein postfix raussendet und dem wie es gebounced wurde. Dann die identifizierbaren Unterschieden anschauen und hoffen, daß Du so den Fehler findest.
Ich habe mir die Postfix Logs und auch den Header einer erfolgreichen E-Mail angesehen und diese mit einer gescheiterten E-Mail von outlook.com vergleicht. Ich konnte jedoch nichts "auffälliges" finden, bis auf den Punkt, dass eben die Fehlermeldung "550 5.7.367 Remote server returned not permitted to relay -> 554 5.7.1" mit dabei ist.
554 wäre ein Transaction Failed, also keien wirklich neue Information.
Was anderes, wenn die Mails wietergeleitet werden, bleibt dann die ursprüngliche Absenderadresse erhalten? Ich frage das, weil bei DKIM die signierende Stelle ja zur 'MAIL FROM' auf Transportebene passen muß.
Du hast zwar geschrieben, es sei alles korrekt konfiguriert, aber vielleicht besteht ein nicht erwarteter Seiteneffekt?
Ja, die Absenderadresse bleibt unverändert. Der Ablauf ist folgendermaßen:
- max@mustermann.de -> ticket@mustergmbh.de -> Weiterleitung zu support@subdomain.zendesk.com über ticket@mustergmbh.de, jedoch wird die Absenderadresse nicht angerührt.
jedoch wird die Absenderadresse nicht angerührt.
Wichtig ist hier die Unterscheidung zwischen dem MAIL FROM des SMTP und From:/Sender: auf höherer Ebene. Wenn im MAIL FROM auf SMTP-Eben die ORiginaladresse erhalten bleibt, dann kann das nicht funktionieren, da Dein MTA kein legitimer Versender für die Domain der Originaladresse ist.
Ich hab nun tatsächlich das Problem selbst gefunden.
- Die CNAME-Einträge für das HC haben auch die Mailserver (MX) Einträge überschrieben.
- CNAME auf eine andere Subdomain gesetzt und schon funktioniert's wieder.
Danke für deine Hilfe!
Yikes, okay, darauf konnte man natürlich aus SMTP/MTA-Sicht auch schlecht kommen....
Gut, daß Du es nun klappt.
Jop, haste Recht.
Mailcow nutzt Postfix als MTA