Icon Makefg

In der Nachrichtenverfolgung tauchen immer wieder Nachrichten auf, bei denen der Betreff mit “Message delivered via relay” beginnt.

Der Grund hierfür ist, dass der absendende SMTP-Server im SMTP-Envelope eine “Delivery Notification” anfordert. Diese Notifications werden vom empfangenden SMTP-Server aber nicht unterstützt. Über diesen Zustand wird dann der Absender informiert.

Angefordert werden diese Notifications über den NOTIFY-Parameter vom RCPT TO-Kommando, also beispielsweise so:
RCPT TO:<alice@example.com> NOTIFY=Delay,Failure

Je nach Anforderung muss dies entsprechend auf der absendenden Seite oder der empfangenden Seite geändert werden.

Dieses Verhalten ist nicht durch NoSpamProxy veränderbar!

Icon Makefg

Oftmals werden E-Mail vom NoSpamProxy mit der Fehlermeldung “Unable to relay” abgewiesen. Davon bekommt der Administrator aber meist nichts mit, da die abgewiesene E-Mail aufgrund einer internen Systemregel abgewiesen wurde und aufgrund dessen standardmäßig keine Protokollierung in der Nachrichtenverfolgung erfolgt.

Was bedeutet diese Fehlermeldung?

Wenn eine E-Mail mit dieser Fehlermeldung abgewiesen wird, können folgende Gründe vorliegen:

  • Bei einer eingehenden E-Mail steht im Envelope “MAIL FROM” eine E-Mail-Adresse aus der eigenen Mail Domäne. Der NoSpamProxy weist diese von außen kommende E-Mail ab, da er grundsätzlich keine Mails von außen mit der eignen E-Mail Domäne erwartet, es sei denn, der einliefernde Server ist auf der Liste der „E-Mail-Server des Unternehmens“ aufgelistet. Dies ist ein erwartetes Verhalten
  • Bei einer ausgehenden E-Mail steht im Envelope “MAIL FROM” keine E-Mail-Adresse aus der eigenen Mail Domäne. Der NoSpamProxy weist diese von innen kommende E-Mail ab, da er grundsätzlich keine Mails von innen mit fremden E-Mail Domänen erwartet. Dies ist ein erwartetes Verhalten, kann bei Bedarf aber angepasst werden.
  • Bei einer ausgehenden E-Mail steht im Envelope “MAIL FROM” eine E-Mail-Adresse aus der eigenen Mail Domäne. Der NoSpamProxy weist diese von innen kommende E-Mail ab, da er grundsätzlich nur Mails von innen mit der eigenen E-Mail Domänen nur zulässt, wenn diese von registrierten E-Mail Servern kommen. Dies ist ein erwartetes Verhalten
  • NoSpamProxy findet keine passende Regel für die vorliegende E-Mail.
  • Bei einer eingehenden Mail ist die Empfänger Mail Domäne nicht als eigene Mail Domäne im NoSpamProxy definiert.

Was können die Gründe dafür sein?

  1. Wenn es vorgesehen ist, dass der absendende Server E-Mails mit der eigenen Mail Domäne Versenden darf, egal ob von innen oder außen, dann muss dieser Server als “E-Mail Server des Unternehmens” gelistet werden. Dies kann man in der NoSpamProxy Konsole unter “Konfiguration > E-Mail Routing > E-Mail Server des Unternehmens” einstellen.
  2. Wenn Punkt 1 korrekt konfiguriert ist, kann es sein, dass das Regelwerk im NoSpamProxy noch nicht korrekt konfiguriert ist. Das Regelwerk kann in der NoSpamProxy Konsole unter “Konfiguration > Regeln” entsprechend kontrolliert und korrigiert werden. Achten Sie hierbei in der betreffenden Regel insbesondere auf den Reiter “Nachrichtenfluss” Auf diesem Reiter bestimmen Sie welche E-Mails von dieser Regel verarbeitet werden sollen.

Bitte beachten Sie
Beim Anlegen von neuen Regeln, achten Sie bitte immer darauf, dass diese für die entsprechenden Fälle korrekt abgesichert sind, sodass ein “Open Relay” verhindert wird!

 

Wie kann man E-Mails sichtbar machen, die mit “Unable to relay” abgewiesen werden?

