Mailregeln/Agenten nach extern funktionieren nicht: Error 550 mailbox unavailable

  • Mailregeln/Agenten nach extern funktionieren nicht: Error 550 mailbox unavailable

    Hallo zusammen,
    wir haben ein kleines Problem und hoffen, das jemand dieses Problem auch schon mal hatte oder eine Idee zur Behebung:

    Domino 9.01 FP9 / Notesclients 8.52 und 9.01

    SMTP Mails an eine beliebige Adresse/Internt Domäne ("hans.mustermann@xyz.com") werden problemlos von Notesusern versendet.


    Mailregeln die "alle Dokumente" and diese Domäne weiterleiten (dieselbe Adresse "hans.mustermann@xyz.com")sollen können das nicht: Fehlermeldung auf der Dominokonsole (vom der annehmenden Gegenstelle) Error 550 "mailbox unavailable" und zwar immer dann wenn eine Mail von aussen (Internet) am Dominoserver ankommt.
    Interessant ist das die Mailregel funktioniert wenn eine interne Notesmail an einen Benutzer ankommt - dann kann die Mail gesendet werden.

    Ein Agent, der eingehende Mails an dieselbe Adress weiterleiten soll scheitert auch. (Agent ist eingestellt: run on bahalf "Username" (der kann Emails manuell versenden)

    Eine im Personendokument eingetragene Weiterleitung kann dies ebenfalls nicht - Fehlermeldung immer dieselbe: "550 mailbox unavailable"

    Die o.g. Probleme betreffen alle Benutzer.


    Bin um jeden Hinweis dankbar.

    Viele Grüße
    Thomas
  • Hallo taurec,
    das hat schon sehr geholfen - vielen Dank - das hat uns auf jeden Fall einen Schritt weitergebracht:

    ich habe den debug parameter SMTPClientDebug=3 angewendet und sehe tatsächlich einen Unterschied zwischen manuell versendeten Emails und (per Mailregel/Weiterleitung/Agent) erzeugten EMails: Bei letzterem ist Feld "MAIL FROM" beim Aufbau der SMtP Verbindung leer.
    ---------------------------------------------------------------------------------------------------------------------------------------------------------

    02.12.2017 13:45:51 [0C70:000E-151C] SMTPClient: CommandMAIL: MAIL FROM:<> BODY=8BITMIME
    02.12.2017 13:45:51 [0C70:000E-151C] SMTPClient: ReceiveResponse: 550 Requested action not taken: mailbox unavailable
    ---------------------------------------------------------------------------------------------------------------------------------------------------------
    Ich mache mich jetzt auf die Suche warum das so ist.

    Viele Grüße
    Thomas
  • Neu

    Ich frage mich, wie die restlichen Header des Verbindungsaufbaus aussehen.
    Wenn nämlich der Client ein EHLO an den remote Mailserver sendet mit dem FQHN des Servers, dann ist es gut möglich, dass das nicht tut: der remote Mailserver weist den Verbindungsaufbau hoffentlich ab, weil er so konfiguriert ist, dass er keine Verbindungen annimmt von Gegenstellen, die sich mit fremden Namen melden.
    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl
  • Neu

    Hmm - ein Test mit einem anderen (funktionerenden) Dominoserver (mit aktivierten SMTPClientDebug=3 Parameter) hat gezeigt:
    Nur wenn ein Mail manuell erstellt wird wird auch ein <Mail From> mit einem Eintrag (=Internetadresse des Notesbenutzers) erstellt.
    Wird das Mail per Mailregel/Forwarding/Agent erstellt dann ist <Mail From> beim SMTP Verbindungsaufbau leer. Ich habe mich auch mit dem passenden RFC auseinandergesetzt und bin der Meinung das ist ein erlaubter Zustand. Wir haben darauf die Regeln annehmenden Mailrelais ändern lassen - so das ein leeres <Mail From> akzeptiert wird - und jetzt gibt es keine Probleme mehr. Dank an alle.
  • Neu

    Zunächst einmal: von welchem RFC sprechen wir? 821 oder 5321? SMTP wird in verschiedenen RFCs besprochen und erweitert. Davon abhängig ist, was erlaubt ist, was empfohlen ist und was gar nicht geht.
    Ein leeres <Mail From:> ist an und für sich erstmal eine suboptimale Idee. Kann man machen, funktioniert in der Regel auch, kann und wird im Problemfalle aber auch auf die Füße fallen.

    Einer der Problemfälle ist, wenn das empfangende System sich (aus guten Gründen) weigert, solche Mails anzunehmen, da es Spam vermutet, oder auf exakt diese Information angewiesen ist, um sicherzustellen, dass die Mail auch wirklich "authentisch" ist und nicht von irgendeinem Skriptkiddie mit seinem Virenbaukasten zusammengefrickelt wurde. Das ist aus heutiger Sicht natürlich Augenwischerei, heutzutags hat man dafür zwar u.a. DKIM, SPF et al. Damals(TM) war es aber Stand der Dinge, sicherlich auch darin begründet, dass es "damals" weit weniger Skriptkiddies gab, die nichts weiter als Blödfug im Kopf haben X( geschweige denn Zugriff auf einen Rechner mit Zugang nach draußen (RFC 821 ist von Anfang der 80er Jahre, da war selbst an einen A500 noch nicht zu denken).

    Ich persönlich würde meine Systeme grundsätzlich so konfigurieren, dass es derart verhunzte Mails abweist. Wenn ein wie auch immer gearteter Mechanismus (Server oder PEBCAK) nicht in der Lage ist, korrekt formatierte Mails zu generieren, dann stimmt da mit einiger Wahrscheinlichkeit etwas nicht; da wäre ich zumindest mal skeptisch.

    Wenn eure automatisch generierten Mails (und was anderes ist eine per Agent/Regel weitergeleitete Mail im Grunde nicht) also ein Problem mit den Headern haben, würde ich lieber da ansetzen, als an den Relais rumzukonfigurieren. Diese Mails sollten in ihren Headern den Namen der ID haben, unter der der Agent läuft, oder im Falle von server mail rules sollte da der Servername drinstehen. Letzteres aber funktioniert nur zuverlässig, wenn das Config-Dokument korrekt befüllt ist.
    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl