Je gebruikt een vraagteken na het IP adres...

% host _i.85.159.96.4._h.mailer1.belastingdienst.nl._o.belastingdienst.nl._spf.belastingdienst.nl
_i.85.159.96.4._h.mailer1.belastingdienst.nl._o.belastingdienst.nl._spf.belastingdienst.nl has address 127.0.0.1

Ik vermoed dat hier iemand enthousiast aan het hobbyen geslagen is en dat je binnen korte tijd een simpeler SPF
record gaat aantreffen...

Ik krijg zelf nooit mail van de belastingdienst dus ik kan het niet natrekken, maar het zou me niks verbazen als er
zat implementaties van SPF zijn die dit helemaal niet aankunnen. Ik had er zelf ook nooit van gehoord, ik zie normaal
alleen platte letterlijke SPF records plus "include".
(misschien hopen ze dat de simplistische implementaties ook die redirect= op toplevel al niet snappen en dan maar
aannemen dat er geen SPF is?)

Mijn eerste gedachte achter het gebruik van de macro's is dat ze bij de belastingdienst graag willen weten vanaf welke IP's er mails binnenkomen uit naam van belastingdienst.nl . Immers zal een ontvangende mailserver de SPF policy volgen en dus het IP van de verzendende mailserver terug communiceren in een DNS query. Een interessante keuze want volgens mij kan je daarvoor ook DMARC reporting gebruiken.

Bij het gebruik van de "exists" lijkt het er op dat er een DNS A query gedaan wordt en ongeacht de waarde de policy klopt. Als ik zelf query wat je hebt aangegeven krijg ik echter een DNS SERVFAIL terug. Als ik het record probeer op te halen bij een grote publieke resolver krijg ik wel degelijk een IP voor 127.0.0.1 terug. Het lijkt er dus op dat wel wel een record aanwezig is, maar ook op mijn systeem faalt het ophalen daarvan. Wellicht nog eens dubbel checken of je niet ook een DNS error terug krijgt i.p.v. een NXDOMAIN or NOERROR? Ik kan overigens niet helemaal terug vinden waarom dit niet werkt, ik zie een melding dat een signature niet klopt terwijl dit wel het geval is, als ik https://dnssec-debugger.verisignlabs.com/_i.85.159.96.4._h.mailer1.belastingdienst.nl._o.belastingdienst.nl._spf.belastingdienst.nl mag geloven.

Mijn voorlopige conclusie is dus dat je eigen mailserver klopt, maar het ophalen van het DNS record faalt op je eigen PC en die van de externe mailserver. Maar ik kan er nog niet helemaal de vinger opleggen waarbij dit precies fout gaat...

EDIT: Het lijkt er bij mij op dat unbound (in recursive mode) moeite heeft met de signature valideren van het gehele record. Ik zie dat dit misgaat vanaf _h.mailer1.belastingdienst.nl._o.belastingdienst.nl._spf.belastingdienst.nl, dan komen er enkele No DS RRset meldingen in de log achteraan. Dit lijkt niet te spelen bij bijvoorbeeld Cloudflare, dus als je eigen mailserver daar zijn records vandaan haalt gaat het goed (ook als ik zelf met dig of kdig de records valideer).

EDIT2: De oorzaak lijkt te liggen in het feit dat unbound standaard lokale (RFC1918) IP adressen filtert. Dit wordt gedaan om DNS rebind attacks te voorkomen en wordt niet standaard gedaan door bijvoorbeeld Cloudflare. De belastingdienst zou dit probleem dus eenvoudig kunnen voorkomen door een publiek IP te kiezen, want het is een beetje veel gevraagd van de rest van het internet om een uitzondering te maken voor rebind attacks onder hun domein. In mijn unbound kon ik dit bevestigen door 'private-domain: belastingdienst.nl' toe te voegen, daarna kreeg ik het 127.0.0.1 IP terug zoals de bedoeling is.

Op zich al bijzonder dat de mail binnenkomt bij -all. Bij mij wordt die terecht aan de poort geweigerd want spf fail. Dmarc houdt dat inderdaad bij. Wel lekker rustig. ;)

Ik denk overigens dat je interpretatie onjuist is.


