SPF max IPv4 & IPv6 [SOLVED]

[Ralph]

Mir ist gerade aufgefallen das ich bei meiner hostmaster Domain zu viele IP Adressen verwende 7 IP4 und 7 IP6 ... 10 ist wohl max. erlaubt.
Habe eine Menge Checks auf verschiedenen Plattformen geacht, wird als valide angezeigt - also insg. 14 Stück z.b.
https://dmarcly.com/tools/spf-record-checker

Wenn ich aber einen "dig TXT domain.tld +short" mache wird ab 10 unterbrochen bzw. neu angesetzt wie hier:

Code: Select all

 ip6" ":xxxx:xxx:xxx:xxx::1

"v=spf1 ip4:xxx.xxx.xxx.xx ip4:xxx.xxx.xxx.xx ip4:xxx.xxx.xxx.xx ip4:xxx.xxx.xxx.xx ip4:xxx.xxx.xxx.xx ip4:xxx.xxx.xxx.xx ip4:xxx.xxx.xxx.xx ip6:xxxx:xxx:xxx:xxx::1 ip6:xxxx:xxx:xxx:xxx::1 ip6:xxxx:xxx:xxx:xxx::1 ip6" ":xxxx:xxx:xxx:xxx::1 ip6:xxxx:xxx:xxx:xxx::1 ip6:xxxx:xxx:xxx:xxx::1 ~all"

Wegen der Panels und hostmaster, postmaster etc. möchte ich gerne bei diesen shared Hosts mit der Original Email arbeiten, also von allen Hosts ohne SPF fail versenden ...

Extern gab es damit bisher keine Probleme, nur mein Haupt System rejected trotz SPF whitelistings manchmal, vor allem wenn über IPv6 gesendet wird.

Hat jemand eine Idee?

[24unix]

eMail ist nicht so meine Stärke, aber kannst Du nicht einfach MX als Eintrag setzen?

[Ralph]

eMail ist nicht so meine Stärke, aber kannst Du nicht einfach MX als Eintrag setzen?

Bei einigen Scripts geht das auch, allerdings bei IPv6 scheint es da irgendwo Probleme zu geben bzw. der Lookup wird wie oben abgeschnitten und neu angesetzt ... wenn ich hier über dieses Tool einen Check mache wird weiter unten ein "Flattened SPF record" ausgegeben:
https://dmarcly.com/tools/spf-record-checker

Vor laaanger Zeit wurde bei solchen Fällen ein Flattened SPF record empfohlen ... könnte aber auch ein Ammenmärchen sein

### edit ###
also mein SPF record ist bereits flattened, also bringt das nichts ....
es gibt KEINE lookup Probleme wie hier beschrieben - max. 10 DNS-Lookups (ist halt seltsam mein zerhackter output von dig +short):
https://mxtoolbox.com/dmarc/spf/what-is-spf-flattening

According to RFC 7208, 'SPF implementations MUST limit the number of mechanisms and modifiers that do DNS Lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the "redirect" modifier"'. The mechanisms of: "include", "mx", "a", "ptr", and "exists" count against the limit of 10 lookups. The "all, "ip4", and "ip6" mechanisms do not count against the limit of 10 since they do not require a DNS Lookup.

Aber die Anzahl der IP Adressen scheint auch auf max. 10 Stück begrenzt zu sein ... oder liege ich da falsch?

[tab-kh]

Gibt es da nicht eine Beschränkung der Länge von TXT Records im DNS auf 256 Bytes? Wahrscheinlich wird das vom DNS-Editor transparent umgesetzt in kleinere Einzelstrings in double quotes. Dann wird dig +short aber die einzelnen Strings jeweils in einer eigenen Zeile ausgeben. Sieht man auch an den DKIM TXT records.

[tab-kh]

Gibt es da nicht eine Beschränkung der Länge von TXT Records im DNS auf 256 Bytes? Wahrscheinlich wird das vom DNS-Editor transparent umgesetzt in kleinere Einzelstrings in double quotes. Dann wird dig +short aber die einzelnen Strings jeweils in einer eigenen Zeile ausgeben. Sieht man auch an den DKIM TXT records.

Ändern kann ich es nicht mehr, also eben so...
Nicht die TXT-Records sind in der Länge beschränkt, es sind die Strings (maximal 255 Charakters). Alles was länger ist, muss also im DNS in Teilstrings zerlegt werden. Das mag der DNS-Editor automatisch machen. Wenn das aus welchem Grund auch immer nicht genehm ist (Scripts???), dann klappt es vielleicht per include?!? Jedes include sollte doch eigentlich nur einein DNS-Aufruf verursachen, den für den TXT-Record der inkludierten (Sub-)Domain. Oder zählen hier die TXT Records der Domain einzeln?

