Hinweis: Dies ist mein erneuter Beitrag von Stackoverflow.
Ich habe aus Sicherheitsgründen mit einer Testumgebung herumgespielt, in der ein DMZ RHEL5 Sendmail-Server als Relay für einen Exchange 2007-Server verwendet wird. Exchange funktioniert in der Umgebung, ich habe Vista- und XP-VMs, die Outlook in der Domäne verwenden, um sich gegenseitig E-Mails zu senden. Ich habe versucht, eine externe Internet-VM zu simulieren, die eine E-Mail an das DMZ-Sendmail-Relay sendet, das sie an den Exchange-Server weiterleitet.
Bevor alle denken, dass dies ein zu großes Problem/eine zu große Frage ist: Ich habe die Anleitungen zu Sendmail/Exchange befolgt und möchte nur wissen, wie ich feststellen kann, warum eine weitergeleitete Nachricht/E-Mail in Exchange als „nicht zugestellt“ gilt.
Grundsätzlich sende ich eine SMTP-Nachricht an den Sendmail-Server, der sie an meinen Exchange weiterleitet. /var/log/maillog zeigt die an Exchange weitergeleitete E-Mail.
Nov 17 13:41:22 externalmailserver sendmail[9017]: pAHIfMuW009017: from=<[email protected]>, size=1233, class=0, nrcpts=1, msgid=<[email protected]>, proto=ESMTP, daemon=MTA, relay=[10.50.50.1]
Nov 17 13:42:17 externalmailserver sendmail[9050]: pAHIfMuW009017: to=<[email protected]>, delay=00:00:55, xdelay=00:00:36, mailer=relay, pri=121233, relay=mailserver.xyz.local. [192.168.1.20], dsn=2.0.0, stat=Sent (<[email protected]> Queued mail for delivery)
Das ist gut, aber der Empfänger erhält nie die E-Mail von Exchange. Also habe ich angefangen, in Exchange herumzustöbern. Im Fehlerbehebungsassistenten „Nachrichtenverfolgung“ habe ich die verarbeiteten Nachrichten abgefragt und Folgendes gefunden: (Ich musste die Zellen kopieren und einfügen ... entschuldigen Sie das Format)
2011/11/17 RECEIVE SMTP <[email protected]> "Undelivered Mail Returned to Sender" [email protected] [email protected] 192.168.100.10 MAILSERVER\DMZ Relay [email protected]
Ich möchte nur wissen, ob jemand Vorschläge hat, warum der von mir eingerichtete DMZ-Relay-Connector keine Weiterleitung durchführt und die weitergeleitete E-Mail stattdessen als „Nicht zugestellt“ an den Absender zurücksendet?
Mein Exchange Relay-Empfangsconnector ist ziemlich einfach. Der FQDN des Exchange-Servers ist als HELO-Antwort festgelegt, alle verfügbaren IP-Adressen können weitergeleitete E-Mails empfangen und die IP-Adresse meines Sendmail-Servers ist speziell als Remote-Server festgelegt.
AKTUALISIEREN:
Eigentlich glaube ich zu wissen, wo das Problem liegt. Das Tool, das ich zum Senden der E-Mail verwenden muss, sendet eine andere Nachricht, als wenn ich es manuell über Telnet versuche.
Wenn ich eine E-Mail per Telnet über SMTP versende, wird die msgid=123123...123.PA12312356@[email geschützt].
Wenn die E-Mail über das Tool gesendet wird, handelt es sich um eine ESMTP-Nachricht, bei der die[email geschützt]
Exchange versucht offenbar, eine Relay-Prüfung durchzuführen und kann keinen Server mit dem Namen „xyz.local“ finden. Klingt das richtig? Alle meine per Telnet gesendeten E-Mails kommen einwandfrei an. Es sieht nicht so aus, als hätte ich eine Wahl, wie das Tool die E-Mails sendet. Woher soll es die xyz.local-Domäne bekommen? Bei Verwendung von Telnet präsentiert sich der Sendmail-Server als 220[email geschützt], was funktioniert.
UPDATE 2:
Ok! Ein bisschen Wireshark hat es geschafft. Es sieht so aus, als ob das Tool, das die SMTP-Nachricht sendet, die Nachrichten-ID selbst einstellt, vermutlich so, wie es ein Mailserver tun würde, bevor er sie an den Ziel-Mailserver sendet. Die eingestellte Nachrichten-ID gilt nur für die Domäne (xyz.com), und wenn die E-Mail über Sendmail an Exchange weitergeleitet wird, scheint sie einfach im STOREDRIVER zu sitzen. Ich habe keine Ahnung, was der STOREDRIVER ist, aber ich weiß, dass E-Mails zugestellt werden, wenn die Nachrichten-ID den FQDN des Relays enthält (nicht nur die Domäne), und wenn sie nur die Domäne enthält, werden sie nicht zugestellt.
Message-ID: <[email protected]>
Message-ID: <[email protected]>
Exchange muss eine Suchfilterung anwenden oder eine Konfiguration fehlt. Hat jemand eine Idee?
ANTWORTETE: Auch hier kann ich meine Frage nicht selbst beantworten, aber die erste Person, die antwortet: „Vielleicht werden die E-Mails zugestellt und Outlook verschiebt sie einfach in den Junk-Ordner“, bekommt meine Stimme.
Das stimmt. Die Nachrichten wurden einwandfrei zugestellt, aber Outlook hat sie als Phishing-Versuche gefiltert. Dies ist eine umfassende Testumgebung und ich bin nie auf die Idee gekommen, das zu überprüfen.
Antwort1
Möglicherweise werden die E-Mails zugestellt und Outlook verschiebt sie einfach in den Junk-Ordner.