SPF voor grote omgevingen

[CAPSLOCK2000]

Ik ben de laatste tijd met SPF aan het stoeien. Nu is het gebruikelijk om de mailservers van je partners op te nemen in je eigen SPF-record zodat die partners namens jou kunnen mailen. Wij includen dus SPF van partijen als google, mailchimp en nog wat andere partijen die mail versturen vanaf ons domein.

We liepen de laatste tijd namelijk tegen het probleem aan dat ons SPF-record te lang is geworden.
De regel is dat je maximaal 10 DNS-lookups mag doen en we hebben nu al meer partners. Ik werk voor een middelgrote organisatie en wij lopen keihard tegen die limiet aan. Hoe doen andere grote organisaties dat?

Een oplossing is om geen gebruik te maken van externe mailservers en alles via je eigen mailservers te vesturen. Dan moeten we onze partners dus toegang geven tot onze mailservers, dat hebben we liever niet en kunnen we hoe dan ook niet op korte termijn regelen. Dat valt voor mij dus af.

Een andere oplossing is om je SPF-record helemaal uit te schrijven. Een "ip" record bevat al een rauw ip-adres (of netwerk) en heeft geen extra DNS-lookup nodig. Ik heb een scriptje geschreven dat een SPF-record pakt en dat recursief uitschrijft in losse ip-adressen. Op zich werkt dat prima, maar omdat we veel partners hebben die op hun beurt weer andere partners includen in hun SPF-record loopt het aantal ip-adressen in de honderden.

Dat past al niet meer in één record (die mogen maximaal 255 tekens lang zijn) en ik heb dus inmiddels meerdere records die worden samengevoegd:

code:

@ IN TXT "v=spf1 include:_spf1.example.com include:_spf2.example.com include:_spf3.example.com ... -all"
_spf1 IN TXT "v=spf1 ip:1.1.1.1 ip:2.2.2.2 ip:3.3.3.3 ?all"
_spf2 IN TXT "v=spf1 ip:4.4.4.4 ip:5.5.5.5 ip:6.6.6.6 ?all"
_spf3 ...
etc....

Nu ben ik zo ver dat het eerste record (dat alle andere records include) meer dan 255 tekens lang is geworden. Ik kan nog een laag indirectie (_spf1 =_spfa + _spfb) toevoegen maar dat wordt me een beetje al te gek.


Heeft er iemand advies, wijze woorden of een geniale inval?

[CyBeR]

Mail vanaf subdomeinen?

Verder is 't lastig want je zit nu al direct met het probleem dat je die eigen SPF records nu zélf moet aan bijhouden elke keer als Google of Mailchimp of watdanook een nieuw IP-adres gebruikt.

[ Voor 81% gewijzigd door CyBeR op 18-07-2016 17:55 ]

[PerfectPC]

ik zie slechts 2 opties:
- het aantal partners dat e-mails mag versturen in naam van drastisch reduceren (waarom zou je dat in hemelsnaam willen?)
- spf laten vallen (+all van maken dus) of spf rfc compliancy laten vallen (heb nog nooit gemerkt dat dit fout loopt bij 10+ lookups)

[ Voor 20% gewijzigd door PerfectPC op 18-07-2016 19:41 ]

[CAPSLOCK2000]

CyBeR schreef op maandag 18 juli 2016 @ 17:54:
Mail vanaf subdomeinen?

Aardig idee maar ik denk niet dat ik het aan Communicatie verkocht krijg, die zijn geobsedeerd met "mooie" adressen.

Verder is 't lastig want je zit nu al direct met het probleem dat je die eigen SPF records nu zélf moet aan bijhouden elke keer als Google of Mailchimp of watdanook een nieuw IP-adres gebruikt.

Dat is zo, daarom heb ik een scriptje geschreven dat dit voor me doet. Dat krijgt als input de SPF-records van onze partners en zoekt DNS af om alle ip-adressen te verzamelen en stelt daar nieuwe SPF-records uit samen met alleen ip-adressen. Die publiceer ik. Het is de bedoeling dat het scriptje automatisch gaat draaien maar ik wil het nog wat meer testen voor ik er op kan vertrouwen.

PerfectPC schreef op maandag 18 juli 2016 @ 19:40:
- het aantal partners dat e-mails mag versturen in naam van drastisch reduceren (waarom zou je dat in hemelsnaam willen?)

Ik probeer het aantal partners te beperken maar de organisatie waar ik voor werk heeft nogal veel min of meer zelfstandige afdelingen die allemaal hun eigen weg zoeken. Helaas zit ik niet in de positie om daar veel aan te doen. Als wij er van horen is het meestal omdat er iets mis is.

