Via Reddit, samengevat:
Na werkzaamheden aan de meterkast van onze stichting kregen wij een aanmaning, maar nooit een factuur. Die blijkt per post verstuurd, waarop ik vroeg om een kopie per mail om direct te kunnen betalen. Ook die kwam niet aan. Na onderzoek zag ik dat de SPF configuratie en daarmee de DMARC policy van de netbeheerder stelt dat mijn mailserver de berichten (waarschijnlijk van hun kantoorautomatisering) niet mag behandelen. Ik zie waarschijnlijk een auto-responder direct na mijn e-mail, en een poging eerder die ochtend. Dus ik neem nogmaals telefonisch contact op met de netbeheerder. Uiteindelijk bij de debiteuren afdeling uitgekomen met het verzoek: stuur het bericht dan maar naar mijn zakelijke e-mail (gehost op GSuite). Ook daar komt de mail niet aan.Mijn vermoeden is dat de gemailde kopie van de factuur niet is verstuurd vanaf een in de SPF configuratie vermelde mailserver. Vaak komt dat omdat die systemen clouddiensten zijn, dus de mailserver is feitelijk in beheer bij een derde. Maar dat maakt de mail verdacht.
DMARC (Domain-based Message Authentication, Reporting & Conformance) is het beleidsrecord dat de ontvangende server (dus onze vereniging) instrueert wat te doen bij zo’n verdacht. Hier zal er dan (conform best practice) in staan dat de mail moet worden verwijderd.
Dit verklaart ook waarom het bij Gmail ook niet aankomt: Google is zeer streng op correcte SPF/DMARC instellingen en gooit de mail dus ook gewoon weg.
De klassieke opvatting over e-mail is dat het jouw risico als ontvanger is. “Spamfilters zijn jouw keuze”, heet dat dan. En dat was in 2004 ook zo. Maar hier ligt het toch even anders: de afzender heeft zélf die SPF/DMARC configuratie zo ingesteld en zélf de facturen laten versturen vanaf een mailsysteem dat niet in hun configuratie staat als authentiek.
Wat mij betreft mag die mail met factuur dus als niet-verstuurd beschouwd worden.
Opmerkelijk is dan natuurlijk dat de factuur kennelijk ook per post verstuurd was (net als de aanmaning) en ook kwijtgeraakt is. Dat kan gebeuren, maar betekent dat de factuur nooit aangekomen is. Een herinnering is dan prima, maar voor incassokosten is dan vooralsnog geen plek.
Gebruikelijk bij mij is dat je een kopie van de factuur bij de aanmaning krijgt, zodat je alsnog direct kunt betalen.
Arnoud
Als er fouten in configuratie bij de netwerkbeheerder staan waardoor verzonden mail niet aankomt dan zou je toch verwachten dat er meer facturen niet aankomen? Of is hier de pech dat de papieren factuur niet aangekomen is?
Ik vermoed een combinatie van zelden facturen krijgen van netbeheerders als zodanig en dat papier meestal wel aankomt.
Ik zou ook verwachten dat het mailsysteem van de ontvanger een bounce-message zou versturen als een mail vanwege beleidsredenen is geweigerd en niet de mail stilzwijgend laat verdwijnen zonder elk spoor. Dan kan de netbeheerder (of in ieder geval hun afdeling automatisering) er achter komen waarom die mails in een bodemloze put zijn verdwenen. Idem dito als er een bericht staat in de log van één van de mailservers wat er met de mail is gebeurd.
Is ook die bounce-message of dat logbericht er niet, dan kun je prima aannemelijk maken dat er nooit sprake is geweest van een verstuurde mail, want daar is totaal geen bewijs van.
Dat is dus een probleem: dan val je onschuldige postmasters lastig met spam dat niet door hen verstuurd is. Ze hébben al maatregelen genomen (namelijk DMARC/SPF instellen) om malafide mail vanuit hen te voorkomen.
De beheerder van de facturatie-applicatie zou een 550-code moeten hebben gelogd toen de mail werd aangeboden (RFC 7489). Je zou zeggen dat dat opvalt, omdat dat bij iedere uitgaande mail van de klant netbeheerder gebeurt.
Het gebeurt niet bij iedere mail maar alleen als de ontvangende mailserver is geconfigureerd om naar SPF records te kijken.
En dan doe je wel de aanname dat de beheerders van die applicatie ooit in hun logs kijken of er mails zijn geweigerd. Ik denk dat een groot onderdeel van het probleem is dat dat al niet gebeurt en dat de applicatie niet alarm slaat.
Het is niet zeer waarschijnlijk dat de facturatie-applicatie ZELF met alle mailservers op het internet gaat praten; waarschijnlijk is er gewoon een adres ingevuld van een mailserver die dat moet gaan verzorgen.
Het aanbieden van die mail aan die eerste server zal echter voor zover ik weet niet resulteren in een 5xx fout, omdat die mail gewoon succesvol zal worden afgeleverd.
Degene die het moet opvallen is dus denk ik meestal de beheerder van de mailserver en dan wordt het al een stuk lastiger.
En dan is ook nog maar de vraag of de ontvangende mailserver (of de mailserver onderweg) wel logs bijhoudt van berichten die in de prullenbak zijn verdwenen omdat ze niet voldeden aan het antispam-beleid.
Wel grappig dat juist van de (licht)netbeheerder de elektronische mail (ook) niet aankomt.