Versionsinformationen für SecurityGateway für Email Servers v4.5

SecurityGateway wurde vor dem Hintergrund 20-jähriger praxiserprobter Erfahrung im Bereich der E-Mail-Sicherheit entwickelt und stellt Sicherheitsfunktionen für E-Mail zu einem bezahlbaren Preis bereit. SecurityGateway schützt gegen Spam, Viren, Phishing, Spoofing und andere Arten von Schadprogrammen und Malware, welche die legitime Kommunikation über E-Mail in Ihrem Unternehmen laufend bedrohen.

Näheres über SecurityGateway für Email Servers erfahren Sie hier.

SecurityGateway 4.5.1 - 2017-05-09

BESONDERS WICHTIGE NEUE LEISTUNGSMERKMALE

[15657] In SecurityGateway ist jetzt der RMail™-Dienst von RPost® integriert.

Die Nutzung von RMail™ ist selbsterklärend. Die Empfänger benötigen hierfür keine besondere Software. RMail™ verbessert die Nutzung von E-Mail-Diensten für Verbraucher und Unternehmen aller Größenordnungen, in allen Sektoren und Bereichen.

Der RMail™-Dienst wird durch das Leistungsmerkmal Registered Email™ von RPost umgesetzt - den weltweiten Standard für Zustellnachweise bei E-Mail-Nachrichten. Der RMail™-Dienst erweitert Ihrer E-Mail-Plattform und bietet folgende Leistungsmerkmale:

Bei Nutzung kostenloser Benutzerkonten für RPost ist jeder Benutzer auf Versand und Empfang von insgesamt 10 verschlüsselten Nachrichten pro Monat beschränkt. Weitere Nachrichten können über RPost erworben werden. Klicken Sie hier, um Informationen über Leistungspakete und Preisgestaltung für Nachrichtenversand und -empfang in größerem Umfang zu erhalten.

Sie können den RMail™-Dienst auf der Seite Sicherheit | RMail™ oder mithilfe von Aktionen in Regeln des Inhaltsfilters aktivieren.

ÄNDERUNGEN UND NEUE LEISTUNGSMERKMALE

BEHOBENE FEHLER

SecurityGateway 4.5.0 - 2017-04-04

ZUR BESONDEREN BEACHTUNG

[18161] Die Option "APOP & CRAM-MD5 aktivieren" im Konfigurationsdialog Einstellungen / Benutzer | E-Mail-Konfiguration | E-Mail-Protokoll wurde aus Sicherheitsgründen und aus technischen Gründen geändert. Die Option ist jetzt per Voreinstellung deaktiviert. Das bevorzugte Verfahren, um die Übermittlung von Kennwörtern im Klartext zu vermeiden, ist TLS.

ÄNDERUNGEN UND NEUE LEISTUNGSMERKMALE

BEHOBENE FEHLER

SecurityGateway 4.0.1 - 2016-07-26

ÄNDERUNGEN UND NEUE LEISTUNGSMERKMALE

BEHOBENE FEHLER

SecurityGateway 4.0.0 - 2016-06-14

BESONDERS WICHTIGE NEUE LEISTUNGSMERKMALE

[15999] Aktualisierung der Web-Schnittstelle und Einführung eines reaktionsfähigen Designs

Die Webschnittstelle und wurde auf ein reaktionsfähiges Design umgestellt, dass in erster Linie von einer mobilen Nutzung ausgeht. Das zugrundeliegende Konzept wird auch als Mobile First Responsive Design bezeichnet. Es werden der Internet Explorer ab Version 10, die neuesten Versionen von Chrome und Firefox, sowie unter MacOS und iOS die neuesten Versionen von Safari unterstützt. Die Standard-Browser auf Android-Geräten zeigen bekannte Probleme beim Scrollen; Chrome funktioniert auf Android-Geräten jedoch gut.