- spf laten vallen (+all van maken dus)

Ik geef momenteel een ?all, dat geeft beter weer hoe ik over SPF denk, namelijk "ik weet het niet". Daarmee dacht ik klaar te zijn maar het bleek maar moeilijk uit te leggen aan onze klanten en partners. Die bleven maar vragen om hun mailservers aan ons SPF-record toe te voegen. Op een gegeven moment zijn we zo dom geweest om daar aan toe te geven en zijn we iedereen gaan toevoegen die daar om vroeg. Met die ?all erbij zou het niet uit moeten maken, dachten we.
Al die gasten er weer uit gooien is Plan B als al het andere faalt.
Helaas (nou ja) wordt er steeds meer waarde aan SPF gehecht door Google en dergelijken.

of spf rfc compliancy laten vallen (heb nog nooit gemerkt dat dit fout loopt bij 10+ lookups)

British Telecom weigert onze mail om deze reden en een belangrijke klant heeft er last van dus ik moet iets doen. Voor het moment ben ik uit de brand maar deze oplossing schaalt niet.

[Freeaqingme]

CAPSLOCK2000 schreef op maandag 18 juli 2016 @ 20:05:
[...]

Aardig idee maar ik denk niet dat ik het aan Communicatie verkocht krijg, die zijn geobsedeerd met "mooie" adressen.


[...]

Er zit natuurlijk een verschil tussen de envelope-from adres, waar SPF over gaat en wat de eindgebruiker eigenlijk nooit ziet, en een From-header die de eindgebruiker ziet. De laatste beveilig je natuurlijk middels DKIM. Als iedereen een eigen (sub)domein gebruikt in de envelope kan meteen iedereen makkelijk z'n bounces tracken. Win-win

Edit: Overigens, de max van 10 lookups vind ik inderdaad ook niet zo groot. Ik probeer dat dan op te lossen door m'n records zo efficient mogelijk in te delen, en zo groot mogelijke subnets te definieren. Beetje zoals _spf.google.com het doet. Wat mij betreft zou die max best omhoog mogen, eventueel gecombineerd met een minimum TTL voor SPF records.

[ Voor 22% gewijzigd door Freeaqingme op 18-07-2016 20:19 ]

[CyBeR]

CAPSLOCK2000 schreef op maandag 18 juli 2016 @ 20:05:
[...]

Aardig idee maar ik denk niet dat ik het aan Communicatie verkocht krijg, die zijn geobsedeerd met "mooie" adressen.

Ja, maar je zou een partner-eigen domein kunnen gebruiken in de envelope from maar vervolgens gewoon je eigen domein in de From: header stoppen. SPF kijkt naar die eerste, de ontvanger over 't algemeen naar die 2e

Sterker nog: veel e-mailverzenders doen dat standaard zo.

Freeaqingme schreef op maandag 18 juli 2016 @ 20:16:
[...]
Edit: Overigens, de max van 10 lookups vind ik inderdaad ook niet zo groot.

Die is er om DDoS-by-SPF te voorkomen.

[ Voor 18% gewijzigd door CyBeR op 18-07-2016 20:31 ]

[Freeaqingme]

CyBeR schreef op maandag 18 juli 2016 @ 20:30:
[...]

Die is er om DDoS-by-SPF te voorkomen.

Ja, ik snap waarom 'ie er is. Maar persoonlijk zou ik er geen probleem mee gehad hebben als de max op, zeg, 25 stond.

[Plopeye]

Aardig idee maar ik denk niet dat ik het aan Communicatie verkocht krijg, die zijn geobsedeerd met "mooie" adressen.

Zo'n discussie heb ik ook een keer met marketing / communicatie gasten gehad...

Gewoon uitleggen dat als ze willen blijven communiceren en er ook nog van uit willen blijven gaan dat hun gecommuniceerde boodschap blijft aankomen in deze wereld dat ze dan die obsessie moeten laten varen.
Zo niet wens je ze veel succes met hun communicatie... (Die niet aankomt...)

[PenguinPower]

CAPSLOCK2000 schreef op maandag 18 juli 2016 @ 17:47:

code:

_spf1 IN TXT "v=spf1 ip:1.1.1.1 ip:2.2.2.2 ip:3.3.3.3 ?all"
_spf2 IN TXT "v=spf1 ip:4.4.4.4 ip:5.5.5.5 ip:6.6.6.6 ?all"
_spf3 ...
etc....

Nu ben ik zo ver dat het eerste record (dat alle andere records include) meer dan 255 tekens lang is geworden. Ik kan nog een laag indirectie (_spf1 =_spfa + _spfb) toevoegen maar dat wordt me een beetje al te gek.


Heeft er iemand advies, wijze woorden of een geniale inval?

