Google neemt maatregelen tegen spam die van ontvanger afkomstig lijkt te zijn

Google zegt dat het maatregelen heeft genomen tegen Gmail-spam waar een deel van zijn gebruikers recentelijk mee te maken kreeg. In de inbox lijken de e-mails van de ontvanger zelf afkomstig te zijn, terwijl dit in werkelijkheid niet zo is.

Afbeelding via Mashable

Google zegt onder meer tegen 9to5Google dat het beschermingsmaatregelen heeft genomen en dat het verschijnsel te maken heeft met aangepaste headers. Het stelt dat de mensen achter de spamcampagne niet hebben ingebroken op Gmail-accounts. Het bedrijf zegt niet hoeveel gebruikers met het verschijnsel te maken kregen, maar heeft het alleen over 'een klein deel'.

In een thread op het Google-forum melden gebruikers dat de e-mails ook verschijnen in hun map voor verzonden berichten en dat ze ook verstuurd zijn naar andere personen. Een aantal gebruikers merkt op dat de mails verzonden lijken te zijn via de Canadese provider Telus.

Dat bedrijf claimt in een reactie tegenover Mashable dat het op de hoogte is van de spam, maar dat het de berichten niet heeft opgesteld en dat ze ook niet worden verzonden via zijn eigen servers. "We werken met onze leveranciers om het probleem op te lossen en adviseren onze klanten niet op verdachte berichten te antwoorden", luidt de verklaring van het bedrijf verder. De spamberichten blijken verschillende onderwerpen te hebben, zoals verzekeringen, cryptovaluta en leningen.

Een gebruiker op het Google-forum heeft een header uit een dergelijke e-mail gepubliceerd. Op dat forum zeggen gebruikers verder dat het inschakelen van tweetrapsauthenticatie of het veranderen van het wachtwoord geen effect op het verschijnsel had.

Reacties (97)

[MadEgg]

Mail blijft shabby. De grote mailboeren zouden eens actie moeten ondernemen om hier betere stappen in te nemen. Vereisen van SPF en DKIM en DMARC. En valide mailserverconfiguratie, hostnames, reverse DNS etc. Als kleine mailserverbeheerder kan ik nog alles zo goed configureren, zolang gmail en hotmail alle mogelijke troep en misconfiguratie blijven accepteren zit je jezelf alleen maar in de weg.

Zij lijken volledig in te zetten op heuristieken en spamfilters terwijl je alles met een sluitende mailconfiguratie veel beter kunt afdichten, zonder risico op false positives.

Het in dit bericht genoemde fenomeen kom ik al zeker 10 jaar regelmatig tegen. Met SPF en DKIM direct opgelost, maar ja, zolang dat niet vereist is...

[Verwijderd]

Dit kan ik enorm onderschrijven! Het zijn relatief eenvoudige zaken om in te zetten. Het meeste werk zit wellicht het uitzoeken van je SPF-record (wat zou allemaal mogen versturen e.d.), maar niks onoverkomelijk.

En ontvangende email-servers (de spam-filters) dienen gewoon SPF, Sender ID, DMARC, DKIM en PTR te checken.

En hier kun je eenvoudig (en gratis) je mail-config checken: https://internet.nl/mail/
En hier kun je eenvoudig (en gratis) SPF en Sender ID records genereren: https://www.unlocktheinbox.com/

[Reactie gewijzigd door Verwijderd op 23 juli 2024 17:10]

[Verwijderd]

Die beschermen tegen spoofing op SMTP niveau (MAIL FROM: etc...), maar niet tegen MIME-spoofing, wat hier hoogstwaarschijnlijk wordt gebruikt.

Als ik mij niet vergis zet gmail e-mails automatisch in de sent-folder als de MIME "from:" header jouw gmail adres is.

Dit is eigenlijk al een ouder issue: https://productforums.goo...#!topic/gmail/gWKD_YjEszE

Zie de opmerking van Sarah op 4/27/09:

" Thanks to both of you! As Joshua said, messages can appear in Sent Mail if they are "from" your address, even if the header is spoofed. "

[Reactie gewijzigd door Verwijderd op 23 juli 2024 17:10]

[Verwijderd]

Heb voor de lol is gmail in die mail-config checker gegooid.
Komt toch uit dat alles behalve DNSSEC goed is, dan zou google 't toch redelijk voor mekaar hebben toch?

[Verwijderd]

Klopt, Google heeft het best redelijk voor elkaar (alleen DMARC is niet strict genoeg en geen DNSSEC maakt Gmail kwetsbaar voor DNS-poisining), maar dat is ook niet zozeer het punt. Het gaat erom dat wanneer spam-filters sterker checken op de aanwezigheid van die maatregelen, er überhaupt al veel minder spam doorkomt. Maar zoals @MadEgg al zegt, men leunt liever op heuristics.

Ik zou graag beide willen zien.

[sugarcube]

Ik ben hier totaal niet mee akkoord.

Dit was niet echt een "SPAM" probleem, en google filtert SPAM overigens behoorlijk goed.

Veel mensen dachten dat hun gmail account gehacked was en gebruikt werd om SPAM te sturen, en dat kwam door de volgende 2 punten:
1) gmail toont mails met een "from adres" = "eigen adres" als eigen verzonden mails (in de sent folder)
2) een spammer had wellicht een manier gevonden om gemakkelijk spam bij google binnen te krijgen, en plaatste ook in het "from" adres het adres van de bestemmeling.

Hierdoor zagen veel mensen spam mails vertrekken vanuit hun eigen account, en leek het voor veel mensen dat hun account gehackt was. Ook na resetten van de account / aanpassen van wachtwoord bleef men zien dat er spam verstuurt werd van hun eigen account.
Dat was natuurlijk niet zo, het leek alleen maar zo omdat deze mails in de "sent" folder stonden, maar het creerde wel een beetje paniek / nervositeit bij deze mensen, vooraleer de oorzaak duidelijk werd en google deze spam ook ging tegenhouden.