_i.%{i}._h.%{h}._o.%{o}._spf.belastingdienst.nl
Voorbeeld : _i.192.0.2.3._h.esp.example.com._o.email.example.com._spf.belastingdienst.nl
%{i}
Het IP adres van de verzender (Voorbeeld : 192.0.2.3 )
%{h}
HELO/ELHO van de ontvanger (Voorbeeld : esp.example.com )
%{o}
Het domein van het verzendende adrese (na het @) (Voorbeeld : email.example.com )

Inclusief typ/taalfouten van https://www.dmarcanalyzer.com/nl/spf-2/checker/?dmarcdns%5Btype%5D=spf&dmarcdns%5Bdomain%5D=belastingdienst.nl&g-recaptcha-response=03AGdBq26xSLNo4JqgEb7TuxymeY2w91m4Fhcp5krVmU7Wosz3qYIhJElI31i2HfBqY2lP8vvsyrvsLo0fuSXCvqwko8MpqrhxrGkvGvrjcRQBc33HLYYBE-26knbV6G0wPRSMDFdYku0oRLs2gmwgVXh5IxcKdgmMM3JeP6c4pQOsMFrsGeY5dYoldqhIpoynYne7KjziTJXcdxec0R1D2FXB2v03oZAPBfyNHSwfGQktaPiA5CC_tpUwapcTHjXjpDEz0YrObyGOGOkN9nuhP-_HI3O9jAfV7zKVZ-09aYH4nh-RW3cCSO7IRqmJ5SywNivX8RoJEaLpG6Io_Dt-zYOy8efnPC6wbS6FGZ5H33z9vviiEM-tTS6Ie__KWdicR4KbvJG5I7TXn9GYn9yXDfyDN0CS5HWwzw


er wordt dus aangegeven wat de toegestane ip adressen zijn,
hoe het HELO/EHLO veld er uit ziet
en wat het verzendende domein is (belastingdienst.nl)

Je mag dat niet als 1 string voor een dns lookup zien. De vraag is of jouw spf/dkim/dmarc checker en email klant al in staat is om dit te gebruiken.

Is dit wel een mail van de belastingdienst?

Mits DMARC gebruikt wordt?

Op dit moment krijg ik 127.0.0.1 voor de lookup van
Deze kun je voor jezelf proberen:

NXDOMAIN checks zijn niet erg betrouwbaar. Ten eerste is NXDOMAIN is de standaard return (terecht of niet) bij veel DNS gerelateerde problemen. Ten tweede zijn er DNS servers die lookups met resultaat NXDOMAIN wijzigen naar een IP adres. Mijn advies aan de Belastingdienst zou zijn dit niet zo te doen aan de serverzijde.

Als je systeem SERVFAIL opvat als "bestaat niet" (c.q. NXDOMAIN) is dat een clientfout.

Voor het geval mijn conclusie verdwijnt tussen de rest: Sommige van je DNS resolvers bieden bescherming tegen DNS rebind attacks waardoor ze het record filteren.

Er is dus wel een record aanwezig en je eigen mailserver gaat hier goed mee om, omdat deze niet beschermd is. Het probleem is dus DNS (dat is het altijd) maar de fout ligt bij de belastingdienst die geen 127.0.0.1 adres moet invullen (al hoewel dat volgens de SPF standaard wel toegestaan is).

Ik wist het ook niet, maar na even zoeken zie ik:
https://duo.com/labs/tech-notes/detecting-phishing-with-spf-macros (bevat nog meer nuttige informatie!)

