DMARC, DKIM en SPF uitschakelen op verzoek van adminstratiesysteem

Citaat:

---

Oorspronkelijk geplaatst door Pepperfield

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.

Citaat:

---

Oorspronkelijk geplaatst door Pepperfield

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.

Citaat:

---

Oorspronkelijk geplaatst door systemdeveloper

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.

Citaat:

---

Oorspronkelijk geplaatst door Pepperfield

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.

De omgekeerde wereld ?

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.

Citaat:

---

Oorspronkelijk geplaatst door systemdeveloper

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.

Citaat:

---

Oorspronkelijk geplaatst door Pepperfield

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.

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.

Citaat:

---

Oorspronkelijk geplaatst door Pepperfield

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 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.

Citaat:

---

Oorspronkelijk geplaatst door visser

Om even geen misverstand te hebben wie klant en leverancier is:

In #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 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-ve...il-aflevering/
Blijft beetje wazig dus... óf het gaat helemaal goed... óf niet... :)

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