Wir sind kürzlich bei einem unserer Kunden auf einige seltsame SPF-Probleme gestoßen. Wir können nicht zuverlässig feststellen, ob eine Nachricht, die angeblich von ihrer eigenen Domain stammt, tatsächlich echt ist oder nicht, wenn wir SPF verwenden. Der Grund... Sie haben Salesforce in ihre SPF-Einträge aufgenommen, und Salesforce verwendet ein Makro, das Probleme verursachen kann.

Schauen wir uns das Problem an

Wir werden die Domain example.com, einschließlich Salesforce, genau so verwenden, wie es unser Kunde gemacht hat. Hier ist ein Beispiel für einen SPF-Eintrag für example.com.

v=spf1 ip4:206.168.70.196 include:_spf.salesforce.com include:spf.protection.outlook.com -all

Der oben genannte SPF-Eintrag ist gut und robust. Er definiert eine einzelne IP-Adresse, von der E-Mails zugelassen werden, und enthält zusätzlich eine Reihe von Organisationen, die diese Domain ebenfalls für verschiedene Dienste verwendet. Er endet mit -all, was bedeutet, dass keine E-Mail von example.com akzeptiert werden sollte, sofern die IP-Adresse des Absenders nicht innerhalb der in dem SPF-Eintrag angegebenen Bereiche liegt.

Wenn ein Server eine Nachricht von example.com empfängt, kann er den SPF-Eintrag verwenden, um zu überprüfen, ob die IP-Adresse der Nachricht von einer autorisierten IP-Adresse stammt. Wir werden dies im Detail erläutern und dabei die IP-Adresse 35.80.210.20 verwenden, die Salesforce gehört und die zu einem PASS führen sollte, der bestätigt, dass der Absender der Nachricht echt ist.

SPF-Mechanismen auswerten

• ip4:206.168.70.196

  ---

  Kein Treffer, weiter prüfen...

  ---

• include:_spf.salesforce.com

  ---

  Dies ist ein Include, das uns anweist, SPF-Daten einzubinden, die Salesforce veröffentlicht. Wenn wir es nachschlagen, erhalten wir Folgendes:

  v=spf1 exists:%{i}._spf.mta.salesforce.com -all

  Dieser SPF-Mechanismus ist eine Makro, der Server, der die SPF-Prüfung durchführt, soll ${i} durch die IP-Adresse des Absenders ersetzen. Nach der Substitution mit der IP-Adresse erhalten wir:

  35.80.210.20._spf.mta.salesforce.com

  We now have a host name of 35.80.210.20._spf.mta.salesforce.com and the server doing the SPF check needs to see if that host name resolves. Our SPF check checks if the host is valid, yes - it resolves so the SPF check is valid. Odds are good the message is genuine.

Ein Virus greift an

Nun können wir dieselben Tests durchführen, wenn eine Spam-Nachricht für einen Computervirus eine Nachricht erzeugt hat, die behauptet, von example.com zu stammen. Sie sollte leicht als Fälschung zu erkennen sein, da sie nicht von einer IP-Adresse stammt, die in der SPF-Liste der Domain enthalten ist. Unsere IP-Adresse wird 123.200.123.200 sein, also führen wir die Tests noch einmal durch.

SPF-Mechanismen auswerten

• ip4:206.168.70.196

  ---

  Kein Treffer, weiter prüfen...

  ---

• include:_spf.salesforce.com

  ---

  Dies ist ein Include, das uns anweist, SPF-Daten einzubinden, die Salesforce veröffentlicht. Wenn wir es nachschlagen, erhalten wir Folgendes:

  v=spf1 exists:%{i}._spf.mta.salesforce.com -all

  Dieser SPF-Mechanismus ist eine Makro, der Server, der die SPF-Prüfung durchführt, soll ${i} durch die IP-Adresse des Absenders ersetzen. Nach der Substitution mit der IP-Adresse erhalten wir:

  123.200.123.200._spf.mta.salesforce.com

  We now have a host name of 123.200.123.200._spf.mta.salesforce.com and the server doing the SPF check needs to see if that host name resolves. Our SPF check checks if the host is valid, yes - it resolves so the SPF check is valid. Odds are good the message is genuine.