• https://support.google.com/a/answer/81126
• https://blog.google/products/gmail/gmail-security-authentication-spam-protection/
• https://support.google.com/a/answer/14229414

1. Policy

Die Regeln fallen je nach versendeter Anzahl Mails/Tag in Richtung Google unterschiedlich scharf aus.

1.a. für alle Mailversender

• Passende A- und PTR-Records für Mailserver müssen im DNS vorhanden sein.
• SPF oder DKIM. Entweder müssen im DNS passende SPF-Records vorhanden oder die Mails müssen DKIM-signiert sein.
• Im From:-Header werden keine Google-Domains akzeptiert.
• Server, die Mails unverändert weiterleiten , sollen ARC-Header einfügen.
• Mailinglisten sollen in die Mails einen List-ID:-Header einfügen.
• Spamraten müssen unter 0,1% liegen.

1.a. ab 5000 Mails/Tag

Ab 5000 Mails/Tag an Google wird man als Absender von Massen-E-Mails / bulk sender betitelt. Hier kommen weitere Anforderungen hinzu:

• SPF und DKIM und DMARC. Man muss einen DMARC-Record im DNS veröffentlichen.
• Kommerzielle Marketing-Mails benötigen unsubscribe-Links nach RFC 8058.

1.c. Ausnahmen

Mails an Google-Workspace-Konten unterliegen diesen Regeln nicht.

2. Konsequenzen bei Verstößen

• Google beachtet die Policy im DMARC-Record, siehe https://support.google.com/a/answer/10032169
• Mails werden eventuell als Spam markiert zugestellt.
• Bei Spamraten über 0,3% werden alle Mails pauschal abgelehnt.
• Google plant einen Übergangszeitraum von Februar bis April, in dem schrittweise ein Ratelimiting mittels temporärer Ablehnungen (4xx) eingeführt wird.
• Ab April sollen dann analog harte Ablehnungen (5xx) hinzukommen.
• Ab Juni sollen die Inhalte der Mails auf unsubscribe-Links kontrolliert werden.

Zur Mitigation von Problemen bei der Zustellung (Googlesprech: Minderung) bietet Google folgendes Formular an: https://support.google.com/mail/contact/gmail_bulk_sender_escalation?hl=en

3. Zusätzliche Empfehlungen

Man soll den eigenen Maileingang bei Google mit Hilfe der Google-Postmaster-Tools beobachten. Einsehbar sind dort die Spamrate, die IP-Reputation der eigenen Mailserver, die Domain-Reputation sowie Zustellungsfehler. Details sind hier zu finden: https://support.google.com/mail/answer/9981691 Zur Nutzung dieser Tools wird ein Google-Konto benötigt.

Weiter beachtet Google die DMARC-Report-Option rua und versendet entsprechende Berichte: https://support.google.com/a/answer/10032472.

4. Unterstützung im DFN-MailSupport

Unsere Hotline unterstützt Sie gerne bei der Umsetzung, hier finden Sie nähere Informationen zu den technischen Details:

• https://www.mailsupport.dfn.de/dokumentation/checks/spf
• https://www.mailsupport.dfn.de/dokumentation/checks/dkim
• https://www.mailsupport.dfn.de/dokumentation/aktionen/dkim-signatur
• https://www.mailsupport.dfn.de/dokumentation/checks/dmarc
• https://www.mailsupport.dfn.de/dokumentation/checks/arc

Einige Details des SMTP-Protokolls werden von verschiedenen SMTP-Softwarepaketen nicht korrekt umgesetzt bzw. im Falle des Postfix werden solche Verstöße aus Kompatibilitätsgründen per Default akzeptiert.

Einem Angreifer ist es hiermit möglich, im Rahmen einer SMTP-Session zusätzliche Mails zu verschicken, bei denen die Envelope-From- und Header-From-Mailadressen gefälscht sein können, ohne dass der SPF-Check und damit der DMARC-Check dies bemerken. So übermittelte Phishing-Mails könnten dadurch etwas glaubhafter aussehen.

Details hierzu sind hier zu finden:

• www.postfix.org/smtp-smuggling.html
• sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide

Da hier leider die Gefahr besteht, auch gute Mails abzulehnen, schalten wir die empfohlene Mitigation nicht per Default scharf, sondern nur explizit auf Wunsch. Bitte wenden Sie sich hierfür an unsere Hotline.
 

Update 2.1.2024:

Wir haben seit heute die mit dem long-term fix versehene postfix-Version 3.5.23 im Einsatz, die Smugglingversuche erkennt und ablehnt.