Wie auch immer, vielleicht kannst du deinen zu langen String aufteilen, die Teilstrings irgendwelchen Subdomains in deren SPF TXT-Record mitgeben und diese Subdomains dann alle inkludieren. So könnten alle Strings < 255 Charakters sein und trotzdem alle deine IPs erlaubt sein. Und Records mit zerstückelten Strings bräuchte es dann auch nicht.

Wie auch immer, dass das etwas bringen könnte ist erst mal nur eine Vermutung, ich habe es nie selbst gebraucht und deshalb auch nie probiert. Ich habe auch keine Idee, warum dein Hauptserver die SPF-Records mit mehreren Teilstrings nicht frisst.

Dass dig +short die TXT Records mit mehreren Teilstrings so ausgibt wie in deinem Beispiel ist jedenfalls völlig normal.

[Ralph]

Nicht die TXT-Records sind in der Länge beschränkt, es sind die Strings (maximal 255 Charakters). Alles was länger ist, muss also im DNS in Teilstrings zerlegt werden. Das mag der DNS-Editor automatisch machen. Wenn das aus welchem Grund auch immer nicht genehm ist (Scripts???), dann klappt es vielleicht per include?!? Jedes include sollte doch eigentlich nur einein DNS-Aufruf verursachen, den für den TXT-Record der inkludierten (Sub-)Domain. Oder zählen hier die TXT Records der Domain einzeln?

Ja, das wäre dann nachvollziehbar ... also wie bei den DKIM keys.
mx includes funktioniert zwar, aber dann bekomme ich bei den Checks "Lookup time" Fehler als Resultat.
Der flattened SPF (wie jetzt verwendet mit 14 IPs) zeigt bei den Checks das beste Resultat 0 lookup time, der SPF fail tritt auch extern (gmail) nicht auf, allerdings hier bei den internen lookups, trotz whitelisting.

Die whitelist habe ich unten angehängt in:

Code: Select all

/etc/postfix-policyd-spf-python/policyd-spf.conf
...
skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1

Whitelist = xxx.xxx.xxx.xxx
Domain_Whitelist = test.tld

Wie auch immer, vielleicht kannst du deinen zu langen String aufteilen, die Teilstrings irgendwelchen Subdomains in deren SPF TXT-Record mitgeben und diese Subdomains dann alle inkludieren. So könnten alle Strings < 255 Charakters sein und trotzdem alle deine IPs erlaubt sein. Und Records mit zerstückelten Strings bräuchte es dann auch nicht.

Hmm, also der geteilte String der bei der dig +short Abfrage ausgegeben wird, wäre ja dann quasi verwendebar?
müsste nur vor dem zertückelten ip6 gestezt werden

Code: Select all

ip6" ":xxxx:xxx:xxxx:xxx::1

zu

Code: Select all

"ip6":xxxx:xxx:xxxx:xxx::1 ... " ..."

Bisher habe ich da noch keine Vorgaben finden können für SPF records, aber ich könnte mir vorstellen, es führt zum gleichen Ergebnis wie die Verwendung von zwei SPF records ...

Das ganze stammt vermutlich noch aus der Zeit wo IPv6 noch nicht im Spiel war ... Systeme mit IP4 + IP6 beiben demnach nur noch 5 Einträge anstatt 10.

auch ein Test via: check-auth@verifier.port25.com (bei diesem wurde die IPv6 getestet) ist OK
SPF check: pass
"iprev" check: pass
DKIM check: pass

[Tobi]

Ich habe das auch mit „include“ gelöst.
Zwar eine etwas andere Aufgabenstellung, aber da includes weitere includes beinhalten können, kann man das sehr übersichtlich gestalten.

So könntest du einen SPF Record auf ipv6.sfp.ralph.tld und einen auf ipv4.spf.ralph.tld setzen. Anschließend bindest du beide mit include auf spf.ralph.tld ein.

Bei allen (Kunden-)Domains kannst du dann ganz einfach sfp.ralph.tld als SPF Record eintragen.

[tab-kh]

Lookup time ist eventuell ein gutes Stichwort. Ich meine irgendwo gelesen zu haben, dass ein Fail auch passieren kann, wenn einfach das Auflösen des entsprechenden Records dem empfangenden Server zu lang gedauert hat. Das mag mit der Stringlänge zusammenhängenn, muss aber nicht. Das kann m.E. eher im Gegenteil an allen möglichen Dingen liegen.