Deze eigenschap van het "from" adres is niet nieuw, en is typisch google waarbij mails niet in een "folder" staan, maar "labels" krijgen.

[MadEgg]

Ik weet dat Google vrij goed spam filter. Dat doen ze op basis van data over binnengekomen mails en wat gebruikers daarover op te merken hebben.

Als je omwille van regelgeving, privacy-overwegingen of andere redenen géén gmail gebruikt maar een je mail verzorgd wordt door een eigen of gedeelde server, heb je daar niets aan natuurlijk. Ook dan zijn er spamfilters die een gooi kunnen doen, maar hebben veel minder gegevens om mee te werken.

Mijn punt is dat spamfilters symptoombestrijding is die voor een groot deel niet nodig zou zijn als afgedwongen wordt dat mailservers juist geconfigureerd zijn. Als je bij het eerste contact tussen de afzender en de mailserver al direct kunt bepalen dat de mail spam is, hoeven er geen algoritmes te draaien en kunnen er minder false positives optreden en ook minder spam ten onrechte doorkomen. Hiermee bestrijdt je de oorzaak van het probleem.

[Verwijderd]

Het probleem is dat er ontzettend veel legacy systemen in de wereld staan die allemaal aangepast moeten worden. Binnen 1 land of tussen bedrijven is dit allemaal wel te realiseren, maar de wereld is groter dan 1 land.

[MadEgg]

Ja, en zolang er geen eisen gesteld worden blijft dat zo. Er moet een stok achter de deur. Als die legacy mailsystemen vanaf morgen geen mail meer kunnen afleveren bij gmail / outlook accounts, moet je eens zien hoe snel die systemen plotseling bijgewerkt kunnen worden.

De servers zelf hoeven niet eens ondersteuning te bieden voor DKIM - je kunt ze altijd mail laten relayen door een server die dat wel doet. IP-adressen aan SPF-records toevoegen is ook geen enkel probleem. Een reverse DNS record instellen is ook geen probleem.

Het is nu gewoon allemaal te straffeloos om de standaard onjuist toe te passen, en zolang dat zo blijft is er weinig motivatie om dat wel te gaan doen.

[fastedje]

Waar ik me nog het meest over verbaas is dat STARTTLS afdwingen volgens deze RFC niet mag: https://www.ietf.org/rfc/rfc3207.txt:
.A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure.

[MadEgg]

Op zich is dat jammer, maar die spec is uit 2002. Logisch dat dat toen niet verplicht was. TLS biedt op zich ook geen enkele garantie qua spam - elke gehackte client kan dat simpelweg toepassen.

Het biedt enkel de garantie dat de communicatie in transit niet onderschept kan worden. Goede zaak als het wél vereist wordt maar tegen spam helpt het niet.

Een bijgewerkte spec voor SMTP zou zeker geen kwaad kunnen - als we nu gewoon met zijn allen afspreken dat TLS, SPF, DKIM, en DMARC verplichte onderdelen zijn kunnen we stappen voorwaarts maken.

[DigitalExorcist]

Moet je vóór Office 365 eens proberen om DKIM in Exchange te integreren. Good luck with that. Dan heb je al 3rd party tooltjes nodig want Exchange snapt dat simpelweg al niet.

[orbit_ph]

Je doet er verstandig aan je DKIM integratie te doen op de MTA die aan de rand van je netwerk staat, welke dus direct communiceert met het internet. Vaak is dit een appliance, maar het kan ook eventueel een Microsoft Exchange Edge Server zijn.

Helaas heeft het geen prioriteit voor Microsoft om DKIM ondersteuning in te bouwen op de on-premise Exchange oplossing. Dan blijven er inderdaad twee Transport Agent plugins over die dit kunnen realiseren.
Of laat het door je mailfilter oplossing doen.

Kleine opmerking, verstuur je via IPv6 mail dan doe je er verstandig aan DKIM in te richten aangezien SPF op IPv6 helemaal een dingetje is.

[wjn]

Ik heb standaard *@gmail.com en *@hotmail.com geblokkeerd.
Kan gelukkig, omdat het bedrijfsmatig is en de meeste klanten een eigen domain hebben.
En auto-whitelist sender aangezet, zodat de gebruiker zelf eenvoudig iemand een mail kan laten sturen.

[the_stickie]

Dat is fijn voor al je potentiële klanten die gmail of hotmail gebruiken

[iAR]

Is het niet gewoon handiger om een e-mail 2.0 te maken?
Al die antispam technieken zijn leuk, maar werken ook niet altijd. Zeker niet voor kleine bedrijven of mensen die er geen verstand van hebben. Ik ontving onlangs een factuur in de spammap, lijkt me niet juist.

[MadEgg]

Is het niet gewoon handiger om een e-mail 2.0 te maken?
Al die antispam technieken zijn leuk, maar werken ook niet altijd. Zeker niet voor kleine bedrijven of mensen die er geen verstand van hebben. Ik ontving onlangs een factuur in de spammap, lijkt me niet juist.

Daarmee onderstreep je mijn punt Spamfilters doen het vaak vrij goed, maar er blijft altijd een onzekerheid inzitten. Je kunt e-mail 2.0 maken en dat niet backwards compatible maken. Daarmee krijg je echter weinig draagvlak. Je kunt ook de bestaande e-mail + SPF + DKIM + DMARC beschouwen als e-mail 2.0 en dat dan ook op korte termijn gaan vereisen. Dan hoeft er véél minder gedaan te worden om draagvlak te creëren, dat is er namelijk al aangezien gelukkig een groot deel van de mailservers de configuratie wél op orde hebben en SPF, DKIM en DMARC juist geconfigureerd hebben.

[efari]

(oprechte vraag, ik ken er niet zoveel van)
Is het niet zo dat SPF, DKIM en DMARC gewoon gebruikt worden ter authenticatie?
Wat houdt een spammer tegen om correct geconfigureerde en geauthenticeerde spammails te sturen? Je hebt dan alsnog een spamfilter nodig om die te onderscheppen.

