Dus Namecheap stuurt authenticatiecodes via SendGrid?
Wegwezen daar!

Het is sowieso dom om authenticatiecodes, wachtwoordresetmails via een geshared platform te sturen. Dat sendgrid wordt al door iedereen geblokkeerd.

Nee. Ze komen wel zo nu en dan op een lijst voor. Maar dat zijn de bekende pay-us blokkers.

Volgens NANOG heeft iemand bij Namecheap een rookie fout gemaakt door de eigen DKIM Prive sleutels aan marketing partij te geven in plaats van die eigen sleutels te laten maken.

Die sleutels zijn vervolgens bij de tweede partij gestolen en zijn de mails die door de criminelen worden verstuurd nu dus legitiem…

Waarom?

Hoe zien jullie dit dan precies? Wat is jullie magische oplossing?

Vanuit de meeste cloud diensten kan je niet eens mogelijk om zomaar SMTP mail te versturen.
SMTP server beheer is tegenwoordig ook een vak apart met alle mogelijke technieken of opwarmingen. Waarom zou je hiervoor dus geen dienst afnemen bij een leverancier? Waarom zelf het wiel uitvinden?

Bij sommige public cloud leveranciers kan je hun eigen dienst afnemen, maar geeft meestal hetzelfde probleem, als een shared dienst.

Ik ken trouwens geen enkel bedrijf, ISP of persoon die SendGrid blokkeert voor het ontvangen van mail, redenen is namelijk dat bijna alle grote bedrijven dit soort diensten nemen voor het verzenden van mail.

Niet NameCheap maar Sendgrid lijkt te zijn gehacked, want zo te zien er zijn ook phishing-mails verzonden met als afzenderdomeinen andere klanten van Sendgrid, nl. playable.video en hostirian.com.

Zie https://tweakers.net/nieuws/206598/aanvallers-sturen-authentieke-phishingmails-uit-naam-van-registrar-namecheap.html?showReaction=18458856#r_18458856 voor meer info hierover.

Uitleg over de gebruikte techniek: https://tweakers.net/nieuws/206598/aanvallers-sturen-authentieke-phishingmails-uit-naam-van-registrar-namecheap.html?showReaction=18457990#r_18457990

Zie mijn uitleg uit Nanog. Namecheap heeft ook geblunderd. De berichten zijn ondertekend met de DKIM sleutel van Namecheap, en dat kan alleen als ze die private key hebben.

Dat vind ik geen grote blunder. Organisaties zoals NameCheap huren partijen als Sendgrid in om hen te ontzorgen. Waarom zou je dat half doen, en wat is de winst?

M.b.t. half doen, uit https://docs.sendgrid.com/ui/account-and-settings/dkim-records#automated-security-and-your-dkim-signature:
Bovendien, als je zelf (bijv. NameCheap) gaat DKIM-signeren, loop je een groter risico dat mails uiteindelijk met defecte DKIM signature worden verzonden. Als je het DKIM-signeren aan Sendgrid overlaat, kan die laatste meteen naar believen links via hun klik-telsystemen redirecten zonder dat jij de exacte URL's daarvan hoeft te kennen.

M.b.t. winst: ook bij een DKIM-fail is DMARC happy zolang SPF klopt. Die winst is dus marginaal. NameCheap zal Sendgrid dus sowieso voor een deel van haar klanten moeten vertrouwen. Deels betrouwbaar is onhandig: je vertrouwt een onderaannemer wel of niet (in dat laatste geval zoek je hopelijk een ander).

Kortom, de EERSTE GROTE BLUNDER die bedrijven als NameCheap begaan, is met bij herhaling bewezen onbetrouwbare derde partijen in zee gaan. En de TWEEDE GROTE BLUNDER is, als zo'n derde partij het verkloot - in plaats van mea culpa te zeggen tegen je klanten, beginnen met roepen dat jij er niks aan kan doen "want die derde partij f*cked up".

Als jouw klanten er geen invloed op mogen uitoefenen met welke derde partijen jij in zee gaat, moet je jouw klanten daar ook niet mee vermoeien op het moment dat jouw eerdere keuze stom blijkt te zijn. NameCheap is en blijft hier verantwoordelijk voor, ongeacht welke onderaannemer precies de fout in ging.

Wie is er precies onbetrouwbaar? Sendgrid? Grootste ter wereld? En wat is de bron voor het feit dat ‘sendgrid is gehackt’? Stelletje stuurlui hier altijd

Nu ben je zelf ook aan het blunderen. Van een PKI geef jij ook de root key weg aan een derde partij als je een subordinate in wil richten?

Je geeft hiermee wel heel erg duidelijk aan dat je niet begrijpt wat DKIM doet, en al je bezwaren vallen ineens op hun plaats... Je snapt het niet.


Ga DKIM en DMARC nog maar eens bestuderen. Het verhaaltje dat je van de website plukt klopt dus niet met wat er is gebeurd.

Indertijd hadden we een significante afname van phishing bij een grote instelling, met als gevolg direct significant lagere fraude kosten. Daar kun je niet mee argumenteren. Het leverde geld op. Veel meer dan de investering.