• DMARC + ARC
  Diese Checks können Fälschungen der Absenderadresse im Header-From erkennen. Details finden Sie auf unseren neuen Seiten DMARC und ARC.
• DecodeShortURLs
  Dies ermöglicht ein rekursives Auflösen von Short-URLs bis zur tatsächlichen URL und unterstützt so die Checks gegen URL-Blacklisten.
• OLEVBMacro
  Die Erkennung von Makros in Office-Dokumenten wurde stark verbessert.

Auf den Spamassassin-Webseiten finden Sie eine Übersicht aller Änderungen.

• https://www.it-daily.net/it-sicherheit/cybercrime/hacker-nutzen-microsoft-onenote-anhaenge-um-malware-zu-verbreiten
• https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/trojanized-onenote-document-leads-to-formbook-malware/
• https://www.proofpoint.com/us/blog/threat-insight/onenote-documents-increasingly-used-to-deliver-malware

Hintergrund dieser Maßnahme ist der Umstand, dass vom Spamassassin auch SPF-Checks auf eben diese HELO-Strings durchgeführt werden, aber bisher mangels Auftauchen letzterer im Syslog das Filterergebnis in zweifelhaften Fällen nicht nachvollzogen und geprüft werden konnte.

https://www.spamhaus.com/resource-center/additional-protection-with-an-expanding-css-dataset/

Spamhaus wird in den nächsten Wochen jeweils pro Tag etwa 50.000 IP-Adressen aufnehmen, da das Auftreten von false positives nicht ganz auszuschließen ist. Falls dies passiert melden Sie sich bitte an unserer Hotline, wir pflegen dann die passenden Whitelisten.

550-5.7.26 This message does not have authentication information or fails to
           pass authentication checks. To best protect our users from spam, the
           message has been blocked. Please visit

            support.google.com/mail/answer/81126 for more

           information.

abgelehnt. Google hatte bekanntermaßen bereits seit längerer Zeit verschärfte Regeln im IPv6 aktiv, scheint jedoch dies nun auch in den IPv4-Bereich hinein auszudehnen. Der Inhalt der Webseite hinter dem Link in der Meldung deutet darauf hin, dass Google nun SPF und/oder DKIM beim Empfang erzwingen will. Aus einer Analyse des Maillogs kann man jedoch nicht auf ein eindeutiges Verhalten der gmail-Server schließen, Ablehnungen korrelieren nicht mit dem Vorhandensein von SPF-Records oder deren Inhalte, das Verhalten sieht mehr nach einem zufallsbasierten Würfeln aus.

Die Zahlen deuten jedoch darauf hin, dass ein korrekter SPF-Record die Wahrscheinlichkeit etwas erhöht, dass eine Mail nicht abgelehnt wird. Auch gab es bislang noch keinen Fall, in dem eine DKIM-signierte Mail abgelehnt wurde.

Falls Sie solche Probleme bei sich beobachten, raten wir daher zum Einsatz von SPF und/oder DKIM.

Den aktualisierten BSI-Button samt Zertifizierungsnummer finden Sie links unter dem Menü auf dieser Webseite.

Wir möchten uns hiermit ausdrücklich bei allen Kolleginnen und Kollegen bedanken, die uns – unbeeinträchtigt vom Pandemiegeschehen – an unseren Daten verarbeitenden Standorten im X-WiN, so herzlich und bestens vorbereitet empfangen und unterstützt haben!

Über das Portal können teilnehmende Einrichtungen einige Eckdaten zu ihrem Dienst selbstständig ändern, wie z.B. Maildomains und Mailserver, sowie Black- und Whitelists.

Sollten Sie als teilnehmende Einrichtung noch keinen Zugang (über DFN-AAI) haben, kommen Sie bitte auf uns zu unter hotline@mailsupport.dfn.de.

Nähere Informationen rund um DNSSEC, DANE & Co im MailSupport finden Sie hier: https://www.mailsupport.dfn.de/dokumentation/komponenten/dns

Nach eingehender Analyse des Sicherheitsvorfalls können wir bestätigen, dass weder personenbezogene Daten abgeflossen sind, noch Konfigurationsänderungen durch unbefugte Dritte vorgenommen wurden. Die Analyse hat ebenfalls ergeben, dass die Sicherheitslücke in der Zuständigkeit des Herstellers der genutzten Web-Umgebung liegt. Der Hersteller verweist auf das baldige Support-Ende und rät zur Migration auf eine neue Version. Da wir jedoch bereits eine Nachfolgelösung in Form eines neuen Portals zusammen mit einem externen Anbieter vorbereiten, und die Migration durch Abhängigkeiten im Source-Code sehr aufwendig ist, haben wir entschieden die Migration nicht mehr durchzuführen. Wir arbeiten intensiv daran, Ihnen wieder die Möglichkeit zu geben, ihren Dienst online zu administrieren.
Über die aktuellen Entwicklungen halten wir sie über diese Web-Seite und per E-Mail auf dem Laufenden.