[MadEgg]

Dat klopt. Het is ook geen volledige vervanging van spamfilters. Je maakt het spammers wel een stuk moeilijker.

Wat je nu vaak ziet zijn gehackte PC's of servers die fungeren als afzender van mails. Die gebruiken dan ofwel de hostname van de machine waar ze op draaien als afzender, ofwel een gefingeerde of onjuiste afzender. Al die gevallen vang je perfect af met de juiste authenticatie middels DKIM en SPF. Bovendien zijn gehackte machines die doorgaans geen mail verzenden ook niet voorzien van de juiste (reverse) DNS configuratie.

Het gevolg is dat spammers domeinnamen moeten registreren en voorzien van een valide SPF- en DKIM-configuratie. Als ~all e.a. niet meer toegestaan worden betekent dat zelfs dat ze alle zendende servers moeten whitelisten via SPF. Daarmee wordt het een stuk grotere uitdaging om spam te versturen. Een correcte DKIM-signature gaat in die opstelling ook niet lukken.

Hiermee vang je zeker niet alle spam af. Ook is vaak zo dat wat wij als spam ervaren is in zekere zin legitiem verstuurde mail door commerciële bedrijven is. We zitten er gewoon niet op te wachten. Die spam zal in de regel ook juist geauthenticeerd en zal daarmee niet tegengehouden worden door SPF of DKIM.

[the_stickie]

Het probleem is dat er ontelbare kleinere spelers nog steeds werken met slecht/miniem geconfigureerde mailservers. De grotere spelers kunnen wel heel strikt zijn, maar dan volgt er sowieso een stortvloed aan klachten waar ze niet op zitten te wachten.
Zoals bij veel zaken is het een evolutie (die gelukkig de goede kant opgaat, getuige jouw terechte opmerking)

[MadEgg]

Die systemen bestaan al vele jaren, dus die evolutie is veel te langzaam. Natuurlijk zal er geklaagd worden, maar dan gebeurt er tenminste wat. Hoeveel PB wordt er ook alweer dagelijks aan spam verstuurd? En hoeveel kost dat? Moet dat allemaal maar geaccepteerd en opgehoest worden omdat er veel kleine partijen zijn die weigeren de boel fatsoenlijk te configureren?

Er zijn voldoende extensies aan mail om het overgrote deel van de spam met 100% zekerheid af te wenden zonder risico op false positives. All it takes is een beetje configuratie door iedereen die een mailserver runt.

[the_stickie]

All it takes is een beetje configuratie door iedereen die een mailserver runt.

Eens, maar de realiteit is dat er echt enorm veel slecht geconfigureerde mailservers (en bijhorende dns) zijn. Ik kan Google (en anderen) niet kwalijk nemen dat ze rekening houden met de realiteit. Ik droom met je mee van een betere wereld, maar we moeten roeien met de riemen die we hebben.

Het lijkt erop dat je het "geklaag" ook onderschat. Dit gaat over duizendtallen support calls van mensen die er geen sikkepit van begrijpen (omdat ze zelf niks met mailservers van doen hebben) en die sowieso Google de schuld gaan geven omwille van "onnodig" restrictief beleid want "gisteren werkte het wel en jullie hebben iets veranderd en nu is het stuk". Dat kost niet alleen een bom geld, maar ook imagoschade. Ik zie de krantenkoppen al voor me

[MadEgg]

Google heeft enkele jaren geleden ook al maatregelen genomen tegen mails die niet via een beveiligde verbinding werden aangeleverd.

Het van de ene op de andere dag blokkeren is wellicht niet wenselijk, maar ze mogen best meer van dit soort stappen doen. Als g-mail wel netjes de mails blijft ontvangen maar voorziet van een grote rode balk die waarschuwt dat de mail niet aan standaarden op gebied van beveiliging en authenticatie voldoet, worden mailserverbeheerders ook meer met de neus op de feiten gedrukt. Dan is het voor gebruikers ook duidelijk dat het probleem niet bij GMail ligt maar de afzender, en zullen de klachten dus ook sneller aan de veroorzaker van het probleem gericht worden. Precies waar ze moeten zijn.

Als er niets geforceerd wordt verandert er ook niets.

[the_stickie]

We verschillen duidelijk van mening
Bedrijven zitten óók niet te wachten op een vingerwijzing van Google hoor: dat levert ook gegarandeerd klachten op. Google (of anderen) hoeven wat mij betreft zich niet te profileren al internetpolitie. Als jij dat wel wil doen, ga je gang!

[MadEgg]

Dat kan

Ik ben ook niet zo zeer voorstander van dat Google de regels bepaald. Ik ben wél voorstander dat er eens wat veranderd aan de lakse houding tov van SMTP-authenticatie. Ik heb zelf een poging gedaan met mijn mailserver. Een tijdje lang heb ik alle geweigerde mails doorlopen en waar het om rechtmatige mail ging (schrikbarend vaak), heb ik contact opgenomen met de organisaties erachter om het probleem aan te kaarten. Een enkeling ondernam hierna actie en heeft het probleem opgelost.

De meesten reageerden helaas in de trant van "het is niet onze fout want de mail komt wel aan bij gmail en outlook, dus we doen er niets aan".

Met mijn mailserver ben ik ergens om een dergelijke stand te maken - het moet echt van de groten komen want anders veranderd er simpelweg niets.

[WillySis]

Dit probleem is zeker niet nieuw. Bij mijn vorige werkgever was dit heel normaal. Soms een paar dagen niet, dan weer meerdere per dag. Het enige verschil is dat ze niet ook nog eens in de outbox terecht komen. Het gros kwam overigens uit Brazilië.
Gelukkig is dit vrij eenvoudig weg te filteren door alle ingekomen mail die je zelf hebt verzonden direct naar de prullenbak te verwijzen. Voor de dataservers die hun status en foutmeldingen per mail naar mij stuurden moest ik wel even een ander mail-adres aanmaken, want die gebruikten ook mijn mail adres om dat soort zaken te versturen. Elke server zijn eigen mail adres laten gebruiken bleek ook nog eens veel overzichtelijker.