_spf1/2/3 kan korter.

code:

spf.example.com. IN A 1.1.1.1
spf.example.com. IN A 2.2.2.2
spf.example.com. IN A 3.3.3.3
spf.example.com. IN A 4.4.4.4
spf.example.com. IN A 5.5.5.5
spf.example.com. IN A 6.6.6.6
spf.example.com. IN AAAA 2001:db8::1
example.com. IN TXT "v=spf1 a:spf.example.com ?all"

[ Voor 2% gewijzigd door PenguinPower op 20-07-2016 21:02 . Reden: werkt ook met ipv6 ]

[CAPSLOCK2000]

Hey, dat is een aardig idee, daarmee kan ik nog wat extra besparen. Die ga ik opschrijven voor de volgende keer dat ik tegen de limiet aanloop

[CyBeR]

Let wel dat er ook een limiet zit aan hoeveel A's je in 1 DNS UDP packet kwijt kunt en naar 't schijnt (ik heb van horen zeggen) ondersteunt microsoft geen EDNS.

[CyBeR]

Als je dat soort dingen wilt kun je denk ik beter een DNSBL maken en met exists bezig gaan. Maar dan zit je wel aan dusdanig geavanceerde SPF spullen te werken dat je er denk ik niet meer zonder meer van uit kunt gaan dat elke server 't ondersteunt.

(exists:%{ir}._spf.domain.com zou checken voor 4.3.2.1._spf.domain.com als de server die komt mailen 1.2.3.4 is.)

[ Voor 20% gewijzigd door CyBeR op 20-07-2016 23:35 ]

[DJVG]

Is het niet zo dat je met de redirect modifier aan het eind (dus ipv all) de lookups reset? Dus als hij niet matched laten redirecten naar het volgende spf record: https://tools.ietf.org/html/rfc7208#section-6.1

[CyBeR]

Je bedoelt zelf een soort ketting van spf records opzetten en dan spf1 redirect=spf2, spf2 redirect=spf3, etc. doen? Theoretisch zou dat werken maar 't is niet moeder's mooiste oplossing imo.

Redirect is eigenlijk meer om als je meerdere domeinen hebt, de SPF record bij 1 domein onder te brengen en de rest gewoon daarnaar te verwijzen.

Ik denk om dit écht op te schalen dat je de macro-methode van mijn vorige post moet gebruiken maar dat 't wel noodzakelijk is om eerst te testen hoe de implementaties van SPF in het wild daarmee om gaan.

[ Voor 76% gewijzigd door CyBeR op 22-07-2016 01:00 ]

[DJVG]

Maar je mag redirect wel opgeven aan het eind, dus je kan meerdere SPF's includen en de individueel laten redirecten naar de grote blocks van de mail-toko's omdat hij pas stopt bij een match of een (-|?|~)all/none.

Moet zeggen dat ik je macro methode interessant vind, op die manier zou je ook nog eens kunnen "afschermen" dat het makkelijk te achterhalen is welke IP's je toestaat.

[ Voor 28% gewijzigd door DJVG op 22-07-2016 08:08 ]

[Powermage]

CAPSLOCK2000 schreef op maandag 18 juli 2016 @ 17:47:
Wij includen dus SPF van partijen als google, mailchimp en nog wat andere partijen die mail versturen vanaf ons domein.

Mailchimp werkt idd met eigen gegenereerde adressen met SPF en DKIM en de reply en from zaken staan dan op het adres van wat de verzender configt,
Zoals Freeagingme al geschreven heeft.

Freeaqingme schreef op maandag 18 juli 2016 @ 20:16:
[...]


Er zit natuurlijk een verschil tussen de envelope-from adres, waar SPF over gaat en wat de eindgebruiker eigenlijk nooit ziet, en een From-header die de eindgebruiker ziet. De laatste beveilig je natuurlijk middels DKIM. Als iedereen een eigen (sub)domein gebruikt in de envelope kan meteen iedereen makkelijk z'n bounces tracken. Win-win

Dus ik zou eerst eens zelf checken of jou SPF records wel gebruikt worden, indien dit zo is kijken of die systemen dit lekker zelf kunnen afhandelen en vervolgens 70% van je SPF schrappen, zal je een hoop beheer schelen.

[kevertje1977]

Google doet het zelf ook :

;; ANSWER SECTION:
google.com. 3599 IN TXT "v=spf1 include:_spf.google.com ~all"


;; ANSWER SECTION:
_spf.google.com. 299 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"


;; ANSWER SECTION:
_netblocks.google.com. 3599 IN TXT "v=spf1 ip4:64.18.0.0/20 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:207.126.144.0/20 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"


etc