Sobald sich dieser Zustand ändert, werden wir Sie hier darüber informieren.

Wir bitten Sie um Ihr Verständnis!

Um die Last auf den Systemen zu senken haben wir uns daher entschlossen, die SMTP-Rejects 'User unknown' und 'Protocol Errors' mit fail2ban zu erfassen und IP-Adressen, die 5 Fehlversuche in 10 Minuten liefern für 10 Minuten in der Firewall zu sperren.

Log-Analysen haben ergeben, dass nur in ganz wenigen Einzelfällen "gute" Mailsysteme davon betroffen sind, zB wenn diese Mailverteiler bedienen, die viele ungültige Empfänger enthalten. In diesen Fällen kann die Auslieferung um obige Zeiträume verzögert werden.

Zu diesem Check gibt es natürlich eine IP-Whitelist, in der wir Ausnahmen definieren können.

1. Update Banned-Rule

Unsere Liste der unerwünschten Anhangstypen haben wir an die aktuelle Microsoft-Outlook-Liste angepasst sowie aus weiteren Microsoft-Quellen die Liste erweitert. Folgende Typen wurden neu aufgenommen: aspx cer diagcab dqy htc jnlp msu oqy printerexport psd1 psdm1 py pyc pyo pyw pyz pyzw rqy theme vhd vhdx webpnp website xll

Details finden Sie unter: https://www.mailsupport.dfn.de/dokumentation/checks/anhaenge

2. Neuer Phishing-Check

Die Verschleierung von Buchstaben mittels HTML-Entities ist kein neues Phänomen und der Spamassassin geht damit problemlos um, sie kann aber als Phishing-Indikator eingesetzt werden, sofern die false-positive-Rate gering genug ist. Wir haben einen neuen Check eingeführt, bei dem Verschleierungsversuche von 'http://' und http://https://' in URLs erkannt und mit 7.0 Spampunkten bewertet werden. Sie erkennen den Hit im Syslog am Spamassassin-Hit

Falls es zu false positives kommt melden Sie bitte diese an unsere Hotline.

3. Neue Option im Attachment-Handling

Wir sind nun in der Lage, Mails mit unerwünschten Anhängen nicht nur markiert weiterzuleiten oder pauschal abzulehnen, sondern können nun auch Attachments herausschneiden und durch einen informativen Text ersetzen.

Bei Interesse melden Sie sich bitte an unserer Hotline.

• active-Liste: ... INFECTED (URLhaus.279542.UNOFFICIAL) ...
• recent-Liste: ... Tests: [...URLhaus30=15...]

Der Unterschied zwischen den beiden Listen liegt darin, dass die active-Liste nur die
URLs enthält, die in den letzten 48 Stunden in Mails gefunden wurden, während die recent-
Liste alle URLs der letzten 30 Tage enthält. Nähere Infos zu diesen Listen erhalten Sie

unter urlhaus.abuse.ch/api/

In diesem Zusammenhang erhielten wir zwei Listen von IP-Adressen und Domains, die wir als zusätzliche RBLs verwenden.  Bei Übereinstimmung mit Inhalten dieser Listen lehnen wir die Mails entweder ab oder vergeben 12 Spampunkte.

Bitte beobachten Sie Ihren Mailverkehr bezüglich der Wirksamkeit der Listen und achten Sie auch auf false positives und kommen Sie gegebenenfalls auf uns zu.

Erkennen können Sie Hits entweder an den RBL-URLs cds.spamhaus.org bzw. cdd.spamhaus.org oder an dem Spamassassin-Hit URIBL_CDD_SPAM. Die Verwendung der Domain 'spamhaus.org' hat interne technische Gründe, die Listen existieren bei Spamhaus nicht.

Weitere Informationen dazu und zur Verarbeitung der RBLs generell finden Sie unter "Dokumentation -> Checks -> RBL".

Diese Makros werden laufend modifiziert, so dass die AV-Hersteller nur
schwer mit der Bereitstellung von Pattern hinterherkommen. Es wird
daher immer ein gewisser Prozentsatz dieser Mails durch unsere
Virenscanner schlüpfen.

Nach unserer Einschätzung wird dieser Zustand noch eine geraume Weile
anhalten, da die Modifikationsmöglichkeiten innerhalb der Office-Makros
sehr vielfältig sind und daher kein Ende für das Hase-und-Igel-Spiel
abzusehen ist.