Das neue Design stützt sich ausschließlich auf die Größe des jeweils genutzten Fensters. Das Aussehen ist für gleiche Fenstergrößen immer gleich, und zwar unabhängig davon, ob der Benutzer ein Mobiltelefon, ein Tablet oder einen PC nutzt. Die wichtigste Änderung betrifft dabei das Menü. Bei einer Fensterbreite von 956 Bildpunkten oder weniger ist das Menü auf der linken Seite des Browserfensters ausgeblendet. Es bestehen zwei Möglichkeiten, das Menü anzuzeigen. Falls ein Bildschirm mit Berührungseingabe (Touchscreen) genutzt wird, kann das sekundäre Menü durch eine Wischgeste nach rechts eingeblendet werden. Außerdem kann durch Antippen des Steuerelements Menü in der oberen rechten Fensterecke das sekundäre Menü aufgerufen werden. Durch Antippen oder Anklicken des Menütitels am oberen Rand des Menüs, neben dem ein Pfeil nach links erscheint, erscheint das primäre Menü. Das Menü Hilfe, Informationen und Abmelden in der oberen rechten Fensterecke ändert sich ebenfalls mit der Fensterbreite. Ab 768 Bildpunkten erscheinen die die Texte Hilfe, Information und Abmelden. Zwischen 481 und 767 Bildpunkten erscheinen nur die Symbole, und bei 480 Bildpunkten oder weniger erscheint ein Zahnrad-Symbol, unter dem nach dem Antippen oder Anklicken ein Menü mit den Einträgen Hilfe, Informationen und Abmelden erscheint. Listenansichten mit mehr als einer Spalte erhalten Steuerelemente, mit denen die einzelnen Spalten ein- und ausgeblendet werden können.

[11232] DMARC

DMARC wird jetzt unterstützt. "DMARC" steht für Domain-based Message Authentication, Reporting, and Conformance, domänengestützte Echtheitsbestätigung, Berichte und Übereinstimmung. Die Spezifikation für DMARC beschreibt ein anpassungsfähiges Verfahren, durch das Stellen, die E-Mail-Nachrichten versenden, mithilfe des Domain Name Systems auf Domänen-Ebene Richtlinien und Anforderungen für die Prüfung und Behandlung von Nachrichten sowie die Berichte hierüber veröffentlichen können. Stellen, die E-Mail-Nachrichten empfangen, können diese Richtlinien und Anforderungen nutzen, um die Behandlung von E-Mail-Nachrichten zu verbessern. Die Spezifikation für DMARC und genaue Informationen über die Funktionsweise finden Sie in englischer Sprache unter http://www.dmarc.org/.

DMARC gestattet es den Inhabern von Domänen, Anforderungen für die Behandlung solcher Nachrichten zu veröffentlichen, die vorgeben, von ihren Domänen aus versandt worden zu sein, bei denen dies aber tatsächlich nicht zutrifft. Die Richtlinie für die Behandlung von Nachrichten kann in diesem Falle folgende Anforderungen bestimmen: "none" (keine) bewirkt, dass SecurityGateway bei solchen Nachrichten keine besonderen Maßnahmen ergreift, "reject" (abweisen) bewirkt, dass SecurityGateway bereits während der SMTP-Verbindung die Nachricht abweist und nicht zur Zustellung entgegennimmt, und "quarantine" (in Quarantäne geben) bewirkt, dass SecurityGateway die Kopfzeile "X-SGDMARC-Fail-policy: quarantine" in alle betroffenen Nachrichten einfügt, sodass die Nachrichten anhand dieser Kopfzeile leicht gefiltert und beispielsweise in den Ordner Spamverdacht geleitet werden können. Diese Kopfzeile wird nur dann in die Nachrichten eingefügt, wenn das Ergebnis der DMARC-Prüfung "fail" (fehlgeschlagen) lautet. SecurityGateway kann aber wahlweise auch Nachrichten annehmen, obwohl die DMARC-Richtlinien verlangen, dass sie abgewiesen werden; diese Vorgehensweise ist per Voreinstellung aktiv. Schlägt dann die Prüfung einer Nachricht fehl, so fügt SecurityGateway die Kopfzeile "X-SGDMARC-Fail-policy: reject" in die Nachricht ein, damit sie besonders behandelt und gefiltert werden kann.