Het goed instellen van de mailserver lost helaas niet alle problemen op. Soms maakt het ook dat een deel van de mail onbedoeld buiten te deur wordt gehouden. Voor een groot deel is die mail afkomstig van servers die zelf niet goed ingesteld staan.

Wil je meer weten over instellingen van de mail server, lees dan eens deze artikelen https://blog.networking4all.com/?s=E-mail+beveiliging

[MadEgg]

Het goed instellen van de mailserver lost helaas niet alle problemen op. Soms maakt het ook dat een deel van de mail onbedoeld buiten te deur wordt gehouden. Voor een groot deel is die mail afkomstig van servers die zelf niet goed ingesteld staan.

Precies! Die niet goed ingesteld staan! En daar kan je als kleine mailserverbeheerder niet echt een standpunt tegen innemen, maar als de grote jongens dat gaan blokkeren zal dat probleem zichzelf snel genoeg oplossen. Niet zichzelf natuurlijk, maar dan is er opeens flink druk op de beheerders van die servers om het op te lossen.

[WillySis]

Het probleem is dat veel bedrijven en instellingen wel een eigen mailserver hebben, maar niemand met voldoende kennis van zaken om zo'n ding goed in te stellen. Vaak is dan "als het maar werkt is het goed genoeg". Dat zijn ook de bedrijven die pas laat door zullen hebben dat hun mail niet meer aankomt. Nu lijkt het al niet ongewoon meer dat men doodleuk verteld dat de mail van een bedrijf vaak als spam gezien wordt en je dus ook de spam-folder moet checken.
Als grote providers de mail van niet goed ingestelde servers gaan weigeren, zullen gewoon nog meer bedrijven je vragen om de spam in de gaten te houden. Dan ben je dus steeds vaker tussen je spam aan het zoeken. Dan maar liever af en toe een redelijk herkenbaar spambericht wat er tussendoor glipt tussen de gewone mail.

[nobraininvolved]

Ik heb er zelf niet veel verstand van hoor, maar wat ik altijd zo raar vind, is dat je niet gewoon altijd het echte emailadres ziet waar een mail vandaan komt. Waarom laten programma's als outlook of Gmail altijd het door de verzender aangegeven adres zien en niet het daadwerkelijke adres?
Dan zou het toch veel meer opvallen dat veel mail gewoon niet klopt?

[MadEgg]

Tja, dat zou prettig zijn. Een van de redenen daarvoor is in ieder geval het gebruik van mailing-lists. Je stuurt dan een mailtje naar een centraal adres van de mailinglist en de mailinglist-software stuurt jouw mailtje door aan alle mensen die daarop geabonneerd zijn. Je krijgt dan doorgaans jouw naam + e-mailadres als afzender te zien bij de ontvangers, met een reply-to (en return-path) van de mailinglist, om de conversatie centraal te houden. Zo zijn er meer valide redenen te vinden waarom dat mogelijk moet zijn, zoals nieuwsbrieven van bedrijven. Overigens kunnen zowel SPF als DKIM daar ook fatsoenlijk mee omgaan, zolang de configuratie van de mailinglist-software maar juist is. SPF valideert alleen de envelope sender, die dus van de mailinglist zou moeten zijn en niet van de oorspronkelijk afzender. De software van de mailinglist zal een nieuwe DKIM-signature moeten genereren, of geen headers aanpassen / toevoegen die middels DKIM ondertekend zijn.

[sugarlee89]

Merk er helemaal niks van, gebruik gmail al sinds de eerste dag, nog nooit een spam mail gezien behalve in de spam box. Konden ze tot voor kort op de bedrijfsvloer niet aan tippen of alles kwam door of timmerde het zo dicht dat geen een mailtje meer doorkwam.

[faim]

Ik ervaar het juist andersom, alle server configuratie correct ingesteld en toch beland mijn e-mail bij Outlook vrij regelmatig in de spambox, ondanks dat het gewoon van een Google-server afkomt. Ook bij afzenders die (voor zover het lijkt) alles goed hebben ingesteld en zelfs tussen mijn contactpersonen staan, belanden bij mij regelmatig in de spam-folder (G-Suite).

[Opperpanter2]

Google had ik dacht in 2016 aangekondigd hun dmarc policy op reject te gaan zetten, maar vooralsnog staat deze op none toen ik onlangs keek.

[MSalters]

zolang gmail en hotmail alle mogelijke troep en misconfiguratie blijven accepteren zit je jezelf alleen maar in de weg. Zij lijken volledig in te zetten op heuristieken en spamfilters

Deden ze dat maar. Ik heb hier een all-in-one printer die kon scannen naar email-adressen. Dan kreeg je een PDF-je in je email. Dat werkt nu niet meer. Ik ben geruime tijd aan het troubleshooten geweest, maar het lijkt SPF of iets in die hoek. Misconfiguratie, ongetwijfeld, maar niet te vinden.

Als ze een stukje AI hadden, dan had die aan het IP adres en gelinkt domein snel genoeg kunnen zien dat dit volstrekt geen spam was.

[MadEgg]

Ik weet niet hoe je all-in-one werkt - ik heb voor een grote professionele all-in-one met dergelijke functionaliteit een eigen mailaccount op de mailserver aangemaakt. Vervolgens stel je net als in je lokale mail-client de juiste SMTP-server met de juiste credentials in en het werkt. Mails worden daarmee ook gelijk voorzien van een valide DKIM-signature, en voldoen natuurlijk aan de SPF-eisen.

Deden ze dat maar.
[...]
Als ze een stukje AI hadden, dan had die aan het IP adres en gelinkt domein snel genoeg kunnen zien dat dit volstrekt geen spam was.

Heuristieken en spamfilters zijn geen AI, maar eerder statistiek. En dat kan falen (AI natuurlijk ook). Dat merken we ook vaak genoeg met spamfilters. Een juiste mailconfiguratie helpt over het algemeen wel om de spam-score van je mails omlaag te brengen.