• Route dem empfangenden Server und dem DNS-Server, also Paketverluste Latenzen und Bandbreiten
• Performance des DNS-Servers
• Hat der DNS-Servers die Antwort im Cache?
• DNSSEC (kostet natürlich auch Zeit)
  [...]

Ich muss das nochmal suchen, also ob es tatsächlich irgendeine maximal zulässige Zeit für die Antwort gibt, nach der ein SPF-Check einfach ein Fail ergeben darf usw. Muss ja eigentlich, kein Server wartet da bis zum St. Nimmerleinstag auf den SPF TXT Record. Aber wenn bei dir im Check ein Fehler bei der Lookup Time kommt, dann ist diese jedenfalls nicht unerheblich für den Erfolg der Prüfung, sonst müsste man sie nicht messen. Und sehr wahrscheinlich ist das Liit dafür eher kurz bemessen. Das ist auch eine variable Zeit, die von Abruf zu Abruf und auch abhängig von den beteiligten Servern und auch ihrer Last schwanken wird. Welche Resolver verwendet denn dein Hauptsystem? Und welche Nameserver deine Hostmaster Domain?

[Ralph]

So könntest du einen SPF Record auf ipv6.sfp.ralph.tld und einen auf ipv4.spf.ralph.tld setzen. Anschließend bindest du beide mit include auf spf.ralph.tld ein.

Hallo Tobi, wie viele includes sind bei Dir enthalten?
Schau mal hier ob die Anzahl der lookup queries bei Dir auch bemängelt wird.
https://dmarcly.com/tools/spf-record-checker

Bei den Kunden Server ist alles Ok, da sind insgesamt nur 4 IP Adressen im SPF record, ist bei mir halt der Haupt Server mit hostmaster Email die von all den shared Hosts für mich verwendbar sein soll.

Lookup time ist eventuell ein gutes Stichwort. Ich meine irgendwo gelesen zu haben, dass ein Fail auch passieren kann, wenn einfach das Auflösen des entsprechenden Records dem empfangenden Server zu lang gedauert hat. Das mag mit der Stringlänge zusammenhängenn, muss aber nicht. Das kann m.E. eher im Gegenteil an allen möglichen Dingen liegen.

Na ja, besser formuliert die "Anzahl der lookup queries" die Fehlermeldung im reject bzw. bei Checks zeigt halt dann eine Zeitüberschreitung an - eben dann wenn zu viele queries nötig sind.

Tja, mir fällt jetzt gerade auch nichts besseres ein als die SPF IPs flattened zu setzen, im Grunde ist das ja richtig wenn wie bei mir 14 IPs verwendet werden.
Bei Online Checks werden diese auch alle schön untereinander aufgelistet, nur bei einem DIG lookup sehe ich da eine Zerstücklung.

[tab-kh]

Für deine IPs sind doch gar keine Queries erforderlich

Also ich verstehe es jedenfalls nicht, wo die vielen Lookups herkommen sollen. Habe eine Domain durch den obigen Checker gejagt und der zeigt mir 4 Lookups und alles ok. Das incude zählt er nur als ein Lookup, obwohl da noch MXe von mailbox.org drin sind. Es wird ja wohl nicht daran liegen, dass von dem Tool Einzel-IPs gezählt werden und Subnetze nicht. Jedenfalls sind es in Summe deutlich mehr als 10 (unterschiedliche) IPs und Subnetze.Wüsste jetzt nicht, warum das nicht auch mit includes eigener Domains oder Subdomains so aussehen sollte.

SPF-Record

Code: Select all

v=spf1 a mx ip4:xx.xx.224.129 include:mailbox.org ~all

Ergebnis von https://dmarcly.com/tools/spf-record-checker

Success!

Everything appears fine with your SPF record. 4 DNS queries

example.com
ip4:xx.xx.224.129
a
ip4:xxx.xx.32.129
mx
ip4:xxx.xx.32.129
include:mailbox.org
ip4:213.203.238.0/25
ip4:195.10.208.0/24
ip4:91.198.250.0/24
ip4:80.241.56.0/21
ip667c:/48
mx
ip4:80.241.60.215
ip667c104::2:25:1
ip4:80.241.60.216
ip667c104::3:25:1
ip4:91.198.250.17
ip667c104::ffff:25:1
ip4:80.241.60.212
ip667c104::1:25:1
~all
~all

[Ralph]

Für deine IPs sind doch gar keine Queries erforderlich

Ja, so isses deswegen bevorzuge ich bei den langen SPF die IP Adressen ...
Ich denke ich werde es dann so lassen, die Probleme sehe ich momentan nur intern und die relevanten IPs sind alle vorne im String.
In der SPF Whitelist verwende ich normalerweise nur IP Adressen ... eventl. werde ich da die MX names bei den Problemfällen noch hinzufügen müssen.