Da E-Mails mit diesem Fehler standardmäßig nicht in der Nachrichtenverfolgung angezeigt werden, ist es möglich ein erweitertes Monitoring zu aktivieren. Dies können Sie in der NoSpamProxy Konsole unter “Konfiguration > Erweiterte Einstellungen > Monitoring > Bearbeiten” durchführen. Aktivieren Sie dort den Haken bei “Ungültige Absender und Empfänger nachverfolgen”. Danach versuchen Sie eine erneute Zustellung der E-Mail und können dann diese auch in der Nachrichtenverfolgung finden und das Problem weiter analysieren.

Bitte beachten Sie, dass diese Einstellung nur zu Analyse Zwecken aktiviert sein sollte, da sonst die Gefahr besteht, bei zu häufigem Auftreten dieses Problems, dass die Datenbank der Intranet Rolle (NoSpamProxyAddressSynchronization) zu groß wird und beim Einsatz einer SQL Express Version die Grenze von aktuell 10GB schnell erreicht wird!

Icon Makefg

In seltenen Fällen kommt es vor, dass das NoSpamProxy Setup aufgrund eines Fehlers bei der Installation von PowerShell RemoteWIN fehlschlägt​.

Um das Problem zu lösen, muss die Registry wie folgt modifiziert werden:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

Anschließend sollte die Installation von NoSpamProxy erfolgreich sein.​​

Icon Makefg

Sollte Outlook so konfiguriert sein, dass Mails nach dem Klick auf Senden im Postausgang verbleiben, bis der endgültige Versand angestoßen wird, kann es unter Umständen zu einem Problem kommen, wenn man sich die Mail vorher noch einmal anschaut. In diesem Fall wird die Mail wieder in den Entwurfsmodus zurückversetzt und muss durch erneutes Klicken auf Senden in den Versandmodus zurückversetzt werden, bevor sie wirklich versendet werden kann.

Dies ist kein spezifisches Verhalten mit dem Outlook Addin, sondern ein ganz allgemeines Verhalten von Outlook und kann auch nicht anders gelöst werden.

Icon Makefg

Fehler:

Nach dem Einspielen von Windows-Updates auf den Windows-Servern melden sich plötzlich immer mehr Benutzer, dass auf einmal Teile des Outlook Addins für NoSpamProxy nicht mehr angezeigt werden. Das Addin scheint aber ordnungsgemäß installiert zu sein und von Outlook geladen zu werden.

Lösung:

Microsoft hat mit den letzten Windows-Updates die Sicherheitseinstellungen für den Zugriff auf Gruppenrichtlinien verschärft. Daher können Benutzer diese nicht mehr abrufen. Die Lösung beschreibt Microsoft in ihrer Knowledge-Base: https://support.microsoft.com/en-us/kb/3163622

Icon Makefg

Fehler:

Obwohl unter “Kryptografische Schlüsselanbieter” die Konfiguration für SwissSign korrekt erfolgt ist und alle Gateway Rollen via TCP 443 (https) auf ra.swisssign.net Zugriff haben, erscheint beim Abrufen von Zertifikaten folgende Fehlermeldung im Eventlog:
ID: 026f7e58-9be2-4434-b562-11016c181bfd
Created: 12.06.2015 12:15:56
Mail address: Test.Benutzer@nospamproxy.de
Request type: CertificateRequest
Request status: Failed
Failure status: TrustCenterError
Error text: Unexpected error: Message:
An error occurred while sending the request.
Error type:
System.Net.Http.HttpRequestException

Error code: 2148734208
Program location:
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
at Netatwork.NoSpamProxy.Cryptography.SwissSignCertificateProvider.<EnrollAsync>d__e.MoveNext()

The request was aborted: Could not create SSL/TLS secure channel.

Message:
The request was aborted: Could not create SSL/TLS secure channel.
Error type:
System.Net.WebException

Error code: 2148734217
Program location:
at System.Net.HttpWebRequest.EndGetRequestStream(IAsyncResult asyncResult, TransportContext& context)
at System.Net.Http.HttpClientHandler.GetRequestStreamCallback(IAsyncResult ar)

Subject name:E=test.benutzer@nospamproxy.de, CN=Secure Mail: Gateway Certificate

Ursache:

Sowohl im Zertifikatsspeicher des Computerkontos einer oder aller Gateway Rollen sowie im Zertifikatsspeicher des NoSpamProxy Encryption Gateways befindet sich das Pseudo-AutoRAO-Dienstzertifikat zur Authentifizierung beim Dienstanbieter SwissSign.

Lösung:

Unter “Kryptografische Schlüsselanbieter” öffnen Sie die Konfiguration für den Anbieter SwissSign. Hier finden Sie das hinterlegte Pseudo-AutoRAO-Zertifikat. Mit einem Klick auf dieses werden die Zertifikatsdetails angezeigt, die beim Identifizieren des korrekten Zertifikats im Zertifikatsspeicher des Computerkontos hilfreich sind:

SwissSign Provider Configuration

Öffnen Sie nun als Administrator “mmc.exe” auf der Gateway Rolle.

Zertifikatsverwaltung öffnen

Klicken Sie auf “Datei” und “Snap-In hinzufügen/entfernen” (1). Wählen Sie anschließend “Zertifikate” (2) und klicken Sie auf “Hinzufügen” (3). Es erscheint ein neues Fenster, in dem Sie das “Computerkonto” (4) auswählen und mit “Weiter” (5) bestätigen. Wählen Sie den “Lokalen Computer” (6) und klicken Sie auf “Fertigstellen” (7). Sie kehren Zurück zur Snap-In-Auswahl und bestätigen diese mit “OK” (8).

SwissSign Certificate at MS Store

Navigieren Sie nun zu den “Eigene Zertifikate” (1) und finden Sie das Pseudo-AutoRAO-Dienstzertifikat. Wählen Sie dieses aus (2) und löschen Sie es (3). Anschließend starten Sie bitte das betroffene Windows System der Gateway Rolle neu, damit die Änderungen wirksam werden.

Wiederholen Sie diese Schritte ggf. für alle weiteren Gateway Rollen.

Icon Makefg

Verhalten:

In der Ereignisanzeige sehen Sie immer wieder diese Meldung:
---------------
Gateway Role 1088:
Could not secure an inbound connection with the host 192.168.0.100:53627.
Die angegebenen Daten konnten nicht entschlüsselt werden
Error type:
System.ComponentModel.Win32Exception
Error number:2147500037
Program location:
---------------

In der Folge finden Sie auch zum gleichen Zeitpunkt einen SChannel-Fehler im Windows-Anwendungs-Eventlog wie diesen:
---------------
SChannel 36887:
Es wurde eine schwerwiegende Warnung vom Remoteendpunkt empfangen. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 51.
---------------

Beachten Sie bitte, dass die ID und der Code sich geringfügig unterscheiden können.

Erklärung:

Windows 2008 R2 und neuer unterstützt von Haus aus bzw. nach einem Windows-Update ältere, schwache Ciphersuites, die als gebrochen gelten, nicht mehr. Daher kommt keine TLS-Verbindung zustande, wenn der einliefernde Server nur diese beherrscht. Als Folge dessen werden die oben genannten Warnungen bzw. Fehler geloggt. Der einliefernde Server muss dann einen Fallback auf Klartext durchführen. Hierzu ist es notwendig, dass der einliefernde Server eine neue Verbindung aufbaut, da die alte Verbindung, bei der keine TLS-Verbindung hergestellt werden konnte, geschlossen werden muss.

Die Unterstützung lediglich veralteter Ciphersuits ist definitiv ein Problem des absendenden Servers, wenn dieser kein Fallback auf Klartext macht, sobald keine TLS-Verbindung erfolgreich zustande kommt. Die Warnungen im Log weisen entsprechend nur darauf hin, dass die Verbindungen nicht zustande kamen, weil der TLS-Handshake nicht funktionierte; sprich sich auf keine Ciphersuite geeinigt werden konnte, da keine gemeinsame gefunden wurde. Manche Server verwenden dann einfach stumpf eine Ciphersuite ihrer Wahl, was dann zu weiteren Meldungen führen kann.

Sollte aufgrund dieses Verhaltens Ihre Kommunikation gestört sein, wenden Sie sich bitte an den Betreiber des einliefernden Servers und weisen ihn auf den hier geschilderten Umstand hin. Es obliegt dann dem Betreiber TLS zu deaktivieren oder seine Lösung dem aktuellen Stand der technischen Entwicklung anzupassen.

Icon Makefg

Fehler:

Bei manchen Benutzern kann der Antwortlink des NoSpamProxy Large Files nicht in die Mail eingefügt werden.

Lösung:

Prüfen Sie bitte, ob per GPO die folgende Sicherheitseinstellung greift:

GPO Einstellung für Antwortlink

Falls ja, setzen Sie bitte die aktivierte Sicherheitseinstellung auf “Disabled”.