[richard1074]

SPF/DKIM controleert alleen het envelope-from adres. Die kan hier wel in orde zijn. Wat hier volgens mij is gebeurd is dat het Header From veld is aangepast. Dan ziet de ontvanger in zijn mailclient/webinterface dus een verkeerd adres staan. SPF/DKIM lost dat niet op. Veel spammers gebruiken namelijk wel de juiste envelope from adres om spamfilters te omzeilen.
De ontvanger ziet dan wel een bekende verzender en trapt dan in de phishing.

[orbit_ph]

SPF zit op 5321.MailFrom, ook wel Mail From, Return Path, Envelope From of Bounce adres
De check vindt plaats als mailservers (MTA) met elkaar communiceren.

Bij DKIM ben je vrij om te kiezen welk domein je gebruikt voor je authenticatie, dit kun je doen op basis van het 5321.MailFrom adres of op basis van het 5322.From (Display From, wat zichtbaar is in je mail client) adres.

Ga je met DMARC aan de slag, dan vinden alle acties plaats op basis van het Display From domein (5322.From) en zul je ervoor moeten zorgen dat je DKIM authenticatie gebruik maakt van het 5322.From domein of je SPF authenticatie gebruik maakt van het 5322.From domein. (zogenaamd domain alignment)
https://space.dmarcian.co...-pass-and-yet-dmarc-fail/

[eelkef]

Deze mails kreeg ik afgelopen dagen ook inderdaad.
Zouden deze niet tegengehouden moeten worden door een spf regel van google?
Dan kun je alleen mail versturen van ip-adressen van gmail.
Of met DKIM? Dan weet je ook zekerder dat de verzender ook echt het bericht verzonden heeft.

Dit zijn beide technieken om de spoofing van headers te kunnen herkennen en de mail daarom te kunnen droppen.
Iemand een idee waarom dit niet werkt/gedaan is bij deze mails?

[bbob]

spf werkt zo niet.

De ontvangende partij check het wel en ziet dan dat het ip adres van waar de mail verstuurd word niet het juist is. Op basis daarvan beland de mail dan meestal in een spam folder maar dat hoeft niet altijd.

Ben bij zo in het beging bezig met exactonline. Daar kun je facturen naar klanten versturen met jou adres als afzender via hun mailservers. In het begin dus probleem facturen landen in de spam folder omdat jawel de exact mailservers niet in mijn spf record stonden. Daar wilde ze in het begin niet aan, was geen probleem, ondertussen wel veranderd en staat nu ook in pagina.

Iedereen kan namens een willekeurig mailadres mail versturen, het is dan aan de ontvangende server het spf record te checken, te kijken naar ip adres of dat niet op een blacklist staat en of dat ip adres in spf record staat.

[MadEgg]

SPF werkt zo wel. Het zegt welke mailserver mail mogen verzenden namens een domein. Daar gaat Google echter de fout in - hun SPF record zegt:

_spf.google.com. 143 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

Die ~all op het einde is kwalijk, wat mij betreft. Dat zegt: komt het van een andere server dan kunnen we de inhoud niet garanderen, maar accepteer het toch maar. Dat zou gewoon een keiharde -all moeten zijn. En dat zou Gmail, Hotmail en andere mailboeren ook gewoon moeten vereisen (-all op het einde), dan wordt het afweren van spam een heel stuk simpeler.

En ja, dan werken constructies zoals jij noemt, versturen namens iemand anders, niet meer. Is ook niet wenselijk - als iemand mail namens hen door een derde partij willen laten versturen dan moeten ze maar de moeite nemen om te zorgen dat de configuratie ook juist is. Anders kan het gewoon niet. Daar een duidelijke beslissing in maken maakt veel spam onmogelijk.

[Reactie gewijzigd door MadEgg op 23 juli 2024 17:10]

[blinchik]

Tja, in theorie heb je gelijk - vroeger had ik ook een -all. Je hebt echter veel verkeerd geconfigureerde mailservers (of, verkeerd geconfigureerde SPF records). Zo heb ik leveranciers / klanten gehad die een mailfarm van 4 servers hadden, en van slechts 2 servers waren de IP's genoteerd in het record. De andere 2 werden door mij (dus terecht) geblokkeerd.

Dat is de theorie. In de praktijk kloegen gebruikers dat mail bij ons niet aankwam, en bij anderen (die geen spf check deden) wel. Dus volgens de gebruiker lag het aan ons. Contact opnemen met het de andere bedrijven lukte ook niet goed : admins die langs geen kanten wisten waar het over ging, externe IT die niet te bereiken was en ook niet begreep waar het over ging, want bij de meesten en bij hen kwam de mail allemaal wel netjes aan.

Ik heb nu geen -all, maar wel een redelijke afstraffing bij een fout SPF record bij de SPAM score - de gebruiker kan dan nog altijd die mail taggen als geen spam.

Misschien dat Google dezelfde redenering toepast?

[Old Swartly]

je lijkt twee zaken te verwarren. Jij kunt een -all als afsluiting van het SPF-record op jouw domein, gebruiken, waarmee je aangeeft wat ontvangers met berichten van jouw domein moeten doen die SPF-resultaat FAIL opleveren. Dat kunnen ze vervolgens respecteren of negeren maar het heeft geen invloed op de bezorgbaarheid van andermans mail richting jouw mailserver. Die wordt bepaald door de configuratie van jouw eigen mailservers: je kunt andersmans -all respecteren of als ~all behandelen bijvoorbeeld. Maar je eigen SPF-record heeft daar geen invloed op.

[blinchik]

Ja, je hebt gelijk, mijn uitleg was inderdaad wat warrig.

Ik bedoelde dat ik vroeger een -all dropte, en dat ik nu een een -all op mijn spamfilter niet meer drop, maar dat deze wel wordt geflagged als SPAM, waardoor de gebruiker zijn mail toch nog binnen krijgt.

