Einfluss auf Smtp-Mail-Header nehmen?

[schroederk]

Hallo,

wir haben einen lokalen Server, der auch nur lokal erreichbar ist, aber auch Mails über unseren Domino-Server nach aussen schicken soll.
Auf dem Server ist eingestellt, dass dieser Server das auch darf und die Mails werden auch verschickt.

Allerdings werden diese Mails bei einigen Empfängern (nicht bei allen) zurückgewiesen (Connection refused).
Das liegt offenbar daran, dass im Header der Mail steht:

Received: from portal.interne_domain.de ([10.10.10.21])
          by mail.dominoserver.de (Lotus Domino Release 7.0.2FP2)

Der Empfänger prüft offenbar, ob es die Domain portal.xyz.de gibt und nicht ob die Domain des Dominoservers existiert.

Gibt es Domino-seitig eine Möglichkeit, dass man aussen nicht mehr erkennen kann, dass die Mail von woanders initiert wurde?
Letzenendlich soll man nur wissen, dass die von einem korrekten sauberen Mailserver verschickt wurde. Was davor war, ist doch uninteressant, oder?

[m3]

Bei der "Zurückweisung" sollte eine Fehlermeldung/Nummer dabei stehen - die wär mal interessant.

Ich tippe, dass mail.dominoserver.de auf einer Blacklist steht, keinen Reverse Lookup hat, etc.

Die Hops davor sollte egal sein.

[schroederk]

Nein, dort steht keine Fehlermeldung. Nur schlicht:
Connect to xyz[ipadresse]: Connection refused

der Domino-Server ist auch ganz sicher nicht blacklisted, wir verschicken ca. 6.000 Mails pro Tag.
Ich denke, wenn da nur 50% von dem Server zurückkommt, der den Notes-Server als Relais benutzt (also maximal 5 pro Tag), dann kann ich guten Gewissens sagen, dass er nicht auf der Blacklist steht.

Ich gehe davon aus, dass der Empfänger-Server die Absender-Domain überprüft und da unsere lokale Domain im WWW nicht bekannt ist, wird die Mail abgelehnt.

[blizzard]

du meinst der empfänger geht die received header durch und prüft dort jede domain auf existenz???

[m3]

Das kanns nicht sein. Da wird nur der letzte Hop überprüft, nicht die Vorgeschichte.
Da muss es an was anderem liegen, aber ohne Feedback/Logs vom Empfängersystem wirds mühsam.

Ich geh davon aus, dass die Meldung auf der Konsole kommt. Das erweckt den Anschein, als ob beim Empfänger entweder auf Firewall- oder MTA-Ebene geblockt wird.

Schröder, mach mal am Domino-Server eine OS-Konsole auf und probier eine manuelle SMTP-Session zum Ziel-MX, da sieht man dann mehr.

[schroederk]

Die Meldung kommt in Form eines Zustellungsfehlerberichts. (siehe Screenshot-Ausschnitt)

Der Zustellungsfehler wird auch nur dann erzeugt, wenn die Mail vom internen Server verschickt wird.
Verschicke ich die Mail über meinen Notes-Client, dann wird die Mail vom Empfänger anstandslos entgegengenommen.
Insofern ist es auch nicht verwunderlich, dass ich über eine OS-Konsole keine Probleme habe, um auf die Ziel-MX zugreifen zu können.

[m3]

Ah, OK. Ich bleib trotzdem dabei, dass das ein Spam-Filter-Problem ist. (ignorier mich, wenn ich nerve ).

Kannst Du Dir so eine Mail vom internen Server an beispielsweise GMX oder so schicken und die anonymisierten Header hier posten? Ev. hats da noch was anderes.

[schroederk]

Das mit dem GMX ist nicht so einfach, da ja nicht alle Mails, die vom internen Server verschickt werden, beim Empfänger abgelehnt werden. Auch wenn hier und da Freenet und T-Online dabei sind.

Ich hab aber mal den anonymisierten Quelltext eines Zustellungsfehlers angehängt. Vielleicht hilft das schon weiter? Vom Prinzip her sehen alle Quelltexte gleich aus, egal ob Schlund, T-Onlinem Freenet oder was auch immer.

[m3]

Ahhh. besser.

Reporting-MTA: dns; portal.intern.de
Arrival-Date: Mon,  5 Nov 2007 16:23:04 +0100 (CET)

Final-Recipient: rfc822; info@empfaenger.de
Action: failed
Status: 4.0.0
Diagnostic-Code: X-Postfix; connect to mailin.rzone.de[81.169.145.102]:
    Connection refused

4.0.0 - das bedeutet:

Code

4.X.X   Persistent Transient Failure

       A persistent transient failure is one in which the message as
       sent is valid, but some temporary event prevents the successful
       sending of the message.  Sending in the future may be successful.

IMHO hats da auf der Empfängerseite was mit dem einen User-Account. Die Fehlermeldung selbst spricht ja auch eine deutliche Sprache:

Code

This is the Postfix program at host portal2.XX.de.

I'm sorry to have to inform you that the message returned
below could not be delivered to one or more destinations.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the message returned below.

			The Postfix program

<info@beXXXXXXg.de>: connect to mailin.rzone.de[81.169.145.102]: Connection
    refused

[schroederk]

Ne dumme Frage... Wie hast Du die Informationen des letzten Code-Blocks von Dir bekommen?
Im angehängten Text stand ja direkt keine Fehlermeldung drin.

Dann kann ich mal die anderen Zustellungsfehler druchgehen und prüfen, ob das jetzt nicht ein Zufall war und ob bei allen der selbe Fehler auftritt.

[m3]

Das ist der Base64 encodete Teil.

[schroederk]

Ok,

was ich aus der Fehlermeldung verstehe ist, dass der Empfänger ein Problem mit dem eigenen User-Account hat, dass die Mail ansich in Ordung ist und später durchaus erfolgreich gesendet werden kann.

Was ich nicht verstehe ist, dass es jeden Tag 5 - 10 Mails sind, die als Zustellungsfehler zurückkommen, die aber alle sofort erfolgreich direkt über den Server verschickt werden können.

Da zweifelt man doch, dass es sich um ein temporäres Problem handelt, dass beim Empfänger liegt.

[schroederk]

4.0.0 - das bedeutet:

Code

4.X.X   Persistent Transient Failure

       A persistent transient failure is one in which the message as
       sent is valid, but some temporary event prevents the successful
       sending of the message.  Sending in the future may be successful.

Bist Du Dir sicher, dass der Code 4.0.0 dieser Fehlermeldung entspricht? Wenn ich im Internet nach dem Code suche, dann erhalte ich zahlreiche Ergebnisse, bei der 4.0.0 immer was anderes bedeutet.
Oftmals schlicht "connection refused" aber auch "Host not found" usw.

Ich hab auch einen (zugegebenermaßen uralten) Beitrag gefunden, der sich sehr interessant anhörte und das Problem beschreibt, dass offenbar nicht immer nach dem MX-Record geschaut wird sondern der A-Record???
Hier ist derBeitrag

[m3]

http://www.ietf.org/rfc/rfc1893.txt

Zum A-Record: Dazu hast Du auch einen Eintrag in Deinem Protokoll weiter oben. Ev. liegts daran.