Je schrijft: Wat doet dat vraagteken daarachter?
Het is waarschijnlijk veroorzaakt doordat het voor controle was gestuurd naar de DNS server die hier geen oordeel over had.
(DNS servers vertalen een url naar bijbehorend IP en niet andersom. daarom als je een IP als 85.159.96.4 naar een DNS server stuurt ter beoordeling, dan krijg je in dit geval een vorm van ? als respons, ten teken van "wat moet ik hier in vresdesnaam mee?".
Net zoiets als Erik v S zou doen. En zoals wel vaker zit jij dan opeens ook met een ?.
Zo van "He? Wat moet ik nou weer met een ?" (tenminste als het je al op zou vallen).

En als je dan toch verder stug door blijft werken met die "?", ontstaan er bij jezelf steeds meer ?????.
Oftewel: hoe kan dit? wat is dit? Waar slaat dat op? Zou het misschien...? etc.
Een heel bekend fenomeen. (vooral als je Erik v S kent. Prima kerel hoor, maar soms...)
Dus wat je in zo'n geval het beste kan doen is die "?" negeren en even te doen alsof ie niet bestaat.
Dan kom je namelijk weer "on track".

Dus niet verder werken met:
maar met:
en de lucht wordt weer helemaal helder.

Hier zit alles OK:
https://dnssec-debugger.verisignlabs.com/_i.85.159.96.4._h.mailer1.belastingdienst.nl._o.belastingdienst.nl._spf.belastingdienst.nl
Second opinion met 1 waarschuwing, zie
https://dnsviz.net/d/_i.85.159.96.4._h.mailer1.belastingdienst.nl._o.belastingdienst.nl._spf.belastingdienst.nl/dnssec/

J.O.

Ik laat deze maar even achter :)

https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/standaard_functies/prive/contact/fraude_misdaad_en_misstanden_melden/beheerders-mailservers

Je hebt gelijk met dat vraagteken. In mijn bronbestand staat geen vraagteken maar als ik het in de terminal plak (en ook hier) verschijnt dat vraagteken. Dat had ik gemist. Dank voor het erop wijzen.

Ik krijg nu inderdaad een 127.0.0.1 terug via het host command. De fout zit dus bij mijn externe mailprovider die struikelt over deze macro. Ik zal ze er morgen eens op wijzen.

Een vraagteken betekent vaak een karakter dat niet kan worden getoond in een bepaalde karakterset. In dit geval kan het off-by-one read van een variabele zijn, bijvoorbeeld een NUL karakter aan het einde van een string. Het programma had in dat geval moeten stoppen met lezen op het moment dat een NUL werd aangetroffen. Die NUL mag niet in output verschijnen.

Verkeerd gebruik van de lengte van variabelen kan exploits faciliteren.

Leerzaam. Dit is dus een spoofing detectie door de domeineigenaar die ook werkt zonder DMARC bij de ontvanger. Door de macro dwingen ze alle ontvangende mailservers het enveloppe adres naar de dns server van domeineigenaar te sturen.
Dan moet je wel en dns server hebben dit logt, maar dat zal de belastingdienst dan wel doen.

De syntax voor macro's heb ik gisteren gehaald op http://www.open-spf.org/ De oude site "www.openspf.org" is al een jaar uit de lucht, maar deze site heeft alles exact overgenomen. In jouw link wordt het iets gemakkelijk leesbaar uitgelegd.

Ik vermoed dat ze macro's niet kunnen parsen. Weet je welke smtp server dit bericht bij jouw externe mailprovider ontvangt?

