Zum Hauptinhalt springen

Appendix D. SPF/Mediator Interactions (SPF/Vermittler-Interaktionen)

Appendix D. SPF/Mediator Interactions (SPF/Vermittler-Interaktionen)​

Dieser Anhang diskutiert die Interaktion zwischen SPF und E-Mail-Vermittlern (wie Mailinglisten und Weiterleitungsdienste) sowie deren Auswirkungen.

D.1 Originating ADMDs (Ursprungs-ADMD)​

Das Ursprungs-ADMD ist die administrative Domain, die ursprünglich die E-Mail sendet. Bei Vorhandensein von Vermittlern muss das Ursprungs-ADMD die Weiterleitungs- und Listendienste berücksichtigen, die seine E-Mails durchlaufen können.

D.1.1 Problemidentifikation​

SPF-Grundannahme:

  • E-Mails werden direkt von autorisierten Servern an Empfänger gesendet
  • MAIL FROM-Identität bleibt unverändert
  • Absender-IP-Adresse ist im SPF-Eintrag autorisiert

Von Vermittlern gebrochene Annahmen:

  • E-Mails durchlaufen Zwischensysteme
  • Können von einer anderen IP-Adresse erneut gesendet werden
  • MAIL FROM kann geändert oder unverändert bleiben

D.1.2 Optionen für Absender​

Option 1: Lockere SPF-Richtlinie verwenden

example.com IN TXT "v=spf1 mx ~all"

Vorteile:

  • Erlaubt legitime Weiterleitung
  • Reduziert Fehlalarme

Nachteile:

  • Schwächt den SPF-Schutz
  • Leichter zu fälschen

Option 2: Auf andere Authentifizierungsmethoden setzen

DKIM-Signaturen veröffentlichen:
- DKIM bleibt bei Weiterleitung gültig
- Unabhängig von Absender-IP-Adresse
- Funktioniert mit DMARC zusammen

Option 3: SPF-Fehler akzeptieren

example.com IN TXT "v=spf1 mx -all"
  • Akzeptieren, dass einige legitime E-Mails markiert oder abgelehnt werden können
  • Darauf vertrauen, dass Benutzer die richtige Sendemethode verwenden
  • Benutzern empfehlen, nicht weiterzuleiten, sondern "Als Kopie senden" zu verwenden

D.1.3 Best Practices​

Empfohlene Konfiguration:

1. Strengen SPF-Eintrag veröffentlichen (-all)
2. Gleichzeitig DKIM-Signierung implementieren
3. DMARC-Richtlinie veröffentlichen
4. Benutzer über Weiterleitungsprobleme aufklären

DMARC-Konfigurationsbeispiel:

_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected]"

Parametererklärung:

  • adkim=r: DKIM-Relaxed-Alignment
  • aspf=r: SPF-Relaxed-Alignment
  • p=quarantine: Bei Fehler E-Mail unter Quarantäne stellen

D.2 Mediators (Vermittler)​

Vermittler sind Systeme, die E-Mails in der Übertragungskette ändern oder erneut senden. Häufige Vermittler umfassen Mailinglisten, Weiterleitungsdienste und automatische Antwortsysteme.

D.2.1 Mailinglisten​

Problem:

Herkömmliche Mailinglisten behalten das ursprüngliche MAIL FROM bei:

Original: MAIL FROM:`<[email protected]>`
Nach Liste: MAIL FROM:`<[email protected]>`
Absender-IP: list-server.mailinglist.org

SPF-Prüfung:

SPF-Eintrag von example.com abfragen
IP von list-server.mailinglist.org prüfen
Ergebnis: fail (IP ist nicht im SPF-Eintrag von example.com)

D.2.2 Lösungen​

Lösung 1: MAIL FROM neu schreiben (empfohlen)

Umgeschrieben: MAIL FROM:`<[email protected]>`
Reply-To: [email protected]

Vorteile:

  • SPF-Prüfung besteht
  • Bounces gehen an Listenserver zurück
  • Empfänger kann korrekt identifizieren

Nachteile:

  • Ändert ursprüngliche Absenderinformationen
  • Benutzer müssen sich an Reply-To anpassen

Implementierungsbeispiel (Mailman):

# Mailman-Konfiguration
from_is_list = 2  # Munge From, add Reply-To

Lösung 2: SRS (Sender Rewriting Scheme) verwenden

SRS ist ein komplexeres Umschreibungsschema:

Original: [email protected]
Umgeschrieben zu: [email protected]

SRS-Format:

SRS0=<hash>=<timestamp>=<domain>=<localpart>@<forwarder>

Beispiel:
[email protected]

Vorteile:

  • Bewahrt ursprüngliche Absenderinformationen (im local-part)
  • SPF-Prüfung besteht
  • Kann nachverfolgt und verifiziert werden

Nachteile:

  • Komplexe Implementierung
  • Benötigt SRS-Datenbank
  • local-part wird schwer lesbar

Lösung 3: DKIM anstatt SPF verwenden

Konfiguration:

1. Ursprünglicher Absender verwendet DKIM-Signierung
2. Listenserver behält ursprüngliche Signatur bei
3. Listenserver fügt eigene DKIM-Signatur hinzu
4. Empfänger verifiziert DKIM (ignoriert SPF-Fehler)

DMARC-Konfiguration:

_dmarc.example.com IN TXT "v=DMARC1; p=none; adkim=r; aspf=r"
  • p=none: Keine Durchsetzung (erlaubt SPF-Fehler)
  • adkim=r: DKIM-Relaxed-Alignment (erlaubt Listensignatur)

D.2.3 E-Mail-Weiterleitungsdienste​

Typ 1: Einfache Weiterleitung

Benutzerkonfiguration: [email protected] → [email protected]
Weiterleitungsdienst behält bei: MAIL FROM:`<[email protected]>`
Sendet von IP des Weiterleitungsservers

SPF-Problem:

Gmail prüft SPF von original.com
IP des Weiterleitungsservers ist nicht im SPF-Eintrag
Ergebnis: fail

Lösung A: SRS-Umschreibung

Weiterleitungsdienst verwendet SRS:
MAIL FROM:<[email protected]>

Lösung B: ~all statt -all verwenden

original.com IN TXT "v=spf1 mx ~all"

Weitergeleitete E-Mails erhalten softfail statt fail, werden eher akzeptiert.

Typ 2: .forward-Datei

# ~/.forward
[email protected]

Problem identisch mit einfacher Weiterleitung.

Best Practices:

1. Weiterleitungsdienste sollten SRS implementieren
2. Ursprünglicher Absender sollte DKIM verwenden
3. Empfänger sollten DKIM-Ergebnisse berücksichtigen, nicht nur SPF

D.2.4 Automatische Antwort- und Benachrichtigungssysteme​

Problem:

Original-E-Mail: [email protected] → [email protected]
Automatische Antwort: MAIL FROM:`<[email protected]>`
         (Gesendet von company.com-Server)

SPF-Prüfung wird fehlschlagen.

Lösung:

Benachrichtigungen mit leerem MAIL FROM senden:
MAIL FROM:<>
From: Mail Delivery System `&lt;[email protected]&gt;`

Oder:

Lokale Adresse verwenden:
MAIL FROM:`&lt;[email protected]&gt;`
From: Automatic Reply `&lt;[email protected]&gt;`
Reply-To: [email protected]

D.3 Receiving ADMDs (Empfänger-ADMD)​

Empfänger-ADMD muss E-Mails von Vermittlern verarbeiten und angemessene Entscheidungen treffen.

D.3.1 Erkennung von Vermittler-E-Mails​

Identifikatoren:

1. Zwischenhops in Received-Headern
2. List-*-Header (Mailinglisten)
3. Precedence: bulk oder list
4. SRS-formatiertes MAIL FROM
5. DKIM-Signatur von bekanntem Listendienst

Beispielerkennungslogik:

def is_mailing_list(message):
    # List-*-Header prüfen
    list_headers = [
        'List-Id', 'List-Post', 'List-Unsubscribe',
        'List-Help', 'List-Subscribe', 'List-Owner'
    ]
    
    for header in list_headers:
        if message.get(header):
            return True
    
    # Precedence prüfen
    if message.get('Precedence') in ['bulk', 'list']:
        return True
    
    # SRS prüfen
    mail_from = message.get('Return-Path', '')
    if mail_from.startswith('SRS0=') or mail_from.startswith('SRS1='):
        return True
    
    return False

D.3.2 Richtlinienempfehlungen​

Richtlinie 1: Lockerer Umgang mit Listen-E-Mails

if is_mailing_list(message):
    if spf_result == 'fail':
        # DKIM prüfen
        if dkim_result == 'pass':
            accept_message()
        else:
            # Listen-Reputation prüfen
            if list_is_trusted(list_id):
                accept_message()
            else:
                quarantine_message()

Richtlinie 2: Auf DMARC verlassen

if dmarc_result == 'pass':
    accept_message()