Ook jij zit er wel eens grandioos naast.

Wat is daar precies het probleem aan, volgens jou?
Is dan niet gewoon elke partij die een externe partij om te mailen gebruikt, gmail, ISP, etc. fout bezig?

Absoluut, en meer dan ééns!

Maar niet in dit geval:

1) Aan DMARC heb je niets (je bent phishable) als de legitieme verzendende server (en/of het verzendende e-mail-account) gehacked is, zoals hier gebeurd is (hoe exact weet ik niet, maar het probleem zit bij Sendgrid).

En, tenzij je weet hoe je e-mail-headers moet uitlezen en interpreteren (https://dl.acm.org/doi/10.1145/3415231):

2) Als 1) n.v.t. is: aan DMARC heb je niets (je bent phishable) als de afzender DMARC op de ontvangende server op het verkeerde been weet te zetten, bijvoorbeeld door twee verschillende afzenderdomeinen in het From: veld op te nemen.

3) Als 2) n.v.t. is: aan DMARC heb je niets (je bent phishable) als Microsoft jouw e-mails ontvangt en jij de afzender als "safe sender" hebt aangemerkt, wat automatisch geldt voor contacten waarvan het e-mail adres in jouw adresboek staat. Je hebt ook niets aan DMARC (en SPF en/of DKIM) (je bent phishable) als de ontvangende mailserver van een andere ISP niets checkt of de beheerder ervan vindt dat er andere criteria moeten gelden dan "gebruikelijk" (wat dat ook moge zijn, de meningen zijn verdeeld).

4) Als 3) n.v.t. is: aan DMARC heb je niets (je bent phishable) als de ontvanger het afzenderdomein niet controleert.

5) Als 4) n.v.t. is: aan DMARC heb je niets (je bent phishable) als de ontvanger het afzenderdomein wel bekijkt maar niet weet dat het niet van de gesuggereerde organisatie is.

6) Als 5) n.v.t. is: voor een DMARC-match moet minstens één van de twee, SPF of DKIM, een positief resultaat opleveren. Als SPF klopt mag, voor een DMARC-match, de DKIM handtekening bijvoorbeeld onjuist zijn (of zijn verwijderd door een Attacker in the Middle).

7) Aan DKIM + SPF zonder DMARC heb je niets (je bent phishable).

8) Aan uitsluitend DKIM heb je niets (je bent phishable).

9) Aan uitsluitend SPF heb je niets (je bent phishable).

Ik geloof best dat er een tijdelijk effect geweest is. Ondertussen hacken scammers Sendgrid om dit probleem te omzeilen, of ze gebruiken lijkt-op afzenderdomeinnamen waar SPF, DKIM, DMARC en ARC perfect voor geregeld zijn, of ze gebruiken willekeurige afzenderdomeinen (met SPF etc. kloppend) omdat geen mens nog afzenderdomeinamen ziet laat staan checkt.

Je hebt er niets aan als je wel kunt "bewijzen" dat een e-mail door jouw mailserver is verzonden, maar tegelijkertijd NIET aan ontvangers duidelijk kunt maken dat een e-mail die door jou verzonden lijkt, niet door jou verzonden is.

Je kunt natuurlijk vinden dat dit dan een probleem van de ontvanger is, maar uiteindelijk gaat dit -m.i. terecht- wel te koste van het vertrouwen dat klanten of burgers in jouw organisatie hebben.

Je eigen ip adres komt echt niet zomaar op een blacklist. Dan moet je volume draaien en rommel versturen. Nieuwsbrieven en dat soort rommel moet je versturen via iets als mailchimp, hun netwerken staan ook allemaal op blacklists.

De oplossing is, kies een infrastructuur met weinig volume, en een die zeker niet gratis is.


Ik denk dat jij het beter kunt dan de sendgrids,mailguns,mailchimps. Dit zijn prutsers die niet eens mail servers gebruiken die de standaard hanteren. Dat zijn volgens mij allemaal van die appjes bouwers die denken dat ze alleen maar even een mail delivery hoeven te scripten.


Natuurlijk niet, want in een gedeelde omgeving weet je niet wat je buurman doet. Je eigen infrastructuur wordt nooit geblokkeerd als je volume laag is en je geen spam verstuurd.
Het is juist dom om je normale email via een bulk email systeem te sturen, en tussen de rommel van anderen te gaan zitten.


Iedereen blokkeert/markeert sendgrid check the spamassassin lijst maar. Alleen bedrijven die rommel versturen zijn geforceerd dit soort diensten te outsourcen, zodat ze van een grotere ip range denken te kunnen gebruiken. En dan heb je natuurlijk hele volksstammen, die niet nadenken en daar gewoon tussen gaan zitten, want het is zo lekker makkelijk.

Je mails worden niet afgeleverd als je via een systeem verstuurd waarvan veel spam vandaan komt. Als je dat als internet provider Namecheap niet kan begrijpen, zegt dat wel over hoe het daar gaat.