[MadEgg]

Ja, dat klopt, en daar zou wel eens wat mogen veranderen. Ik weet de cijfers niet, maar een heel groot deel van alle mailaccounts op internet zijn ondergebracht van Google of Microsoft. Zij zijn dus ook degene die veranderingen kunnen afdwingen. Als mail standaard geweigerd wordt door Gmail en Hotmail/Outlook dan wordt er snel genoeg zo veel geklaagd dat de configuratie wel gefikst moet worden.

Als ik mijn mailserver instel om een missende rDNS te weigeren, een niet bestaande HELO te weigeren, of een falende SPF-check te weigeren dan worden er veel mails niet afgeleverd waardoor de gebruikers bij mij komen klagen. Ik kan daarin niet een kritisch standpunt innemen. Google en Microsoft kunnen dat wel. Dus laten ze dat alsjeblieft ook eens doen, dan worden er écht stappen genomen om het spammers onmogelijk te maken.

Overigens heb ik voor mijn eigen domeinnamen SPF gewoon op -all ingesteld en DMARC zegt ook mail te weigeren die faalt voor SPF of DKIM. Het jammere is dat ook dat weer als wegingspuntje in de spamfilters bij gmail en outlook meegenomen wordt, in plaats van dat er daadwerkelijk gehoor aan gegeven wordt en mail die niet aan de eisen voldoet gewoon keihard geweigerd wordt.

[Reactie gewijzigd door MadEgg op 23 juli 2024 17:10]

[Dorank]

Mail weigeren op die criteria is niet handig, maar als je ze gebruikt voor een spam score werkt het prima. Geen rdns en geen zinnige HELO en een SPF fail is een score voldoende voor SPAM, tenzij er andere checks zijn die totale score onder de threshold krijgen is het aan de eindgebruiker om deze te laten weigeren of in de tijdelijke spam folder te laten afleveren.

[MadEgg]

Is een expliciet foutieve configuratie weigeren onhandig? Waarom zou je niet kunnen eisen dat de afzender zich aan de standaard houdt en zijn zaken op orde heeft? Waarom willen we spammers de mogelijkheid geven om een in hun nadeel uitslaande balans qua spamscore via trucjes alsnog onder de spamgrens te laten vallen?

[the_stickie]

Omdat je een hoop potentiële klanten tegen de schenen schopt (of negeert) bijvoorbeeld?

[MadEgg]

Ontwikkelaars testen hun webapplicaties in Chrome. Waarom zou je je e-mail niet op Gmail testen? Als ik ergens een mailconfiguratie opzet test ik altijd of de mails in ieder geval juist aankomen bij mijn eigen mailserver, bij een gmail account en bij een outlook account. Dat is het minste wat je kunt doen.

Op deze manier komt het er feitelijk op neer dat ondanks dat we een prima systeem hebben om spam binnen te perken te houden, we dat niet doen omdat er een aantal incapabele of luie beheerders van mailservers zijn. En daar betaalt iedereen wereldwijd de rekening van in enorme datatransfers van ongewenste mails.

[the_stickie]

Ten eerste ga je er van uit dat ik niet zou testen, dat is ronduit beledigend, ten tweede geef ik vooral aan dat er veel andere zaken zijn waarmee rekening gehouden moet worden bij het implementeren van eender welke oplossing. Als techneut sta je niet alleen in een bedrijf. Als een "oplossing" mogelijk schade aanbrengt in bijvoorbeeld de relatie met je klanten is dat, wat mij betreft, zeker iets om rekening mee te houden (en door te spreken). En dan kan het resultaat best zijn dat blijkt dat de beste technische implementatie niét het streefdoel is.

[MadEgg]

Ik zeg niet dat jij niets test. Mijn punt is dat als je een mailserver opzet, je best de verantwoordelijkheid mag nemen om voor een juiste configuratie te zorgen. Waaronder dus best kan vallen dat je test of je mailserver mails kan bezorgen bij Gmail e.a.

Het is historisch zo gegroeid dat er bij web-gerelateerde diensten erg laks met de specs werd omgegaan. Zo gaat het met SMTP, zo gaat het helaas ook met HTML in browsers. Alles wat maar een beetje op HTML lijkt wordt als zodanig behandeld en getracht om te corrigeren, in plaats van dat er gewoon een syntax error gegeven wordt. Dat kun je nu helaas niet echt meer maken aangezien het altijd zo geweest is, maar het is wel een zeer kwalijke zaak.

De configuratie van mailservers kan best de juiste kant op geduwd worden door geleidelijk aan de teugels aan te trekken. Maar dan heb je wel overwicht nodig, wat gmail en outlook hebben. Dat afwachtende geneuzel schieten we niets mee op. En er is hier een zéér goed argument wat vrijwel iedereen ervaart: spam, phishing en malware. Dat zou toch moeten bijdragen aan draagvlak voor het aanscherpen en handhaven van de regels.

[Verwijderd]

In de praktijk kloegen gebruikers ...

Kloegen? Hehehe

Ik kan vanaf een webserver met de standaard PHP mail() functie zo willekeurige mailadressen invullen (dus spoofen) bij het FROM veld. Dat komt gewoon aan bij Google (zowel Gmail als G Suite). Die doen er niet moeilijk over.

[Carharttguy]

"Kloegen" is in België acceptabel als vervoeging. Er is (nog) geen uitsluitsel of het correct is, maar het is ook nog niet zeker of het foutief is.

[the_stickie]

Staat in het groene boekje dus is correct http://woordenlijst.org/#/?q=klagen

[3raser]

Het probleem met SPF is dat je geen tussenliggende diensten kunt gebruiken omdat het verzendende IP adres dan wijzigt. Diensten als externe spam-filters bijvoorbeeld. Die ontvangen jouw mail, filteren het en sturen het daarna op naar de juiste server. Die server kan vervolgens niets meer met het SPF record omdat de verzender altijd de server van het spam-filter is.