DMARC löst ADSP und die Leistungsmerkmale des SPF zur Behandlung von Nachrichten ab. Sie können jedoch ADSP und SPF neben DMARC weiterhin einsetzen. Die Abweisung von Nachrichten aufgrund der ADSP-Verarbeitung oder der SPF-Prüfung erfolgt jetzt, falls die DMARC-Prüfung aktiv ist, erst nach der DMARC-Prüfung.

DMARC hängt teilweise von der Nutzung einer Liste öffentlicher Domänenendungen ("Public Suffix List") ab. Öffentliche Endungen sind Domänenendungen, unter denen Nutzer im Internet Namen unmittelbar registrieren können. Beispiele für solche Domänenendungen sind .com, .co.uk, .de und pvt.k12.ma.us. Eine Liste öffentlicher Domänenendungen ist eine Liste aller bekannten öffentlichen Domänenendungen. SecurityGateway nutzt die durch die Mozilla Foundation für die Öffentlichkeit bereitgestellte und unterhaltene Liste. Sie ist verfügbar unter https://publicsuffix.org/. Eine Kopie dieser Liste ist in Ihrem App-Verzeichnis unter dem Dateinamen effective_tld_names.dat installiert. Derzeit steht keine verbindliche Quelle mit erschöpfendem Inhalt für eine solche Liste zur Verfügung; dieses Problem kann jedoch nur Internet-weit gelöst werden. Mit der Zeit wird die bei der Installation im Verzeichnis App hinterlegte Liste überholt werden; sie muss dann erneut von https://publicsuffix.org/list/effective_tld_names.dat abgerufen und im Verzeichnis App abgelegt werden. SecurityGateway lädt die Liste im Abstand von etwa zwei Wochen während der Bereinigungsvorgänge herunter und legt sie im Verzeichnis App an. Dieser Aktualisierungsvorgang wird mithilfe mehrerer neuer Optionen gesteuert, die im neuen Konfigurationsdialog für DMARC enthalten sind. Das DMARC-Protokoll und der neue Bereich DMARC auf der Registerkarte Sicherheit auf der Benutzeroberfläche enthalten Informationen über die Aktualisierung und alle anderen Verarbeitungsvorgänge im Zusammenhang mit DMARC. Sie können, falls gewünscht, auch einen anderen URL angeben, von dem die Liste heruntergeladen wird. In allen Fällen müssen die heruntergeladenen Daten aber in dem Format vorliegen, das die Mozilla Foundation für ihre Liste festgelegt hat. Sie können diese Formatdefinition ebenfalls unter dem oben genannten URL einsehen. SecurityGateway wendet die Auswertungsalgorithmen, die die Mozilla Foundation festgelegt hat, strikt an. Falls Sie Änderungen an der Datei effective_tld_names.dat im SecurityGateway-Verzeichnis \App\ vorgenommen oder die Datei dort ersetzt haben, können Sie SecurityGateway durch Anlegen der Datei "PUBLICSUFFIX.SEM" im selben Verzeichnis veranlassen, die Liste ohne Neustart neu zu laden.