Wie gesagt bei heutigen Dual Stack Systemen finde ich diese Beschränkung unpassend, reicht nicht immer aus bei Verwendung von ip4 + ip6.

[Ralph]

Für deine IPs sind doch gar keine Queries erforderlich

Jetzt nicht mehr, hatte es vorher mal mit 6 MX includes versucht und da gab es dann Probleme.


Bei allen Checks mit Flattened SPF auch hier mit A+ und "Email server's SPF, DMARC and DKIM are properly set"
https://www.immuniweb.com/ssl/

[tab-kh]

Also das hier funktioniert auch, mit zusammengestückelten Strings im TXT Record. Und die Trennung geht einmal sogar zwischen "i" und "p6"

dig _spf_v6.webhosting.systems txt +short
"v=spf1 ip6:2a03:4000:0:200::/56 ip6:2a03:4000:27:578:e81d:28ff:fe2a:e4b9 ip6:2a03:4000:34:4d4:e449:7ff:fee3:c48d ip6:2a03:4000:21:611:1479:86ff:fe4e:c332 ip6:2a03:4001:0:200::160 ip6:2a03:4001:0:200::164 ip6:2a03:4001:0:200::168 ip6:2a03:4001:0:200::172 i" "p6:2a03:4001:0:109:94ab:73ff:fe56:b085 ip6:2a03:4001:0:108:a80e:45ff:fe08:52bc ip6:2a03:4000:3c::/48 ip6:2a00:11c0:82:1117::/64 ~all"

Und da sind im eigentlichen spf vom übergeordneten _spf.webhosting.systems (netcup) noch die zwei includes für _spf_v4 und _spf_v6 (s.o.) drin. Das Ganze include ich (und bestimmtTausende anderer netcup-Kunden) dann in mein SPF und das Ergebnis geht ganz locker durch den Checker. Die Mails werden auch nicht angemeckert, höchstens mal bei Microsoft oder irgendwelchen UCE_PROTECTL3 Junkies, da aber aus anderen Gründen und nicht wegen fehlerhaftem SPF :mrgreen:.

[Ralph]

Also das hier funktioniert auch, mit zusammengestückelten Strings im TXT Record. Und die Trennung geht einmal sogar zwischen "i" und "p6"

dig _spf_v6.webhosting.systems txt +short
"v=spf1 ip64000:0:200::/56 ip64000:27:578:e81dfe2a:e4b9 ip64000:34:4d4:e449:7ff:fee3:c48d ip64000:21:61186ff:fe4e:c332 ip64001:0:200::160 ip64001:0:200::164 ip64001:0:200::168 ip64001:0:200::172 i" "p64001:0:109:94ab:73ff:fe56:b085 ip64001:0:108:a80e:45ff:fe08:52bc ip64000:3c::/48 ip611c0:82:/64 ~all"

ja, ist auch eine Flattened SPF Methode - wie meine aktuelle ... hierbei zestückelt eine Abfrage via dig auch an dieser Stelle und diese IP wird dann intern scheinbar ignoriert:

Code: Select all

i" "p6

Bei meinen Online Checks ist auch alles bestens, nur halt eben der dig output nicht ... keine Ahnung ob dies bei meinen internen lookups relevant ist und daher manchmal die betreffende IP nicht findet ... jedenfalls betrifft es nur diese IPv6 nach der Zerstückelung bei mir

[Ralph]

Eine mögliche Ursache wäre allerdings auch das das "postfix-policyd-spf-python" package ... da sind immer noch uralte Macken enthalten z.b. auch die URL in "Reason_Message" ist unbrauchbar, wenn ein User den Link klickt wird eine Fehlerseite angezeigt:

Code: Select all

http://www.openspf.net/Why?s=mfrom;id=admin@domain.tld;ip=xxx:xxx:xxx:xxx::x;r=<UNKNOWN>
Die Website ist nicht erreichbar
www.openspf.net hat die Verbindung abgelehnt.
Versuche Folgendes:
Verbindung prüfen
Proxy und Firewall prüfen
ERR_CONNECTION_REFUSED

2020 gemeldet siehe:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1882920

ich nehme den Link jetzt mal ganz da raus:

Code: Select all

nano /etc/postfix-policyd-spf-python/policyd-spf.conf

unter

Mail_From_reject = Fail

zusätzlich eigene Reason_Message einfügen z.b.

Code: Select all

Reason_Message = Message {rejectdefer} due to: {spf}.