SPF is een leuke gimmick om je spamscore te verlagen maar het is absoluut niet geschikt om mail op af te keuren.

[MadEgg]

Wat jij noemt is een foute configuratie. Alles wat mail verstuurd namens een domein moet in het SPF-record staan. Ook een eventuele externe spamfilter, als je die gebruikt.

Als je het hebt over een externe spam-filter aan de kant van de ontvanger: ook dan is het een misconfiguratie. De ontvanger bepaalt in dat geval dat alle mail via een externe spamfilter loopt en moet er in dat geval voor zorgen dat de spamfilter SPF controleert en niet de MDA van de ontvanger.

[3raser]

Het versturen met een correct SPF-record moet geen enkel probleem zijn. Ik heb het echter over het ontvangen van e-mail. Er zijn diverse diensten die een dedicated spam-filter aanbieden waarna de mail gerouteerd wordt naar je eigen inbox.

[MadEgg]

Daarover zei ik:

Als je het hebt over een externe spam-filter aan de kant van de ontvanger: ook dan is het een misconfiguratie. De ontvanger bepaalt in dat geval dat alle mail via een externe spamfilter loopt en moet er in dat geval voor zorgen dat de spamfilter SPF controleert en niet de MDA van de ontvanger.

Bij een externe dienst moet je zorgen dat je de beslissing spam/geen spam overlaat aan de externe dienst en uitsluitend mail die afkomstig is van de externe dienst vertrouwen. In dat geval moet de externe dienst de SPF/DKIM valideren. Ook een kwestie van configuratie dus.

[watercoolertje]

Dan moet je geen dubbele filtering toepassen natuurlijk.

Imho niet echt een probleem dus, ben het wel met je eens dat je niet op enkel verkeeede/spf moet filteren.

[3raser]

Daar heb je niet altijd invloed op. Bijvoorbeeld als je e-mail account gehost wordt door Google of Microsoft. Die laten je echt niet bepalen of jij de SPF controle uit wilt schakelen omdat je hem op een andere server al gecontroleerd hebt.

[Reactie gewijzigd door 3raser op 23 juli 2024 17:10]

[watercoolertje]

Klopt maar dan is de tussenliggende spamfilter ook wel overbodig.

[3raser]

Dat is subjectief. En dat het voor komt geeft al aan waarom het SPF record in die gevallen niet goed functioneert (want daar gaat het om).

[Old Swartly]

SPF is niet het end-all-be-all van spampreventie en het kent zijn zwakke punten (die zijn geprobeerd te verbeteren in bijvoorbeeld 'opvolger' DKIM) maar wat jij beschrijft is er daar niet één van. Wannneer je als (als admin van een mailserver) alle mail over een extern spamfilter verstuurt en vervolgens het SPF-record niet aanpast is dat een configuratieprobleem van jou, geen ontwerpprobleem van de techniek

[orbit_ph]

Samen met Scott Kitterman in de praktijk al eens gekeken naar het mechanisme, het gros van de ontvangers, die alleen op SPF controleert, kijkt echt niet naar het mechanisme voor de qualifier (in het geval van ~all of -all).

Verder, met betrekking tot het artikel, heeft telus.com een SPF include van _spf.google.com in het eigen record zitten waarmee ze op basi van SPF toestaan dat je gebruik mag maken van de Gmail infrastructuur.
Zie ook: https://dmarcian-eu.com/spf-survey/telus.com

[MadEgg]

Samen met Scott Kitterman in de praktijk al eens gekeken naar het mechanisme, het gros van de ontvangers, die alleen op SPF controleert, kijkt echt niet naar het mechanisme voor de qualifier (in het geval van ~all of -all).

Precies, en dat zouden ze dus wel moeten doen. Een faal bij SPF -all is duidelijk: weg met de mail! Maar sowieso zou ~all eigenlijk gewoon niet gebruikt moeten worden - dit zou altijd -all moeten zijn. Als je niet weet welke servers mail sturen namens je domein dan moet je jezelf toch eens even goed achter de oren krabben.

Verder, met betrekking tot het artikel, heeft telus.com een SPF include van _spf.google.com in het eigen record zitten waarmee ze op basi van SPF toestaan dat je gebruik mag maken van de Gmail infrastructuur.
Zie ook: https://dmarcian-eu.com/spf-survey/telus.com

Wat ik hier in het artikel lees gaat het om spam namens gmail-gebruikers, die verzonden zou zijn via de servers van telus.com

Dat telus.com Google-servers aanmerkt als valide afzenders betekent niet dat Gmail Telus-servers aanmerkt als valide afzenders, dus dat zou voor het eindoordeel niet moeten uitmaken. Tenzij het specifiek om gebruikers va een @telus.com e-mailadres gaat die voor dat adres gebruik maken van GMail.

[Verwijderd]

Maar de Exact gegevens toevoegen in je SPF-record is toch iets wat je alleen zelf kan/moet doen?
Daar hebben zij geen controle over toch? Zij kunnen niet bij jou DNS.

Of hebben ze nu een mogelijkheid ingebouwd voor elke klant dat ze d.m.v. SMTP hun mail kunnen versturen?

[bbob]

Klopt die moet je idd zelf toevoegen, dat kunnen ze niet voor jou doen.
Moet je dus zelf doen of je hosting provider kan het doen.

Probleem was jaren terug dat exact toen niet zo bewust was van de waarde van spf record en in mijn geval veel emails verstuurd via exact bij de spam kwamen.

[Donstil]

Maar de Exact gegevens toevoegen in je SPF-record is toch iets wat je alleen zelf kan/moet doen?
Daar hebben zij geen controle over toch? Zij kunnen niet bij jou DNS.

Klopt. Verzend Exact Online namens je domein dan dien je de verzendende server van Exaxt toe te voegen aan je eigen SPF record.

Include:_spf.exactonline.nl

in dit voorbeeld.

[Batiatus]