Um DMARC als Absender von E-Mail-Nachrichten zu nutzen, müssen Sie einen DMARC-Eintrag des Typs TXT im DNS Ihrer Domäne veröffentlichen. Informationen über Inhalt und Struktur dieses Eintrags finden Sie - derzeit nur in englischer Sprache - unter http://www.dmarc.org. Nachdem Sie den DMARC-Eintrag im DNS veröffentlich haben, können Sie DMARC-Berichte zahlreicher unterschiedlicher Gegenstellen über E-Mail empfangen. Diese Berichte werden als komprimierte XML-Dateien übermittelt; ihr Format ist in der DMARC-Spezifikation festgelegt. Die DMARC-Implementation in SecurityGateway sieht eine Auswertung dieser Berichte durch SecurityGateway selbst nicht vor. Die Daten aus den Berichten können aber wichtige Aufschlüsse geben über den Mailverkehr der Domäne, die fehlerhafte Verwendung der Domäne, die Unversehrtheit und Gültigkeit der DKIM-Signaturen und die Richtigkeit und Genauigkeit der Nachrichtenleitwege, wie sie für das SPF wichtig sind. Sie legen die Adresse, an die diese Berichte gesendet werden sollen, bei der Erstellung des DMARC-Eintrags fest.

Bei der Erstellung der DMARC-Einträge für Ihre Domänen ist bei Nutzung der Richtlinie p=reject besondere Vorsicht angezeigt. Diese Richtlinie kann besonders dann negative Wirkung haben, wenn sie E-Mail-Adressen betrifft, die für die Nutzung durch natürliche Personen vorgesehen sind. Die Verwendung von p=reject kann beispielsweise dazu führen, dass Benutzer Mailinglisten, Weiterleitungsdienste oder Empfehlungsfunktionen wie etwa "Artikel an einen Freund senden" oder "Produkt weiterempfehlen" nicht mehr nutzen können. Tritt dieser Fall ein, dann ist mit nachdrücklichen Beschwerden der Benutzer zu rechnen. Die DMARC-Richtlinie p=reject ist grundsätzlich nicht zu beanstanden und kann sehr hilfreich sein; ihre Vorteile entfaltet sie aber hauptsächlich dann, wenn sie für Domänen veröffentlicht wird, in denen die Nutzung der E-Mail-Konten strikt geregelt ist. Beispiele hierfür sind die Nutzung durch funktionsbezogene und nicht benutzerbezogene E-Mail-Konten, Konten für automatischen E-Mail-Versand, die Durchsetzung von Unternehmensrichtlinien, die die Nutzung im Verkehr mit Dritten regeln und vergleichbare Anwendungsfälle.

SecurityGateway speichert die Daten, die nach der DMARC-Spezifikation zur Erstellung zusammengefasster ("aggregierter") DMARC-Berichte benötigt werden. SecurityGateway wertet dabei den DMARC-Tag "ri=" nicht aus und erstellt nur zusammengefasste DMARC-Berichte, die für jeden Tag den Zeitraum von 00.00:00 Uhr UTC bis 23.59:59 Uhr UTC umfassen. Um Mitternacht UTC (dies muss nicht zwingend auch Mitternacht Ortszeit sein) wertet SecurityGateway die gespeicherten Daten aus und erstellt die Berichte. SecurityGateway muss zu diesem Zeitpunkt tatsächlich ausgeführt werden, da sonst die gespeicherten Daten immer weiter anwachsen und nicht abgearbeitet werden können. Falls Sie daher SecurityGateway nicht durchgehend ausführen, sollten Sie die zusammengefassten DMARC-Berichte nicht aktivieren. Die Erstellung der zusammengefassten DMARC-Berichte ist per Voreinstellung abgeschaltet.