Unsere Filter können aber zuverlässig erkennen, ob Makros in einem
Dokument enthalten sind. Damit haben Sie die Möglichkeit, den Empfang von
makrobehafteten Office-Dokumenten pauschal zu blocken. Dies führt
zu Einschränkungen für ihre Nutzer! Verweisen Sie deshalb bitte
ausdrücklich auf alternative Formen des Dokumentenaustausches.

Bei Bedarf finden Sie in der DFN-Cloud Cloud-Lösungen im Wissenschaftsnetz,
die auf die besonderen Bedürfnisse von Wissenschaft und Forschung abgestimmt sind.
Weitere Informationen finden Sie unter: <link https: www.dfn.de dfn-cloud syncshare-dienste external-link-new-window internal link in current>

www.dfn.de/dfn-cloud/syncshare-dienste/

DNS-Konfiguration:

 Versenden Sie Mails über unsere Gateways (ausgehendes Filtern) und setzen SPF-Records für ihre Domains, so müssen sie folgendes Partikel in die SPF-Records aufnehmen:

include:spf.mailsupport.dfn.de

Ein weicher SPF-Record, der Weiterleitungen nicht unterbinden sollte, würde dann zum Beispiel so aussehen:

example.org TXT "v=spf1 include:spf.mailsupport.dfn.de ~all"

Und ein harter SPF-Record, der Weiterleitungen unterbindet, so:

example.org TXT "v=spf1 include:spf.mailsupport.dfn.de -all"

Wir haben die .mht-Anhänge nun in die Liste der verdächtigen Attachments aufgenommen.

Einrichtungen, die Anhänge nur markieren, sehen dies im "X-Amavis-Alert: BANNED"-Header, bei den Einrichtungen, die Attachments ablehnen, finden sich entsprechende Zeilen im Log.

DFN-Mailsupport erkennt Makros und gibt dies bei den Checks an:

<link DFN.ContainsMacros.UNOFF>DFN.ContainsMacros.UNOFFICIAL=0.01</link&gt; .

Die Spam-Bewertung mit 0.01 Punkten führt aber idR. nicht dazu, daß die Mail als Spam erkannt, wegsortiert oder abgelehnt wird. Wir haben diese Bewertung nun auf 4 Punkte erhöht.

Zusammen mit anderen Kriterien kann dies schon dazu beitragen, den Spamschwellwert von 6.2 Punkten zu erreichen.

Alternativ kann die Einordnung von Makros pro Einrichtung von "Spam mit 4 Punkten" auf "Virus" geändert werden, was aber in den meisten Fällen zu einer Ablehnung der Mail führen wird. Mitarbeiter, die Dokumente mit Makros austauschen wollen, sollten dies über Cloudlösungen oder Dokumentenserver tun, alternativ die Dokumente in zip-Files  mit Passwort kopieren und dann versenden.

Zusätzlich haben wir eine Regel eingeführt, die mehrfach vorkommende spitze Klammernpaare im From: erkennt. In der aktuellen Welle wird hier gern beim angezeigten und tatsächlichem From getrickst. Bei Vorkommen von mehreren spitzen Klammern werden 6 Punkte zur Spambewertung addiert.

seit heute morgen verzeichnen wir eine Makro-Viren-Welle, die bisher von den bei uns eingesetzten Virenscannern nicht erkannt wird. Lediglich die ClamAV Unofficial Pattern erkennen diese.

Derzeit bewerten wir diese wie folgt: <link http://http://DFN.ContainsMacros.UNOFF&gt;AV:DFN.ContainsMacros.UNOFFICIAL=0.01.&lt;/link&gt;

Wir werden diese Bewertung ändern, dann werden diese Mails als Virus eingeordnet und abgelehnt bzw. getaggt (die derzeitige Bewertung ist nur eine Spam-Bewertung, die zum Score beiträgt).

Damit verringert sich die Wahrscheinlichkeit, daß unbedarfte Nutzer die Mails anklicken.

Als zweite Möglichkeit bieten wir an, bei den Anhängen .doc zu markieren bzw. Anhänge abzulehnen inkl. doc. Dies kann für Sie innerhalb weniger Minuten geschaltet werden, bitte sprechen Sie uns an unter <link hotline@mailsupport.dfn.de>hotline@mailsupport.dfn.de.</link>

Update 08.11.2018, 16:30: die Regel wurde wieder deaktiviert, die Makroviren werden nunmehr vom Virenscanner ClamAV erkannt. Makros werden wieder im Spam-Header mit Score-Punkten versehen.