Ik heb deze mailtjes ook gekregen inderdaad. Heel vreemd fenomeen. Bij de afzender staat ook 'mij' en je email adres. Eerste gedachte bij mij was ook dat mijn account gecompromiteerd was, maar dan had ik ook een bericht van Google zelf gehad dat er van een vreemd IP zou zijn ingelogd op mijn account, daarnaast staat 2FA aan.

Overigens staat er bij de berichten nu "Het lijkt een nep-'bounce'-antwoord op een bericht dat je helemaal niet hebt verzonden".

[Reactie gewijzigd door Batiatus op 23 juli 2024 17:10]

[HooksForFeet]

Wat moet ik me voorstellen bij "bounce"-antwoorden?

Ook mysterieus dan dat je zowel de bouncemelding krijgt, als de "verzonden" mail in je sent-box.

[bigbadbull]

je stuurt een mail naar [e-mail], die komt niet aan, en je zet het het replay adres op [e-mail].

dan krijg je na een tijd een mail terug dat de mail die jij verzonden hebt naar [e-mail]
niet bereikbaar was.

Als nu @declown.nl een bestaande mail server is, dan zal hij zegen dat HooksForFeet geen gekende user in het domain is. maar dat bericht is aanpasbaar, dus kan je daar een normaal uitziend mailbericht van maken.
en als je dat bericht nu nog eens via een andere spoof zender laat komen en de voorgaande header schrapt, dan weet je niet dat dit een bounce mail van @declown.nl

[HooksForFeet]

Helder, dank voor de uitleg!

[maratropa]

ik had ze ook, ook 2-factor aan. Niet in mijn sent map doch.. ( of als ik berichten als spam aanmerk; verdwijnen ze dan ook uit de sent map?)

[Sharkoon]

zet je jezelf dan niet op de spamlijst?

[maratropa]

das een goeie, niet aan gedacht
Zullen ze wel aan denken toch?

[Sharkoon]

ik heb geen idee

[SpazzII]

Ik heb de berichten als spam aangemerkt. Ik heb mijn sent map daarvoor niet bekeken. Ze staan nu in de spam map, met de opmerking dat ik mijn eigen adres als afzender als spam heb aangemerkt. Volgens mij kan ik mezelf dus geen mail meer sturen (deed ik wel eens als reminder).

[maratropa]

naar mezelf mailen gaat nog gewoon goed hier

[Macchill]

Ik heb afgelopen weekend ook tientallen van dit soort mailtjes gekregen.
Normaal gesproken komen er zo'n 4 a 5 spam per week binnen op mijn mailadres, nu dus meer dan 50 in 2 dagen, voornamelijk van 'mijzelf'.

[Verwijderd]

Ik krijg ze ook, maar ik snap niet hoe ze aan de tenaamstelling komen. Allemaal gericht aan "Fluffy buffy rabbit" en dat staat echt niet in het e-mail adres . . .

[masterjorie]

Zelf ontvang ik bijna nooit spam op mijn gmail, maar ook ik kreeg 4 van deze spammailtjes. Het bijzondere was dat ik sommige van deze mailtjes tot wel 28x keer had gekregen. Inmiddels komen ze wel in mijn Spam folder. Krijg inmiddels ook een melding bij het mailtje dat het een zogenaamd niet-bezorgd antwoord is op een bericht dat ik niet daadwerkelijk heb verzonden.

[flippiej]

Toch wel jammer dat ik geen 26x gratis mag verblijven bij een van der Valk hotel Ik vond het al zo vreemd dat ze niet m'n spamfolder in gingen en dat het er zo veel waren, maar ze zijn bij mij nu ook door google in de spam gezet.

[masterjorie]

Had exact hetzelfde mailtje van een gratis verblijf in een van der Valk hotel.

[RobbyTown]

Aha ben dus niet de enige zie ik hier. 3 stuks gehad. Normaal is de spam ook echt in de spam te vinden en daar staat zelden spam in dus ben zeer benieuwd waar mijn email adres is gelekt. Of is iedereen met gmail de sjaak geweest?

[Reactie gewijzigd door RobbyTown op 23 juli 2024 17:10]

[HooksForFeet]

Ik ken er inmiddels veel, dus zo'n "klein deel" lijkt het niet te zijn...

[DigitalExorcist]

Hier (nog?) niet....

[HooksForFeet]

Zoek eens naar berichten via telus in je spam-map. Ik zag ze bij toeval verschijnen op m'n telefoon en een minuut later zaten ze alsnog in de spammap. Had ik een minuut later gekeken, dan had ik nooit geweten dat het gebeurd was.

[DigitalExorcist]

Nope, gekeken, staan een paar hardnekkig legitieme berichten in die ik in mn Inbox wil maar Google standaard als spam markeert..

[jwal]

Mn ouders hadden er ook een lading.. sinds zaterdag een stuk of 10-15 spammails via telus.

[ivocare]

Op een gegeven moment ontkom je er niet aan om rDNS, DANE, spf, dkim en dmarc goed in te richten.

Richt eerst dmarc in. Dan weet je waar er vanuit jouw domein gemailt wordt. Onderzoek de resultaten en pas je spf record aan waar nodig.

Na een onderzoek periode ga je spf en dmarc strakker instellen door de spf hardfail en dmarc quarantaine of remove optie.

[jeroen3]

Hebbn deze maatregelen nog invloed op e-mails die je daadwerkelijk van jezelf, naar jezelf stuurt vanaf bijvoorbeeld een Synology NAS?

[NoobishPro]

Als ik het op de goek moet gooien;
Ligt er aan of je via een API, of app oid gekoppeld bent aan jouw gmail account, of jouw NAS als een soort server gebruikt om vervolgens inderdaad je e-mailadres te faken voor de handigheid.

In het eerste geval vermoed ik dat het geen probleem zou moeten zijn (gezien je het gewoon via gmail doet; op de correcte manier) en in het 2e geval vermoed ik dat het wel eens problemen op zou kunnen leveren. Tenslotte is er bij het 2e geval niet echt een 'link' aan jouw eigen e-mail adres anders dan dat deze benoemd word.