SecurityGateway unterstützt die DMARC-Fehlerberichte. Hierfür wurden RFC 5965 (Ein erweiterbares Format für E-Mail-Feedback-Berichte), RFC 6591 (Berichte über Fehler in der Echtheitsbestätigung mithilfe des Formats für Berichte über missbräuchliche Nutzung ARF), RFC 6652 (Berichte über Fehler bei der SPF-Verarbeitung mithilfe des Formats für Berichte über missbräuchliche Nutzung ARF), RFC 6651 (Erweiterungen für Fehlerberichte bei DomainKeys Identified Mail [DKIM]) und RFC 6692 (Ursprungsports im Format für Berichte über missbräuchliche Nutzung ARF) vollständig implementiert. Fehlerberichte werden in Echtzeit und schritthaltend mit den Ereignissen erstellt, die sie auslösen. SecurityGateway hat den Berichtstyp AFRF für DMARC-Fehlerberichte implementiert, nicht aber den Berichtstyp IODEF. Aus diesem Grund werden nur die Einträge "afrf" in den DMARC-Tags "rf=" befolgt. Umfassende Informationen hierüber finden Sie in der DMARC-Spezifikation. Aus der Verarbeitung einer einzelnen Nachricht können auch mehrere Fehlerberichte entstehen; dies hängt von der Zahl der Empfänger im Tag "ruf=" des DMARC-Eintrags sowie dem Wert des Tags "fo=" und der Anzahl eigenständiger fehlgeschlagener Versuche zur Echtheitsbestätigung ab, die bei Verarbeitung der Nachricht aufgetreten sind. Verlangt der DMARC-Tag "fo=" auch Berichte über Fehler bei der SPF-Prüfung, so sendet SecurityGateway SPF-Fehlerberichte nach RFC 6522. Aus diesem Grund müssen die Erweiterungen für diese Spezifikation im SPF-Eintrag der Domäne enthalten sein. SPF-Fehlerberichte werden nicht unabhängig von der DMARC-Verarbeitung gesendet; sie werden ferner nicht gesendet, falls die Erweiterungen nach RFC 6522 fehlen. Verlangt der DMARC-Tag "fo=" auch Berichte über Fehler bei der DKIM-Prüfung, so sendet SecurityGateway DKIM- und ADSP-Fehlerberichte nach RFC 6651. Aus diesem Grund müssen die Erweiterungen für diese Spezifikation in der Kopfzeile für die DKIM-Signatur enthalten sein, und für die Domäne muss ein gültiger TXT-Eintrag zu den DKIM-Berichten im DNS veröffentlicht sein; alternativ können auch gültige ADSP-Erweiterungen im TXT-Eintrag für ADSP veröffentlicht sein. Die DKIM- und ADSP-Fehlerberichte werden nicht unabhängig von der DMARC-Verarbeitung gesendet; sie werden ferner nicht gesendet, falls die Erweiterungen nach RFC 6651 fehlen. Umfassende Informationen hierüber finden Sie in den angegebenen Spezifikationen. Die DMARC-Fehlerberichte sind per Voreinstellung abgeschaltet.

Achtung: Ein DMARC-Eintrag kann auch bestimmen, dass Berichte an einen Dritten gesandt werden, der im Auftrag des Domäneninhabers handelt. Diese Vorgehensweise kann beispielsweise gewählt werden, wenn der Domäneninhaber einen Dienstleister mit der Überwachung des Mailverkehrs auf missbräuchliche Nutzung und unzureichende Systemleistung beauftragt hat. Es muss dann aber sichergestellt sein, dass der Dritte die in den DMARC-Berichten enthaltenen Daten auch erhalten darf; dies kann aufgrund der Datenschutzrichtlinien, der Nutzungsrichtlinien oder anderer Regelungen unzulässig sein. Die einschlägigen Regelungen müssen daraufhin geprüft werden, ob sie die DMARC-Berichte einschränken, und die DMARC-Berichte müssen, falls erforderlich, abgeschaltet werden.

DMARC erfordert die Nutzung von STARTTLS immer dann, wenn der Empfänger eines Berichts dieses Verfahren unterstützt. Es besteht aber keine Möglichkeit, vorauszusehen, wann dies der Fall ist, und die Nutzung von STARTTLS zu überwachen. Sofern auf Ihrem System aber STARTTLS nicht ohnehin bereits aktiv ist, sollten Sie STARTTLS aber ohnehin aktivieren (vgl. Einstellungen/Benutzer -> Sicherheit -> Verschlüsselung).

