Bekijk Volledige Versie : DMARC, DKIM en SPF uitschakelen op verzoek van adminstratiesysteem
Pepperfield
28/07/18, 09:06
Een klant van ons gebruikt een online facturatiesysteem. Dat systeem verstuurt facturen uit naam van de klant en gebruikt daarbij de domeinnaam van de klant als afzender. Deze emails belanden bij veel eindklanten in de Spambox.
De oplossing die de leverancier van het facturatiesysteem voorstelt, is om DMARC, DKIM en SPF uit te schakelen.
Hoe kijken jullie hier tegenaan?
CharlieRoot
28/07/18, 10:54
Een klant van ons gebruikt een online facturatiesysteem. Dat systeem verstuurt facturen uit naam van de klant en gebruikt daarbij de domeinnaam van de klant als afzender. Deze emails belanden bij veel eindklanten in de Spambox.
De oplossing die de leverancier van het facturatiesysteem voorstelt, is om DMARC, DKIM en SPF uit te schakelen.
Hoe kijken jullie hier tegenaan?Wat een onzin, uitschakelen is geen optie. Laat ze een relay host optie toevoegen zodat het via de juiste SMTP naar buiten gaat?
systemdeveloper
28/07/18, 12:32
Zo krijgt ie zijn facturen wel netjes 'gearchiveerd' bij zijn klanten.
Voor de rest: wat BOFH hierboven zegt :)
Laat ze een relay host optie toevoegen zodat het via de juiste SMTP naar buiten gaat?
Mijn inziens niet de beste optie. Je hebt immers geen volledige controle over welke emails dan door die leverancier verstuurd worden over die juiste SMTP. Voor hetzelfde geld zijn het prutsers en wordt er straks allemaal spam verstuurd door hun waardoor jij weer grotere problemen hebt.
Denk dat mijn voorkeur zou zijn om niet te mailen vanaf het hoofddomein, dus door iets als <facturen@accounting.hoofddomein.nl> te gebruiken en daar aparte rules voor toe te voegen.
Yourwebhoster
28/07/18, 15:38
Om welk administratie systeem gaat het? Ik denk dat je een support medewerker hebt gehad die er niet veel kaas van heeft gegeten. DMARC en DKIM is één ding; maar SPF uitschakelen is al helemaal een no-go.
Mijn inziens niet de beste optie. Je hebt immers geen volledige controle over welke emails dan door die leverancier verstuurd worden over die juiste SMTP. Voor hetzelfde geld zijn het prutsers en wordt er straks allemaal spam verstuurd door hun waardoor jij weer grotere problemen hebt.
Denk dat mijn voorkeur zou zijn om niet te mailen vanaf het hoofddomein, dus door iets als <facturen@accounting.hoofddomein.nl> te gebruiken en daar aparte rules voor toe te voegen.
Prima om dat te scheiden op een subdomein, maar ook dan heb je een probleem als het facturatie systeem echte spam gaat sturen.
Aan de andere kant, als het online facturatie systeem via de juiste SMTP verstuurt kan daar nog steeds uitgaande spam filtering (of anderszins bewaking/volume limitering) op gezet worden.
Op zich is het technisch oplosbaar - het vervelende van al deze maatregelen is dat er steeds meer dingen perfect op elkaar afstemd moeten staan om het geheel te laten werken . En een hoop mensen kiezen voor uitbesteden van zaken juist om ontzorgd te worden van allerlei technische problemen ....
Uitzetten van dmarc/dkim en SPF zou wel echt een stap terug zijn.
Pepperfield
28/07/18, 21:09
Om welk administratie systeem gaat het? Ik denk dat je een support medewerker hebt gehad die er niet veel kaas van heeft gegeten. DMARC en DKIM is één ding; maar SPF uitschakelen is al helemaal een no-go.
Het gaat in deze case om Moneybird.
Pepperfield
28/07/18, 21:12
Prima om dat te scheiden op een subdomein, maar ook dan heb je een probleem als het facturatie systeem echte spam gaat sturen.
De oplossing die we gekozen hebben, is mail versturen via een subdomein van de leverancier. Namelijk klantnaam.leverancier.nl. Geen fraaie oplossing. Voor nu voldoet het.
De oplossing die we gekozen hebben, is mail versturen via een subdomein van de leverancier. Namelijk klantnaam.leverancier.nl. Geen fraaie oplossing. Voor nu voldoet het.
Ah, natuurlijk, dat kan ook prima .
Zolang je het niet heel erg vindt dat zo zichtbaar is dat de facturatie uitbesteed is dit een prima oplossing .
Technisch imo zelfs beter, omdat je nu geen afhankelijkheden hebt tussen twee infrastructuren die apart beheerd worden .
Pepperfield
28/07/18, 21:31
Ah, natuurlijk, dat kan ook prima .
Zolang je het niet heel erg vindt dat zo zichtbaar is dat de facturatie uitbesteed is dit een prima oplossing .
Technisch imo zelfs beter, omdat je nu geen afhankelijkheden hebt tussen twee infrastructuren die apart beheerd worden .
Mee eens. De klant had het liever anders gezien. Ze informeren hun klanten nu vooraf dat de factuur vanaf een specifiek adres wordt verstuurd.
Yourwebhoster
28/07/18, 21:45
Het gaat in deze case om Moneybird.
Voor Moneybird kan je de volgende SPF toevoegen:
include:_spf.moneybird.nl
Als je kijkt op https://www.moneybird.nl/blog/57-bedrijfsnaam-en-e-mail-adres-afzender-instelbaar/ dan verwijzen ze naar een SPF maar die pagina is offline. Daarmee heb je SPF alvast ingesteld maar hoe het zit met dmarc en dkim, dat weet ik niet. Wel apart dat Moneybird niet een degelijke oplossing adviseert.
Op zich is het technisch oplosbaar
Maar dat is precies het punt, dit is eigenlijk geen technisch probleem dus kan je het niet goed oplossen met een technische oplossing. Als je de leverancier via jouw SMTP laat mailen dan ben jij opeens mede-verantwoordelijk voor problemen die ontstaan door hun toedoen. Soms is het gewoon makkelijker om zaken gescheiden te houden zodat je duidelijk en onontkomelijk met een vinger kan wijzen als het mis gaat.
virtuality
29/07/18, 11:55
Als je de leverancier via jouw SMTP laat mailen dan ben jij opeens mede-verantwoordelijk voor problemen die ontstaan door hun toedoen.
Als de leverancier e-mailt met jouw domeinnaam (of subdomein) ben je zoiezo mede-verantwoordelijk. Dan heb ik liever dat ze via mijn spamfilter naar buiten sturen zodat ik er zelf grip op heb en alle SPF, DKIM en DMARC zaken zelf kan regelen.
Maar dat is precies het punt, dit is eigenlijk geen technisch probleem dus kan je het niet goed oplossen met een technische oplossing. Als je de leverancier via jouw SMTP laat mailen dan ben jij opeens mede-verantwoordelijk voor problemen die ontstaan door hun toedoen. Soms is het gewoon makkelijker om zaken gescheiden te houden zodat je duidelijk en onontkomelijk met een vinger kan wijzen als het mis gaat.
Eens met wat virtuality voorgaand zei .
Maar aanvullend:
Kijk, als je als requirement hebt dat jouw facturen met jouw domein verstuurd worden , met behoud van spf/dkim/dmarc - terwijl je een externe partij gebruikt voor facturatie - dan is dat een technisch probleem dat oplosbaar is.
Maar het vergt wel wat coördinatie met de versturende leverancier , en als er problemen zijn is het wat lastiger zoeken dan wanneer het vanuit een apart domein verstuurd wordt. En als er bij één van beide infrastructuren wat wijzigt moet de afhankelijkheid met de andere partij niet vergeten worden.
Maar - gezien vanuit de eindklant - heb ik helemaal niks te maken met vingerwijzen - als er iets niet goed gaat bij de dienst van mijn leverancier, is dat een probleem van mijn leverancier . Hoe die wil vingerwijzen naar _zijn_ leveranciers, onderaannemers,outsourcers, ,interne afdelingen, suppliers is uiteindelijk niet mijn probleem. (privé kan ik dat best interessant vinden , als klant wil ik zeggen "regel het , ik ben _jouw_ klant " ). Of het nu zichtbaar verstuurd wordt door de externe partij of niet.
Ik moet ook zeggen dat ik in de context van *facturatie* de zorgen omtrent spam wel een beetje scheef vindt.
Als je dusdanig twijfelt over de kwaliteit van een partij om hun systemen op orde te houden, dan is facturatie of all things toch wel het laatste om daar te laten afhandelen.
Pepperfield
29/07/18, 20:47
Ik moet ook zeggen dat ik in de context van *facturatie* de zorgen omtrent spam wel een beetje scheef vindt.
Als je dusdanig twijfelt over de kwaliteit van een partij om hun systemen op orde te houden, dan is facturatie of all things toch wel het laatste om daar te laten afhandelen.
Geen idee of ik je goed begrijp. In deze case belanden de facturen van onze klant daadwerkelijk in de spamfilters van hun eindklanten. De reden is dat het gebruikte administratiesysteem emails met facturen verstuurde met het domein van onze klant als afzender.
Geen idee of ik je goed begrijp. In deze case belanden de facturen van onze klant daadwerkelijk in de spamfilters van hun eindklanten. De reden is dat het gebruikte administratiesysteem emails met facturen verstuurde met het domein van onze klant als afzender.
Uh nee, dat is niet wat ik bedoel .
Sommige posters (mn pimlie , en later virtuality) uitten de zorg dat de leverancier "echte" spam via de SMTP server van de klant zou versturen , wanneer de leverancier die SMTP server mag gebruiken om te zorgen dat mails met het domein van de klant ook via de juiste (qua spf/dkim/dmarc) server verstuurd worden.
Hetzij bewust, hetzij omdat het prutsers zijn wier systemen geinfecteerd raken.
Daarop is mijn reactie dus, dat als je zo'n partij niet (eens) vertrouwd om je mailserver te gebruiken je je hard moet afvragen waarom je ze wel met je facturatie vertrouwd.
systemdeveloper
29/07/18, 21:02
Geen idee of ik je goed begrijp. In deze case belanden de facturen van onze klant daadwerkelijk in de spamfilters van hun eindklanten. De reden is dat het gebruikte administratiesysteem emails met facturen verstuurde met het domein van onze klant als afzender.
Dan hoef je toch alleen het spf record van het domein van je klant aan te passen met de mailservers van moneybird? Als jouw klanten een systeem willen dat mail verstuurt onder hun naam via moneybirds eigen servers, hoef je die servers maar op te nemen in je klant zijn spf record. Dkim en dmarc staat er dan los van.
Pepperfield
29/07/18, 21:57
Dan hoef je toch alleen het spf record van het domein van je klant aan te passen met de mailservers van moneybird? Als jouw klanten een systeem willen dat mail verstuurt onder hun naam via moneybirds eigen servers, hoef je die servers maar op te nemen in je klant zijn spf record. Dkim en dmarc staat er dan los van.
Op zich vertrouwd onze klant Moneybird. Moneybird vond het geen optie om hun servers op te nemen in het SPF record van de klant. Kunnen we ze nog voorstellen als mogelijke oplossing.
systemdeveloper
29/07/18, 22:33
Op zich vertrouwd onze klant Moneybird. Moneybird vond het geen optie om hun servers op te nemen in het SPF record van de klant. Kunnen we ze nog voorstellen als mogelijke oplossing.
Geen optie? Daar hebben ze toch niks mee te maken? Je klant gebruikt gewoon (buiten zijn eigen server) een externe server (die van mb) om mail te versturen. Als je klant een domein abc.nl heeft dan hoef je in de dns van dat abc.nl domein alleen de spf aan te passen en MB's servers eraan toe te voegen.
Volgens mij is dit gewoon de gangbare manier en de enige normale optie die je hebt als je mailt via een server waar je zelf geen beheer over hebt en die mail wil versturen met abc.nl als afzender.
Je hebt hier nog het geluk dat je te horen krijgt welke partij (MB) door je klant gebruikt wordt voor uitgaande mail. Vaak genoeg gezien dat klanten dat niet weten of elke mailing zo ongeveer via een andere partij proberen te doen en dan raar op kijken als wij vragen of ze het SPF record bijwerken of de wijzigingen door kunnen geven. Uiteindelijk zijn er klanten waar we het weg hebben moeten halen (helaas). Het weg halen is in mijn ogen ongewenst en we zullen klanten actief moeten informeren voor we het er weer op kunnen krijgen. Gelukkig is dit iets dat je per domeinnaam kunt regelen.
ronaldvanhoeven
31/07/18, 18:03
De omgekeerde wereld ?
Pepperfield
31/07/18, 21:11
We nemen contact op met Moneybird om ze het SPF-scenario uit te leggen. Misschien kunnen ze dat aan hun klanten als optie aanbieden i.p.v. de oplossing om DMARC, DKIM en SPF uit te schakelen.
Yourwebhoster
31/07/18, 22:55
Geen optie? Daar hebben ze toch niks mee te maken? Je klant gebruikt gewoon (buiten zijn eigen server) een externe server (die van mb) om mail te versturen. Als je klant een domein abc.nl heeft dan hoef je in de dns van dat abc.nl domein alleen de spf aan te passen en MB's servers eraan toe te voegen.
Volgens mij is dit gewoon de gangbare manier en de enige normale optie die je hebt als je mailt via een server waar je zelf geen beheer over hebt en die mail wil versturen met abc.nl als afzender.
Als je de SPF wilt instellen dan stel je die natuurlijk in. Maar in dit geval speelt er een ander probleem. Als Moneybird je niet officieel de correct SPF die je er in moet zetten wilt geven en niet op de website heeft staan, dan vraag ik mij af of ze het wel officieel willen blijven ondersteunen of niet. Het advies van Moneybird slaat kant noch wal en ik ben het met Pepperfield eens dat ze hier echt wel duidelijk in moeten zijn. Ik heb de SPF gehaald uit bij SPF records van anderen waarvan ik weet dat ze moneybird gebruiken.
We nemen contact op met Moneybird om ze het SPF-scenario uit te leggen. Misschien kunnen ze dat aan hun klanten als optie aanbieden i.p.v. de oplossing om DMARC, DKIM en SPF uit te schakelen.
Met dat pad snij je wel het gebruik van DMARC/DKIM als mail validatie af , en dat zijn m.i. wel serieus goede opties .
DMARC / DKIM is (heel kort gezegd) een mail header signature, waarvoor de bijbehorende public key via DNS gepubliceerd wordt.
DKIM is de signature, DMARC is de policy wat te doen bij (mis)matches .
Het lijkt me bijzonder onwenselijk om de private key waarmee je mail signed ook op de mailserver van een derde partij te installeren , dus in het scenario waarin de facturatie partij zelf mail blijft sturen met klant-domain als From , kun je dan [lijkt me] geen DKIM gebruiken .
(Misschien kan het wel als je per subdomein keys instelt , en de facturatie partij dan alleen kan signen voor @factuur.klant.nl .)
Het lijkt me wat dat betreft beter dat de facturatie partij gewoon de smtp server van de klant gebruikt voor mail die met de From van die klant verzonden wordt . (dat zou goed instelbaar moeten zijn, aangezien ook al per account kunnen bijhouden welke From gebruikt moet worden ) . Dan kan de smtp server van de klant gewoon alle soorten dmarc/dkim/spf supporten zonder dat de facturatie anders behandeld moet worden.
Pepperfield
02/08/18, 16:24
In het voorgestelde scenario gebruikt de klant de SMTP server van de leverancier, maar dat de klant een SPF record aanmaakt voor de SMTP server. Zoals ook Yourwebhoster hierboven aangeeft.
In het voorgestelde scenario gebruikt de klant de SMTP server van de leverancier, maar dat de klant een SPF record aanmaakt voor de SMTP server. Zoals ook Yourwebhoster hierboven aangeeft.
Om even geen misverstand te hebben wie klant en leverancier is:
In #23 (https://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=23) zegt Yourwebhoster (en systemdeveloper) - Moneybird gebruikt eigen SMTP server, stuurt met domein van de klant als afzender, en de klant zet de Moneybird SMTP server in het SPF record van het domein van de klant.
En dat is het scenario waarvan ik zeg "dan kun je geen DKIM/DMARC meer doen voor het domein van de klant", maar slechts SPF.
systemdeveloper
02/08/18, 23:41
Om even geen misverstand te hebben wie klant en leverancier is:
In #23 (https://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=23) zegt Yourwebhoster (en systemdeveloper) - Moneybird gebruikt eigen SMTP server, stuurt met domein van de klant als afzender, en de klant zet de Moneybird SMTP server in het SPF record van het domein van de klant.
En dat is het scenario waarvan ik zeg "dan kun je geen DKIM/DMARC meer doen voor het domein van de klant", maar slechts SPF.
Dat klopt. Zeer zeker niet de beste manier vanwege de dkim (wat ik in #17 (https://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=17) waarschijnlijk niet duidelijk aangaf). Maar beter dan helemaal niks... maar... MB zegt op hun site dat ze zelf garanderen dat mail op de best mogelijke manier verzonden wordt (2016 update onderaan op https://www.moneybird.nl/blog/146-verbeteringen-aan-e-mail-aflevering/
Blijft beetje wazig dus... óf het gaat helemaal goed... óf niet... :)
stefantriep
23/12/18, 23:47
Heeft iemand inmiddels een goede oplossing hiervoor?
Ik vind het echt stuitend dat Moneybird dit doet in het tijdperk waar SPF, DKIM en DMARC de normaalste veiligheidsmaatregelen zijn van het internet