Sendeadresse für Exchange OOF einstellen

[tobinator_1991 2]

Hallo zusammen,

 

gibt es eine Möglichkeit die Sendeadresse für OOF Nachrichten im Exchange einzustellen?

Wir haben nämlich das Problem, dass OOF Nachrichten vom Provider SMTP Server abgelehnt werden, weil der Exchange diese mit einer internen Adresse (also kryptischeadresse@exchange.interneDomain.de) versendet.

Der Provider Server lehnt diese dann mit der Meldung 550 Requested action not taken: mailbox unavailable Sender address is not allowed ab.
 

 

[NorbertFe 2.281]

vor 3 Minuten schrieb tobinator_1991:

gibt es eine Möglichkeit die Sendeadresse für OOF Nachrichten im Exchange einzustellen?

 

Nein und das ist auch gut so.

 

vor 3 Minuten schrieb tobinator_1991:

Wir haben nämlich das Problem, dass OOF Nachrichten vom Provider SMTP Server abgelehnt werden, weil der Exchange diese mit einer internen Adresse (also kryptischeadresse@exchange.interneDomain.de) versendet.

 

Ein OOF wird per Empty Sender gesendet (vom Exchange). Da ist also keine kryptische interne Domain enthalten. ;) Sicher, dass es um OOF und nicht um NDR oder DSN geht? Das wäre dann die external postmasteraddress in der Transportconfig.

[tobinator_1991 2]

Hallo @NorbertFe,

danke für die schnelle Antwort.

Ja es geht hier in dem Fall um OOF Nachrichten die der Exchange versucht rauszusenden, die dann aber vom Provider abgelehnt werden.

Aber er sende diese halt mit z.B. 1312423534fasdfsdg@exchange.interneDomäne.de raus.

[NorbertFe 2.281]

vor 8 Minuten schrieb tobinator_1991:

Aber er sende diese halt mit z.B. 1312423534fasdfsdg@exchange.interneDomäne.de raus.

Glaube ich aber nicht. Denn der Exchange schickt das eben mit empty sender. Also entweder setzt da irgendwer was rein oder es ist kein OOF.

[tobinator_1991 2]

Zitat

Glaube ich aber nicht

was kann ich tun damit mir glaubst?

hier mal ein Screenshot aus dem Messagetracking Tool von Frankys:

[NorbertFe 2.281]

mag alles sein, aber OOF werden von Exchange OHNE Sender (empty sender/empty returnpath) gesendet. Also ist das entweder kein OOF oder du hast nen Transportagent, der da einen einsetzt.

 

Dein Exchange sendet selbst direkt an den IONOS Smarthost?

[testperson 1.858]

Hi,

 

ich vermute, du nutzt 1und1 / IONOS als Smarthost? 1und1 / IONOS haben Anfang des Jahres (?) darüber informiert, dass leere Absender (OOF) oder abweichende E-Mail-Adressen nicht mehr angenommen werden: 

• Kein E-Mail-Versand bei abweichender Absenderadresse (1und1.de)
• Auch 1&1-Postfächer von Änderungen der Einstellungen zum 15. Januar 2024 betroffen | Borns IT- und Windows-Blog (borncity.com)

Das sinnvollste wäre vermutlich, sich um einen direkt Versand zu kümmern und nicht 1und1 als Smarthost zu nutzen bzw. wenn es direkt nicht geht, einen anderen Anbieter als Smarthost nehmen.

 

Gruß

Jan

[NorbertFe 2.281]

vor 15 Minuten schrieb tobinator_1991:

hier mal ein Screenshot aus dem Messagetracking Tool von Frankys:

 

Nur zur Erläuterung, damit du _mir_ glaubst:

Das zeigt dir den Sender bzw. FROM an, wenn kein Sender vorhanden ist Wenn du dir die detaillierten ERgebnisse anschaust und mal den ReturnPath dieser Mail anschaust, siehst du, dass dort ein <> drin steht wenn es ein OOF ist. Und dann tritt vermutlich Jans Hinweis in Kraft. Wer heutzutage IONOS als SMTP RElay nutzt, ist aber auch selbst Schuld. :)
https://learn.microsoft.com/en-us/exchange/message-tracking-exchange-2013-help

 

 

Zitat

sender-address                The email address specified in the Sender: header field, or the From: header field if Sender: is not present.

return-path                      The return email address specified by MAIL FROM: in the message envelope. Although this field is never empty, it can have the null sender address value represented as <>.

 

[testperson 1.858]

Gerade eben schrieb NorbertFe:

Wer heutzutage IONOS "einen der Domainprovider" als SMTP RElay nutzt, ist aber auch selbst Schuld. :)

;)

 

(Allerdings machen es die ISPs einem auch nicht unbedingt leichter, wenn die /20-er Netze auf Blacklists setzen lassen und man beim Blacklist Anbieter dann das Delisting für das komplette Netz durchführen soll.)

[tobinator_1991 2]

@NorbertFe

der Return Path sieht bei mir im Message Tracking genau so aus wie bei dir.

 

@testperson

danke für den Hinweis bzgl. der Umstellung bei 1und1.

[NorbertFe 2.281]

vor 11 Minuten schrieb tobinator_1991:

der Return Path sieht bei mir im Message Tracking genau so aus wie bei dir.

 

Gut, dann hast du vermutlich eins der Probleme gefunden. Bleibt die Frage, warum das "From" Feld so ein kryptisches Konstrukt bei dir beinhaltet. Findest du denn raus, welche Mailbox diesen OOF sendet, oder ob das alle OOF betrifft?

[tobinator_1991 2]

Zitat

Gut, dann hast du vermutlich eins der Probleme gefunden. Bleibt die Frage, warum das "From" Feld so ein kryptisches Konstrukt bei dir beinhaltet. Findest du denn raus, welche Mailbox diesen OOF sendet, oder ob das alle OOF betrifft?

 

Wenn ich die Message Trackings richtig interpretiere werden die Mails mit der Postmasterdresse versendet.

Diese Adresse ist auch eine Reale Adresse die beim Provider auch vorhanden ist.

Ich habe nun 3 Postfächer getestet, jedes davon war betroffen.

[NorbertFe 2.281]

vor 3 Minuten schrieb tobinator_1991:

Wenn ich die Message Trackings richtig interpretiere werden die Mails mit der Postmasterdresse versendet.

 

Was dann aber auch "merkwürdig" wäre, denn im FROM steht ja der Absender dessen Mailbox die OOF versendet. Was gibt dir denn ein "get-transportagent" am Exchange als Ergebnis?

[tobinator_1991 2]

Zitat

Was gibt dir denn ein "get-transportagent" am Exchange als Ergebnis?

[PS] C:\Windows\system32>get-transportagent

Identity                                           Enabled         Priority
--------                                           -------         --------
Transport Rule Agent                               True            1
DLP Policy Agent                                   True            2
Retention Policy Agent                             True            3
Supervisory Review Agent                           True            4
Malware Agent                                      False           5
Text Messaging Routing Agent                       True            6
Text Messaging Delivery Agent                      True            7
System Probe Drop Smtp Agent                       True            8
System Probe Drop Routing Agent                    True            9

 

[NorbertFe 2.281]

OK, also zumindest kein 3rd Party Transport Agent, der da irgendwie was "veranstaltet".

Welche Domain ist bei dir als Default konfiguriert? (get-accepteddomain) Evtl. die interne?