Die Kopfzeile Authentication-Results wurde erweitert und enthält jetzt auch die Ergebnisse der DMARC-Verarbeitung. Bitte beachten Sie, dass die Kommentare dieser Kopfzeile einige Daten zur Fehlerbehebung enthalten; hierzu gehört auch die DMARC-Richtlinie, die der Domäneninhaber veröffentlicht hat, und die nicht zwingend mit der Maßnahme übereinstimmen muss, die für die Nachricht ausgeführt wird. Ergibt beispielsweise die DMARC-Prüfung "pass", so ist die DMARC-Richtlinie selbst bedeutungslos, da sie nur dann angewendet wird, wenn die DMARC-Prüfung mit dem Ergebnis "fail" fehlschlägt. Schlägt aber beispielsweise die DMARC-Prüfung mit dem Ergebnis "fail" fehl, dann wird die Nachricht unter Umständen trotzdem aufgrund lokaler Richtlinien zur Zustellung angenommen. Wird die Kopfzeile zum Filtern von Nachrichten verwendet, so müssen diese Erwägungen berücksichtigt werden. Alternativ kann auch nach den Kopfzeilen "X-SGDMARC-Fail-policy: quarantine" und "X-MDDMARC-Fail-policy: reject" gesucht werden, und diese Nachrichten können beispielsweise in die Ordner für verdächtige Nachrichten verschoben werden. SecurityGateway entfernt die Kopfzeile "X-SGDMARC-Fail-policy:" aus allen eingehenden Nachrichten.

Die Absenderkopfzeile From nach RFC 5322 muss in allen Nachrichten den Festlegungen aus Abschnitt 15.1 des DMARC-Standards entsprechen, da diese sonst nicht verarbeitet werden. Fehlt eine Absenderkopfzeile im richtigen, in RFC 5322 bestimmten, Format, oder ist mehr als eine Absenderkopfzeile vorhanden, so wird die Nachricht insgesamt als nicht standardkonform angesehen und nicht als gültig durch DMARC verarbeitet.

Dem Konfigurationsdialog Sicherheit -> Anti-Spoofing wurden mehrere Abschnitte hinzugefügt, in denen Sie die verschiedenen Optionen für die Nutzung von DMARC konfigurieren können.

DMARC erfordert SPF und/oder die DKIM-Prüfung, da sich DMARC auf die durch beide Verfahren geprüften Identitäten der Absender stützt. Sie können bei eingehenden Nachrichten DMARC nicht sinnvoll nutzen, falls Sie nicht mindestens eines der genannten Verfahren ebenfalls nutzen. Die Benutzeroberfläche versucht, dieses Erfordernis durchzusetzen.

[3961] Bindung von Domänen an IP-Adressen

Auf Servern, denen mehrere IP-Adressen zugewiesen sind, kann jede Domäne an eine bestimmte IP-Adresse gebunden werden. Nachrichten, die von solchen gebundenen Domänen ausgehen, werden über die IP-Adresse versandt, an die die jeweilige Domäne gebunden ist.

Für die Domänen können auch SMTP-Hostnamen angegeben werden. Diese Domänennamen werden als vollqualifizierte Domänennamen (FQDN) angegeben und beim Versand von Nachrichten der Domänen in den SMTP-Befehlen HELO/EHLO übermittelt. Bei eingehenden Verbindungen werden die FQDN ebenfalls übermittelt, falls nicht mehrere Domänen an dieselbe IP-Adresse gebunden sind. Sind mehrere Domänen an dieselbe IP-Adresse gebunden, so wird der Domänenname übermittelt, der in alphabetischer Reihenfolge an erster Stelle steht.

ÄNDERUNGEN UND NEUE LEISTUNGSMERKMALE

BEHOBENE FEHLER

Copyright ©1996-2016 Alt-N Technologies, Ltd.