elif spf_result == 'fail' and dkim_result == 'fail':
    reject_message()
else:
    # SPF oder DKIM eins besteht
    if is_mailing_list(message):
        accept_message()
    else:
        apply_content_filtering()

Richtlinie 3: Benutzerspezifische Regeln

Benutzer können Whitelists konfigurieren:
- Vertrauenswürdige Mailinglisten
- Bekannte Weiterleitungsadressen
- Lockere Behandlung bestimmter Domains

D.3.3 Implementierungsempfehlungen​

SpamAssassin-Konfiguration:

# Lockerer Umgang mit Mailinglisten
header LIST_ID exists:List-Id
score LIST_ID -0.1

# SPF fail aber mit List-Id-Header
meta SPF_FAIL_LIST (SPF_FAIL && LIST_ID)
score SPF_FAIL_LIST 0.5

# Normaler SPF fail (ohne Listenheader)
score SPF_FAIL 5.0

Postfix-Konfiguration:

# smtpd_recipient_restrictions
reject_unauth_destination,
check_policy_service unix:private/spf-policy,
permit

# SPF-Richtliniendienst kann Listen-E-Mails erkennen und entsprechend anpassen

rspamd-Konfiguration:

-- SPF-Modulkonfiguration
spf {
  -- Unterschiedliche Gewichtung für Mailinglisten anwenden
  symbol_fail = "R_SPF_FAIL";
  symbol_softfail = "R_SPF_SOFTFAIL";
  
  -- Benutzerdefinierte Regeln
  custom_symbols = {
    R_SPF_FAIL_LIST = {
      score = 2.0,
      description = "SPF failed but from mailing list",
      condition = function(task)
        local spf = task:get_symbol('R_SPF_FAIL')
        local list_id = task:get_header('List-Id')
        return spf and list_id
      end
    }
  }
}

D.4 Interoperabilitätsempfehlungen​

D.4.1 Standardisierung​

Standardheader verwenden:

Mailinglisten sollten hinzufügen:
- List-Id: &lt;list-name.domain.com>
- List-Post: &lt;mailto:[email protected]>
- List-Unsubscribe: &lt;mailto:[email protected]>
- Precedence: bulk

DKIM-Signierung:

Listenserver sollten:
1. Ursprüngliche DKIM-Signatur beibehalten (falls vorhanden)
2. Eigene DKIM-Signatur hinzufügen
3. Signierte Header nicht ändern

D.4.2 Kommunikation​

Absenderbenachrichtigung:

Listendienst sollte Abonnenten informieren:
- E-Mails werden vom Listenserver erneut gesendet
- MAIL FROM wird umgeschrieben
- Empfehlung, Reply-To für Listenantworten zu verwenden

Empfängerdokumentation:

Empfängerrichtlinien dokumentieren:
- Wie Listen-E-Mails verarbeitet werden
- Whitelist-Mechanismus
- Benutzerkonfigurierbare Optionen

D.5 Zukünftige Entwicklungsrichtung​

D.5.1 ARC (Authenticated Received Chain)​

RFC 8617 führte ARC ein:

ARC ermöglicht Vermittlern das Hinzufügen von Authentifizierungsinformationen:
- ARC-Seal: Vermittlersignatur
- ARC-Message-Signature: Nachrichtensignatur
- ARC-Authentication-Results: Authentifizierungsergebnisse

Beispiel:

ARC-Seal: i=1; a=rsa-sha256; t=1234567890; cv=none;
    d=mailinglist.org; s=arc-seal; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
    d=mailinglist.org; s=arc-msg; h=from:to:subject; b=...
ARC-Authentication-Results: i=1; mailinglist.org;
    spf=pass [email protected];
    dkim=pass header.d=example.com

Vorteile:

  • Bewahrt ursprüngliche Authentifizierungsergebnisse
  • Ermöglicht Kettenverifizierung
  • Empfänger können Vermittlern vertrauen

D.5.2 Empfehlungen​

Für neue Bereitstellungen:

  1. DKIM und SPF implementieren
  2. DMARC-Richtlinie veröffentlichen
  3. ARC-Unterstützung in Betracht ziehen (falls Vermittler)
  4. Interoperabilität mit gängigen Mailinglisten testen

Für bestehende Systeme:

  1. Strenge SPF-Richtlinien überprüfen
  2. DMARC-Berichte überwachen
  3. Problematische Quellen identifizieren (Listen, Weiterleitungen usw.)
  4. Richtlinien anpassen oder SRS implementieren
Letztes Update am