Heeft dat vraagteken niet iets te maken met hetgeen RFC7208 omschrijft over "qualifiers"?
De mogelijke qualifiers zijn (zie paragraaf 4.6.2 van https://tools.ietf.org/html/rfc7208 ):

Zie ook paragraaf 2.6.2. en paragraaf 8.2 over "neutral".

Je schreef in topic:
Daar zit aan het einde het vraagteken bij inbegrepen.
Kunnen we hieruit concluderen dat het vraagteken iets te maken heeft met dit IP-adres?
(neutral respons op een controle van het IP-adres?)

Onderzoek het eens aan de hand van YARA regels:
https://github.com/Yara-Rules/rules/tree/master/email

Ook een Zonemaster DNS check gedaan.

De domein eigenaar publiceert een speciaal geformateerd TXT record in de DNS zone
met een lijst van geautoriseerde servers.

Zie: https://www.zonemaster.net/domain_check (domeinnaam query = belastindienst.nl)

ADDRESS WARNING Nameserver ns4.belastingdienst.nl has an IP address (147.181.112.4) without PTR configured.
Idem: Nameserver ns5.belastingdienst.nl has an IP address (2a01:380:1602:500::250) without PTR configured.

DELEGATION ERROR Child does not list enough (1) nameservers (ns5.belastingdienst.nl) that resolve to IPv6 addresses (2a01:380:1602:500::250). Lower limit set to 2.

DELEGATION NOTICE Delegation lists no nameserver that resolves to an IPv6 address. If any were present, the minimum allowed would be 2.

DELEGATION NOTICE Child has nameserver(s) not listed at parent (ns5.belastingdienst.nl).

ZONE NOTICE SOA 'retry' value (1440) is less than the recommended minimum (3600).

luntrus

Dat is nifty dus als ik het goed begrijp verschijnt mijn cliënt ip adres bij de belastingdienst in de dns log wanneer ik e-mail namens een van de domeinen van de belastingdienst spoof? En bijna niemand anders gebruikt deze methode?

Nee, dat is de -all aan het eind.

Het IP adres van de verzendende mailserver, dat hoeft dus niet gelijk te zijn aan die van de computer waar je de mail vandaan verstuurd. Anoniem@15:29 linkte naar een blogpost van Duo (authenticatie dienst) die hier ook gebruik van maakt, het lijkt dus niet alleen de belastingdienst te zijn. Genoemde voordeel ten opzichte van DMARC reports, die hier voor bedoeld zijn, is dat het ook werkt als die reports niet verstuurd worden. Het is dus wel een niche toepassing en alleen bedoeld voor die gevallen waar geen reports verstuurd worden, anders lijkt een uitgebreider DMARC report mij de voorkeur hebben.

Dat begrijp je inderdaad niet goed.

Als jouw smtp server aan spf/dkim/dmarc doet dan kan die een dns lookup doen en zal dat eventueel in de dns logs verschijnen. De kans dat dat wordt gelogd is bijzonder klein want het levert vreselijk veel data.
Jij haalt je mail op bij je email provider en jouw adres wordt dus niet gelogd bij de dns provider van de belastingdienst, tenzij je alles thuis draait.

Nee. Het IP dat in het log verschijnt is het IP van de mailserver die beweerd mail te versturen namens 'belastingdienst.nl'. In het log komt vooral het IP van hun eigen mailserver te staan. Verschijnt er een ander IP, dan is dat direct verdacht.

Echter, zijn er ook veel mailprogramma's die mail forwarden met behoud van de originele afzender. Die komen ook allen in het log. Maar dat zijn niet de IP adressen van de privé personen, maar van de smpt server van hun provider. (tenzij de privé persoon een eigen mailserver heeft draaien). Deze IP adressen van de versturende smtp server krijgt de domeineigenaar ook altijd al dagelijks toegestuurd van de grotere mailproviders als hij DMARC gebruikt.

Nadeel van deze dns methode is dat je niet direct door hebt hoeveel verkeerde mailtjes verstuurd worden omdat dns verkeer gecached wordt. Als de dns server van google, bij een phishing campage, 10000 van deze domeinen in een uur moet opvragen, zal dat maar 1x bij de belastingdienst opgevraagd worden. De 9999 volgende haalt google uit zijn eigen cache. Hetzelfde geldt voor andere dns servers die dit domein moeten opvragen.


Nee, ik kan niet uit de mailheader halen welk type mailsoftware ze gebruiken. (de smtp-server zit op mail2.dataweb.nl") Ik weet wel dat mail een bijzaak voor hen is en dat ze steeds een beetje achter lopen. dmarc controleren ze ook niet.

Dat bedoelde Anoniem niet. En @08:34 door Anoniem: nog niet helemaal.

Stel: je draait je eigen mail server. Dan gaat die de SPF (DNS TXT) lookup uitvoeren als er een SPF controle plaatsvindt. Meestal wordt een resolver (name server) ingesteld van de internetprovider op deze server. Dat IP adres (en dus niet je eigen IP adres) is bekend aan de name server van de Belastingdienst. Lookups kunnen worden gelogd en het ligt voor de hand dat de Belastingdienst dat ook doet voor in ieder geval de A-query lookups van de virtuele spf hosts.

Zoveel lookups zijn er nu ook weer niet, het kan worden gelogd.

@08:34 door Anoniem: Misschien denk je aan het loggen van queries aan een resolver bij een grote provider. Dat zijn grote aantallen. Maar zelfs dan wordt er nog wel gelogd. Sommige DNS blacklists bijvoorbeeld hebben een aanpassing voor Bind zodat blacklist queries kunnen worden gelogd.

Je begrijpt de vraag niet goed! En Briolet die er op reageert ook niet.
Hij zegt "wanneer ik e-mail namens een van de domeinen van de belastingdienst spoof".
Dat betekent: als ik via mijn eigen servers een mail ga sturen die claimt dat die van de belastingdienst komt.
Dan wordt dit mechanisme wel degelijk actief.

En als ze die DNS queries niet zouden loggen dan zou dit hele circus totaal geen zin hebben dus neem maar van
me aan dat ze dat wel doen, ook al komt er naar jouw idee een onbehapbare hoeveelheid data uit.
(ik neem aan dat ze wel een zodanig slimme DNS server draaien dat ze queries voor het _spf.belastingdienst.nl subdomein
apart kunnen loggen, maar zelfs als dat niet zo is dan kunnen ze die logs nog filteren op dat subdomein)

Inderdaad dat denk ik ook. Ik zag meteen dat vraagteken en dacht daar ook aan, maar ik heb het bij eigen checks
zelf al weggelaten omdat ik ook nog even dacht dat hij wellicht wilde aangeven dat hij onzeker was over dit adres.
Maar jouw conclusie mbt de NUL ( \0 ) is denk ik correct, er zit ergens een bug in een tool wat ie gebruikt.

Dat van die DNS rebind protection (in een andere reactie) is echter ook een goede, zo zie je maar hoe link het is om dat
soort filters te installeren, dat kan een hoop dingen op een totaal raadselachtige manier kapot maken.

Het IP van de recursieve DNS zal (ook) in de logs te zien zijn, maar dat is niet het punt hier. Als je kijkt naar de SPF macro dan zal de ontvangende mailserver hierin het IP adres opnemen van de verzendende mailserver (die het te zien krijgt bij het opzetten van de verbinding). Bij de belastingdienst zal dus in de query het IP adres te zien zijn van de verzendende mailserver; en dus niet (alleen) waar de query afkomstig van is, dat is het IP van de recursive DNS server zoals je hier lijkt te schrijven. Als je zelf de mailserver draait zal dus uiteindelijk de belastingdienst het IP adres zien van jou mailserver, naast het IP van de recursieve DNS server van de ontvangende partij die query verstuurd.


Daar ben ik het niet helemaal mee eens. Ja het is filtering die iets kapot kan maken, echter had de belastingdienst hier beter over moeten nadenken. Het is bovendien nergens voor nodig, als ze gewoon hetzelfde IP adres terug geven (daar waar ze nu 127.0.0.1 terug geven) is er niks aan de hand. Vergeet ook niet dat dit lastig te vinden is maar wel degelijk bij default aan kan staan.

Het gaat om het IP adres van de mail server die het bericht stuurt over Internet naar de MX mail server. Dat zouden IP adressen van de mail servers van de Belastingdienst moeten zijn.

De Belastingdienst zal zien welk IP adres wordt opgevraagd in de SPF A record query. De Belastingdienst zal dus vooral zijn eigen IP nummers zien in die queries. In de gevallen waar dat niet zo is, is er iets mis. Oorzaken kunnen zijn: IP adressen die geen mail voor de Belastingdienst mogen bezorgen over Internet of een verkeerde configuratie van een mail server/SPF check tool.

De Belastingdienst ziet via de SPF A record query geen persoonlijk IP als je een resolver van je provider gebruikt. Het IP van de requester kan worden gelogd, maar dat is het IP adres van de resolver. Als je je eigen resolver draait is dat gelijk aan het IP adres van de mail server. Dat zal in de praktijk zelden het geval zijn.

Iedereen die denkt dat hier een fout gemaakt is, dit is incorrect.

De Belastingdienst maakt gebruik van SPF macro's om zo informatie te verzamelen over mailservers die email forwarden en of het domein van de belastingdienst misbruiken.

Dit is uitgelegd in een eerdere presentatie op Blackhat 2019: https://i.blackhat.com/USA-19/Thursday/us-19-Hoelzel-How-To-Detect-That-Your-Domains-Are-Being-Abused-For-Phishing-By-Using-DNS.pdf

Je veronderstelt hier een soort "superieure kennis van alle issues die mogelijk kunnen spelen" bij iedere beheerder van
ieder systeem op internet. Ga er maar vanuit dat dat niet zo is. Bij iedere beslissing die je neemt kun je niet alle mogelijke
consequenties overzien, en het retourneren van 127.0.0.1 of 127.0.0.2 op een DNS query is heel normaal in dit soort
situaties, "er over nadenken hoe dat eventueel mis kan gaan" dat is zeker niet de taak van de belastingdienst.

In feite is het zo dat degene die "DNS rebind protection" verzint degene is die moet nadenken over de gevolgen van
dat soort filtering, niet degene (in dit geval de belastingdienst) die iets met DNS oplost.

De volgende keer is er iemand die domeinnamen met meer dan X levels blokkeert om een of andere vage reden, en
dan werkt dit systeem ook niet meer "en had de belastingdienst daar over moeten nadenken" in jouw opinie.
Zo werkt dat natuurlijk niet. Wie het internet kapot maakt moet daar zelf over nadenken, niet maar aanemen dat
iedereen weet dat het kapot gemaakt is en daar maar "over moet nadenken".

https://support.openprovider.eu/hc/en-us/articles/360000317007-How-do-I-create-an-SPF-Sender-Policy-Framework-DNS-record- An excellent example of use of those macros is the Dutch tax authority. Their SPF record looks as follows:

Belastingdienst doet nu zelf heel veel automatiseringsdingen die voorheen door logius gedaan werden. Dat kan ook diverse issues opleveren..

Het doel is duidelijk maar de methode is niet trefzeker en kan false positives veroorzaken. Zoals hier ook het geval is, al werd die fout in het geval van de TS elders gemaakt, je moet onder ogen zien dat de NXDOMAIN methode inherent niet betrouwbaar zal zijn. Zoals ik in dit bericht schreef: Gisteren, 13:43 door Anoniem.

Daar begon Briolet toch ook mee:
"v=spf1 exists:_i.%{i}._h.%{h}._o.%{o}._spf.belastingdienst.nl -all" (zie topic)

En vervolgens
En dan zou je toch zeggen dat het niet toevallig is dat het roet-in-het-eten-gooiende vraagteken hier achter het IP-adres staat.
Of toch wel?
Er moet een reden zijn voor dat vraagteken hier achter het IP-adres.

That's the question.

Er is wel degelijk een fout gemaakt door te kiezen voor een RFC1918 adres in de A record. Dit geeft problemen bij DNS resolvers die bescherming bieden tegen rebinding attacks.

@ Anoniem 12:59
De DNS rebind bescherming staat standaard ingeschakeld bij unbound en volgens mij ook al voordat de belastingdienst gebruik maakte van deze SPF macro's. Vanuit dat opzicht is het dus wel degelijk de belastingdienst die hun eigen uitgaande mail om zeep helpt. Dat ze dit niet hadden voorzien kan ik begrijpen. Maar dat is het risico van gebruik maken van een feature die door een miniem aantal mensen gebruikt wordt.

Dat vraagteken was inderdaad het probleem bij de handmatige test, maar had niets met de dns te maken. Bij het kopieren van het IP uit mijn mailheader is een 'non-printing' karakter meegekomen naar mijn tekstverwerker. In de tekstverwerker had ik het hele domein opgebouwd uit de macro en gecontroleerd. Via de tekstverwerker had ik ook mijn startpost gemaakt. Daar was nooit een vraagteken te zien.

Pas bij het plakken achter het host commando, in mijn terminal verscheen hij maar dat was me niet opgevallen. Ik had alleen het eerste en laatste karakter gecontroleerd om te zien of ik de hele string wel had. En de controle op syntaxfouten deed ik steeds in de versie van de tekstverwerker. Ik mag blij zijn dat de forumsoftware er ook een vraagteken van gemaakt heeft en het karakter niet gewoon weggelaten heeft, zodat het anderen nu direct opviel.

Bedankt voor dit zeer heldere antwoord.

127.0.0.1 is geen RFC1918 adres!

Dat is precies wat ik bedoel: wie gebruikt er nou "unbound"? En waarom moet de belastingdienst rekening houden met gebruikers van unbound? Laten die hun eigen problemen oplossen!!
Het is kierewiet om dergelijke functionaliteit in een recursive resolver onder te brengen. Daarmee maak je het internet kapot. Net als die resolvers die ipv een NXDOMAIN altijd een vast IP adres retourneren wat dan het adres is waarop een of andere informatieve reclame-achtige pagina gehost wordt (zoals bepaalde ISP's doen). Gewoon NIET DOEN dat soort dingen.

Als je dit soort filtering wilt doen, doe het dan in een resolver library (de library die je DNS lookups voor een programma doet) met de optie voor een programma om die protectie wel of niet te hebben. Met de mogelijkheid voor de beheerder dat te configureren per programma, bijv default aan maar niet voor mail server/spamchecker software.
Zodat het wel werkt voor een browser ofzo, maar niet zomaar voor alle software die gewoon werkende DNS lookups nodig heeft zonder dit soort fratsen.

@ Vandaag, 18:59 door Anoniem

Negeren van de werkelijkheid om ons heen is geen optie. De Belastindienst zal zich moeten bezinnen of het deze methode door wil zetten ten koste van false positives.

Overigens past de Belastingdienst ook andere blokkeermethode(s) toe die leiden tot false positives in toegang weigeren tot de website. Je moet geen methoden gebruiken die false positives veroorzaken.

false positive = onterechte detectie
false negative = gemiste detectie

Dat is belangrijker dan een false negative. De bedenkers van deze methoden maken een stadium door die er al lang is geweest is in anti-spam meer dan 10 jaar geleden. De fout is makkelijk te herkennen door het gebruik/misbruik van het woord "balance" tussen false positives en false negatives. Dat duidt op een verkeerd begrip, uiteindelijk is zo'n false positive een denial-of-service die je zelf pleegt op je eigen diensten. Maak van het middel geen doel en voorkom false positives.

false positives zullen ze hoe dan ook veel krijgen.

Wij sturen regelmatig mailings naar ca 500 adressen. Hierop krijgen we via DMARC ca 25 SPF failures terug. Dat is 5% van de verzonden mail, die een detectie zal geven bij de methode van de belastingdienst.

De spf failures ontstaan doordat de klanten een domein registreren voor hun bedrijf met een mailadres erbij. Blijkbaar willen ze de mail ook op een ander mailadres hebben en forwarden het ernaar toe. Bij het forwarden gaat het mis omdat hun provider de mail forward, met de originele afzender. Die mailprovider is dus zelf de afzendernaam aan het spoofen bij elke forward.

De belastingdienst zal er dus nog een uitgebreide analyse over moeten gooien om er de spoofers met kwade bedoelingen uit te filteren.

Gaarne uitleg wat hier fout aan zou zijn:
https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/standaard_functies/prive/contact/fraude_misdaad_en_misstanden_melden/beheerders-mailservers{/url]

De standaardsituatie is tegenwoordig "een mail account bij gmail". Daar moet alles uiteindelijk terecht komen.

Dus als je een bedrijf hebt met de naam example.nl dan stuur je via die domeinregistrant alle mail voor *@example.nl
door naar example-nl@gmail.com. Dit is de goedkope manier en "het werkt", maar niet zonder problemen inderdaad.
(je kunt ook je mail hosting op domeinnaam bij gmail regelen en dan in het geregistreerde domein de MX servers van
google opnemen maar dan gaat het wel weer meer kosten en dat willen we natuurlijk niet!)

Daarnaast komt het ook heel vaak voor dat medewerkers van bedrijven (en ministers enzo) die onhandige bedrijfsmail
dienst met 2nd factor en andere onhandige zooi "kaltstellen" door een rule aan te maken die alle mail doorstuurt naar
hun gmail account. Dan kunnen ze er tenminste gemakkelijk bij.
Dan is er ook weer het risico dat het zodanig geforward wordt dat de SPF mis gaat.

Je kunt mail toch al niet meer gebruiken voor communicatie die "altijd moet werken", dwz die niet zonder zichtbare
technische defecten ("computer kapot") stilletjes mis gaat. Daarvoor is er teveel aan kapot gemaakt, gemotiveerd
door misbruikers (spammers en oplichters). Het kind is met het badwater weggegooid: als je communicatie er uit
bestaat dat er een bericht van A naar B gaat en A dan redelijkerwijs kan aannemen dat B het ontvangen heeft, zeg
maar zoals bij een brief, dan is e-mail niet meer geschikt. Er wordt best wel eens een brief niet bezorgd, maar in
vergelijking daarmee is e-mail een stapje erger: daar wordt gewoon een gedeelte niet bezorgd omdat het door een
partij onderweg "afgekeurd" is. Er zullen niet veel postbodes zijn die een brief weggooien omdat de kleur van de
envelop of de postzegel hen niet aanstaat, maar bij e-mail is dat heel normaal geworden.

Niets. Blijkbaar gebruiken ze deze macro al sinds november 2018. (dank voor het zoeken) Dan gaat het bij onze externe mailprovider nu fout omdat ze recentelijk zelf iets veranderd hebben in hun mailserver. Wij krijgen maandelijks mailtjes voor herinnering loonaangifte, bevestiging aangifte etc. Tot nu toe probleemloos.

Op zich vat het wel mee, maar bijna iedereen die een brief post, weet wat de essentiële onderdelen zijn. (genoeg porto, goede adres, afmeting niet te klein of te groot). Bij mail is dat anders. De meeste mensen kennen de regels niet en vertrouwen hiervoor op hun software. Alleen veranderen de regels soms (net als bij de echte post ), maar ze blijven software gebruiken die de nieuwe regels nog niet kent.

Als ze daar niets veranderd hebben en jij hebt niets veranderd dan moet er in het tussendeel iets gebeurd zijn.
Het is een kwestie van mogelijkheden verzinnen en gaan afvinken.

Wat me opviel (onderaan) is dat ze de controles / checks kunnen zien en ook zien dat er nogal eens wat fout gaat aan de andere kant. Dat moet een volledige call back zijn. Ik kan ook nog een presentatie uit 2015 van ze tegen.
Ik zit er te weinig in, ze zijn er wel al lang mee bezig op een gedegen manier. Niet het eenvoudigste wat ze doen.

Ik kreeg net antwoord van onze externe mail provider.


Het probleem zit dus in hun Barracuda spamfilter. Andere providers met dit pakket zullen dan hetzelfde probleem hebben.

De belastingdienst maakt ook gebruik van DKIM en DMARC...
Op mijn server geeft de SPF check TMPFAIL, waarschijnlijk door die macro, maar DKIM klopt wel en daardoor dus ook DMARC.
Ik begrijp dan ook niet waarom de mail dan door jouw externe provider als spam wordt gezien...

--
Anoniem 21-05-2020, 12:34

De SPF test kan meerdere keren gebeuren op de server. Op onze server gebeurd het volgens mij 3x. Eerst postfix zelf die een SPF test doet op het enveloppe adres. Daarna de DMARC module die de test overdoet, maar dan met het zichtbare afzend-adres. Verder draait bij mij het spamassassin pakket, die ook nog een SPF check doet. (Beetje inefficiënt natuurlijk, maar dat komt omdat alles in losse modules zit)

Bij onze externe provider wordt een soft-fail op het enveloppe adres alleen voor de spamscore gebruikt. Bij een hard-fail instelling wordt de mail niet geweigerd, maar altijd als spam aangemerkt. Naar DMARC wordt bij hen niet gekeken. (In elk geval niet iets in de header weggeschreven).
Formeel moet een SPF record met een syntax error behandeld worden als een afwezige record. Als zij die macro niet goed kunnen interpreteren, zouden ze dat voor mijn gevoel moeten afhandelen als een syntax error. Maar goed, we zullen zien. De mail komt gelukkig wel binnen en ik weet dat die waarschuwing onterecht is.

Op onze eigen server wordt mail met een hard-fail op het enveloppe adres altijd geweigerd. Ik heb het nooit getest, maar verwacht niet dat hij de DKIM en DMARC tests na een fail in de eerste module toch nog gaat doen. Dus ook hier verwacht ik een bounce als DMARC op zich wel goed zou zijn, maar er al een hard-fail op het enveloppe adres optreed.

Ahh... Barracuda. Nou dan help ik je hopen! Dit bedrijf staat bekend om het slechte onderhoud.
Het beste wat je met een Barracuda kunt doen is in de container gooien. Maar ja als die niet van jezelf is,
dan wordt dat lastiger natuurlijk.