Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
spammer gebruikt in Return-Path mail adres van ontvanger adersom geschreven
Beste forum lezer,
Vraag over spam: Eigen email adres staat achterstevoren in Return-Path
De laatste tijd krijg ik meer spam dan normaal binnen en probeer deze steeds te melden in spamcop.net. maar sommige mails kan ik niet melden omdat het header adres niet klopt.
Nu valt mij op dat mijn eigen email adres in het Return-path staat alleen andersom geschreven.
Ik heb even mij eigen mail adres verwijderd en vervangen voor een voorbeeld adres.
Bv mijn mail adres pietjepuk.xs4all.nl
Return-Path: <bounce_2ln.lla4sx=kupejteip_82J843-55-2NEB34-QPPBFE-FBRKN4-1U2K-4G7O@mx2.apstracker.com>
Het lijkt erop dat zo het originele spammer adres niet meer gevonden kan worden.
Ik krijg inmiddels meerdere mailtje per dag binnen met de zelfde opbouw in het bounce adres.
Steeds bevat het adres van de spammer mx2.xxxx.com. (bij xx kan elke willekeurigenaam ingevuld worden in dit bericht was het mx2.apstracker.com) Subject: <eigenemail adres>zin in een gratis NETFLIX abonnement?
Het liefst wil ik deze spammer ook aan de schandpaal nagelen. Zijn er meer formum lezers die deze form van spam kennen? En hoe kom je er van af. Want blokkeren lukt niet omdat het geen geldig adres is. Ik weet spam vrij zijn is een illusie, maar probeer elke spam bij spamcop te melden tegen beter weten in misschien? ! maar met deze spammer lukt dat niet. En ik vroeg me af hoe de spammer dit voor elkaar krijgt.
Zou wel meer willen weten hoe spam werkt zodat ik het beter tegen kan gaan en begrijp. Nee ik wil geen spammer worden ;-)
iemand nog weblinks met meer informatie hierover?
Alvast bedankt voor jullie reacties.
Vraag over spam: Eigen email adres staat achterstevoren in Return-Path
De laatste tijd krijg ik meer spam dan normaal binnen en probeer deze steeds te melden in spamcop.net. maar sommige mails kan ik niet melden omdat het header adres niet klopt.
Nu valt mij op dat mijn eigen email adres in het Return-path staat alleen andersom geschreven.
Ik heb even mij eigen mail adres verwijderd en vervangen voor een voorbeeld adres.
Bv mijn mail adres pietjepuk.xs4all.nl
Return-Path: <bounce_2ln.lla4sx=kupejteip_82J843-55-2NEB34-QPPBFE-FBRKN4-1U2K-4G7O@mx2.apstracker.com>
Het lijkt erop dat zo het originele spammer adres niet meer gevonden kan worden.
Ik krijg inmiddels meerdere mailtje per dag binnen met de zelfde opbouw in het bounce adres.
Steeds bevat het adres van de spammer mx2.xxxx.com. (bij xx kan elke willekeurigenaam ingevuld worden in dit bericht was het mx2.apstracker.com) Subject: <eigenemail adres>zin in een gratis NETFLIX abonnement?
Het liefst wil ik deze spammer ook aan de schandpaal nagelen. Zijn er meer formum lezers die deze form van spam kennen? En hoe kom je er van af. Want blokkeren lukt niet omdat het geen geldig adres is. Ik weet spam vrij zijn is een illusie, maar probeer elke spam bij spamcop te melden tegen beter weten in misschien? ! maar met deze spammer lukt dat niet. En ik vroeg me af hoe de spammer dit voor elkaar krijgt.
Zou wel meer willen weten hoe spam werkt zodat ik het beter tegen kan gaan en begrijp. Nee ik wil geen spammer worden ;-)
iemand nog weblinks met meer informatie hierover?
Alvast bedankt voor jullie reacties.
Reacties (9)
Kan je de Emailclient (bijv.thunderbird,outlook oid) niet instellen dat hij elke mail die binnenkomt op broncode filter op juist dat returnpath adres waar je het hierboven over hebt ? Tenzij die gast niet elke mail van een ander return path voorziet kan je die mailtjes op die manier opvangen en kwijtraken. Thunderbird doet dit meestal vrij goed geloof ik. Misschien heb ik iets gemist van bovenstaand verhaal maar het is dus maar een idee..
Return-path is een header die een MTA kan toevoegen om zo duidelijk te maken wat de envelope sender was. De envelope sender wordt misbruikt door massa mailers (niet alleen spammers) om bounces te tracken.
Je moet weten dat Return-Path headers ook door spammers kunnen worden toegevoegd. Veel MTA's wissen die header en vervangen hem door het envelope sender adres.
De envelope sender is het email adres dat is gebruikt tijdens de SMTP sessie (MAIL FROM: <verzender@verzenddomein.tld>)
Over de spam zelf is ook iets te zeggen. Spammers registreren grote aantallen domeinen en gebruiken servers bij providers om hun massa mail te versturen. Die methode heet snowshoe spam. De method is heel "populair" in de Verenigde Staten. In Europa doen bedrijven ongeveer hetzelfde. Er worden email adressen gedeeld met bedrijven in andere landen en zo maken ze het moeilijker om anti-spam waakhonden er iets aan te doen.
Dit soort spammers gebruiken vaak SPF of DKIM om de illussie van vertrouwen te creeeren. Sommige domme filters denken dat email met SPF of DKIM betrouwbaar is. Dat is uiteraard niet zo, want degene die beschikking heeft over het domein kan zonder problemen de benodigde DNS records aanmaken.
Hoezo lukt het niet om deze spam bij Spamcop aan te melden? Wordt daar een reden voor gegeven?
Wat je er zelf aan kunt doen is zorgen dat je email adres niet handen komt van de spammers. Ze proberen emailadressen te verzamelen via reclame op sites om die te delen met "partners". Je doet mee aan een wedstrijd (sweepstake) met een makkelijke vraag om iets te winnen wat je graag wilt hebben. Een Mini of een iPhone bijvoorbeeld. Geef je email adres gewoon niet op. Ook niet op sites zoals consumeo en dergelijke. Die werken met de spammers samen.
De truuk die men toepast is dat het aantal partners oneindig is en als je unsubscribe gebruikt is het alleen voor 1 partner. Dat is uiteraard wettelijk niet in orde. Men moet bij opt in en in iedere email de gelegenheid bieden volledig uit te schrijven, ook bij die "partners". Zomaar persoonlijke gegevens delen met niet met naam en toenaam genoemde partners is overigens wettelijk ook niet ok.
Daarom is voorkomen beter dan genezen: deel je gegevens niet. Ook niet die van je auto (kenteken) en info voor verzekeringen.
Je moet weten dat Return-Path headers ook door spammers kunnen worden toegevoegd. Veel MTA's wissen die header en vervangen hem door het envelope sender adres.
De envelope sender is het email adres dat is gebruikt tijdens de SMTP sessie (MAIL FROM: <verzender@verzenddomein.tld>)
Over de spam zelf is ook iets te zeggen. Spammers registreren grote aantallen domeinen en gebruiken servers bij providers om hun massa mail te versturen. Die methode heet snowshoe spam. De method is heel "populair" in de Verenigde Staten. In Europa doen bedrijven ongeveer hetzelfde. Er worden email adressen gedeeld met bedrijven in andere landen en zo maken ze het moeilijker om anti-spam waakhonden er iets aan te doen.
Dit soort spammers gebruiken vaak SPF of DKIM om de illussie van vertrouwen te creeeren. Sommige domme filters denken dat email met SPF of DKIM betrouwbaar is. Dat is uiteraard niet zo, want degene die beschikking heeft over het domein kan zonder problemen de benodigde DNS records aanmaken.
Hoezo lukt het niet om deze spam bij Spamcop aan te melden? Wordt daar een reden voor gegeven?
Wat je er zelf aan kunt doen is zorgen dat je email adres niet handen komt van de spammers. Ze proberen emailadressen te verzamelen via reclame op sites om die te delen met "partners". Je doet mee aan een wedstrijd (sweepstake) met een makkelijke vraag om iets te winnen wat je graag wilt hebben. Een Mini of een iPhone bijvoorbeeld. Geef je email adres gewoon niet op. Ook niet op sites zoals consumeo en dergelijke. Die werken met de spammers samen.
De truuk die men toepast is dat het aantal partners oneindig is en als je unsubscribe gebruikt is het alleen voor 1 partner. Dat is uiteraard wettelijk niet in orde. Men moet bij opt in en in iedere email de gelegenheid bieden volledig uit te schrijven, ook bij die "partners". Zomaar persoonlijke gegevens delen met niet met naam en toenaam genoemde partners is overigens wettelijk ook niet ok.
Daarom is voorkomen beter dan genezen: deel je gegevens niet. Ook niet die van je auto (kenteken) en info voor verzekeringen.
Verstandig uitgangspunt (ook voor andere lezers met vergelijkbare problemen):
ALLES in een e-mail, inclusief headers, behalve Received: headers die bovenaan zijn toegevoegd door door jou vertrouwde mailservers, kan worden vervalst, en dat geldt ook voor DKIM headers [1].
M.a.w. bij spam is meestal het enige dat je kunt vertrouwen, het IP-adres waarvandaan de "verste" (bij jou vandaan), nog door jou vertrouwde mailserver, de e-mail kreeg aangeboden.
Met dat uitgangspunt in het achterhoofd kun je proberen vast te stellen wat er niet vervalst is in de e-mail:
1) Is de e-mail digitaal gesigneerd met PGP of S/MIME? Dat heb ik nog nooit gezien bij spam, maar spammers gaan dat ongetwijfeld een keer gebruiken. Zo ja, is de bijbehorende public key (ter verificatie van de digitale handtekening) aantoonbaar (check op PGP keyserver volstaat niet) van de kennelijke afzender, en is diens private key niet gejat?
2) Staat er een geldig SMTP afzenderadres achter "From:" (mail from dus, niet te verwarren met envelope from of return-path? Zo ja dan kun je checken of DMARC, voor het afzenderdomein, correct en afgedwongen, is ingericht.
3) Als er een DKIM header in staat moet je eerst checken of die is toegevoegd door een mailserver die geautoriseerd is om e-mail te verzenden namens het afzender domein in het SMTP adres achter From: (dat dan natuurlijk wel geldig moet zijn). Zie ook [1].
Zoals Anoniem van 02:29 hierboven schrijft is het bij spam gangbaar om het "Return-Path" (Envelope-From) te vervalsen. Dat wordt gedaan om ten minste de volgende redenen:
1) Een "account" waarop wordt geregistreerd welke spam niet kon worden afgeleverd (voor die domeinen die eerst elke mail aannemen en ergens daarna pas vaststellen of de mail kan worden afgeleverd);
2) Een willekeurig account (hoeft niet te bestaan) van een domain dat SPF records publiceert, dit omdat er suffe spamfilters bestaan waarvan de auteurs denken dat als SPF klopt, het niet om spam kan gaan (onzin natuurlijk);
3) De combinatie van bovenstaande 2 (voorbeeld: [2]).
Jouw accountnaam wordt vermoedelijk achterstevoren geschreven zodat deze niet door mensen zoals jij herkend wordt (faal in dit geval), en de spammers wellicht onvoldoende vertrouwen hebben in hun eigen hashtechnieken (en handmatig willen kunnen checken).
Overigens, als alles van SPF, DKIM en DMARC klopt (en de bijbehorende infornatie correct en volledig is (replay attacks zijn uitgesloten), de testende mailserver goed checkt), bestaan ten minste nog de volgende mogelijkheden voor vervalsingen:
A) De afzender accountnaam kan zijn vervalst (immers alleen het afzenderdomein wordt gevalideerd);
B) Het account kan zijn gehacked;
C) De DKIM private key is gestolen ( d.w.z. kwaadwillenden hebber er een kopie van in handen gektrgeg(;.
D) DNS entries kunnen zijn gewijzigd door de spamners
E) DNS informatie ontvangen door de testende mailserver kan zijn gemanipuleerd;
F) De door jou vertouwde mailserver verdient dat vertrouwen niet;
[1] https://www.security.nl/posting/463813/Waarom+DMARC+(%2BSPF+%2BDKIM)
[2] https://www.security.nl/posting/450934/Personeel+Universiteit+Twente+trapt+in+phishingtest+studenten#posting450942
[3] https://www.security.nl/posting/471357/ICS+Phishing+spamrun
ALLES in een e-mail, inclusief headers, behalve Received: headers die bovenaan zijn toegevoegd door door jou vertrouwde mailservers, kan worden vervalst, en dat geldt ook voor DKIM headers [1].
M.a.w. bij spam is meestal het enige dat je kunt vertrouwen, het IP-adres waarvandaan de "verste" (bij jou vandaan), nog door jou vertrouwde mailserver, de e-mail kreeg aangeboden.
Met dat uitgangspunt in het achterhoofd kun je proberen vast te stellen wat er niet vervalst is in de e-mail:
1) Is de e-mail digitaal gesigneerd met PGP of S/MIME? Dat heb ik nog nooit gezien bij spam, maar spammers gaan dat ongetwijfeld een keer gebruiken. Zo ja, is de bijbehorende public key (ter verificatie van de digitale handtekening) aantoonbaar (check op PGP keyserver volstaat niet) van de kennelijke afzender, en is diens private key niet gejat?
2) Staat er een geldig SMTP afzenderadres achter "From:" (mail from dus, niet te verwarren met envelope from of return-path? Zo ja dan kun je checken of DMARC, voor het afzenderdomein, correct en afgedwongen, is ingericht.
3) Als er een DKIM header in staat moet je eerst checken of die is toegevoegd door een mailserver die geautoriseerd is om e-mail te verzenden namens het afzender domein in het SMTP adres achter From: (dat dan natuurlijk wel geldig moet zijn). Zie ook [1].
Zoals Anoniem van 02:29 hierboven schrijft is het bij spam gangbaar om het "Return-Path" (Envelope-From) te vervalsen. Dat wordt gedaan om ten minste de volgende redenen:
1) Een "account" waarop wordt geregistreerd welke spam niet kon worden afgeleverd (voor die domeinen die eerst elke mail aannemen en ergens daarna pas vaststellen of de mail kan worden afgeleverd);
2) Een willekeurig account (hoeft niet te bestaan) van een domain dat SPF records publiceert, dit omdat er suffe spamfilters bestaan waarvan de auteurs denken dat als SPF klopt, het niet om spam kan gaan (onzin natuurlijk);
3) De combinatie van bovenstaande 2 (voorbeeld: [2]).
Jouw accountnaam wordt vermoedelijk achterstevoren geschreven zodat deze niet door mensen zoals jij herkend wordt (faal in dit geval), en de spammers wellicht onvoldoende vertrouwen hebben in hun eigen hashtechnieken (en handmatig willen kunnen checken).
Overigens, als alles van SPF, DKIM en DMARC klopt (en de bijbehorende infornatie correct en volledig is (replay attacks zijn uitgesloten), de testende mailserver goed checkt), bestaan ten minste nog de volgende mogelijkheden voor vervalsingen:
A) De afzender accountnaam kan zijn vervalst (immers alleen het afzenderdomein wordt gevalideerd);
B) Het account kan zijn gehacked;
C) De DKIM private key is gestolen ( d.w.z. kwaadwillenden hebber er een kopie van in handen gektrgeg(;.
D) DNS entries kunnen zijn gewijzigd door de spamners
E) DNS informatie ontvangen door de testende mailserver kan zijn gemanipuleerd;
F) De door jou vertouwde mailserver verdient dat vertrouwen niet;
G) (aanvulling 23-05-2016, 08:59) De ontvanger weet niet exact welke afzenderdomeinen legitiem zijn of merkt een (minimaal) verschil niet op, zie bijv. de conclusie in [3] ("ics.nl, icscard.nl, icscards.nl, icscards.com, icscards.net, icscards.org, icscards.eu, icscards.ni, icscardonline.nl, icscardsonline.nl, icscard-online.nl, en icscards-online.nl" - wat is echt en wat is nep?)
H) (aanvulling 23-05-2016, 09:28) De vraag is hoe DMARC en/of DKIM, en de ontvanger indien deze hierop let, omgaan met incorrecte (message body-) From: velden. Een voorbeeld uit een drietal ransomware-emails van eind maart en begin april 2016:
From: "noreply@" <kpn.com noreply@kpn.com>
[1] https://www.security.nl/posting/463813/Waarom+DMARC+(%2BSPF+%2BDKIM)
[2] https://www.security.nl/posting/450934/Personeel+Universiteit+Twente+trapt+in+phishingtest+studenten#posting450942
[3] https://www.security.nl/posting/471357/ICS+Phishing+spamrun
24-05-2016, 21:38 door
Neo27
[Verwijderd]
Door Anoniem: Kan je de Emailclient (bijv.thunderbird,outlook oid) niet instellen dat hij elke mail die binnenkomt op broncode filter op juist dat returnpath adres waar je het hierboven over hebt ? Tenzij die gast niet elke mail van een ander return path voorziet kan je die mailtjes op die manier opvangen en kwijtraken. Thunderbird doet dit meestal vrij goed geloof ik. Misschien heb ik iets gemist van bovenstaand verhaal maar het is dus maar een idee..
Bedankt voor je reactie:
Heb geprobeerd een rule aan te maken in Outlook die op ReturnPath fileterd maar dit werkt niet zo best. Bij mijn provider kan ik helaas ook geen wildcards gebruiken in het email filter Webmail. Want dan zou ik het bij de de provider al tegen kunnen laten houden
iets van @mx?.*.com aangezien deze spammer steeds deze notatie gebruikt.
24-05-2016, 21:45 door
Neo27
Door Erik van Straten: Verstandig uitgangspunt (ook voor andere lezers met vergelijkbare problemen):
ALLES in een e-mail, inclusief headers, behalve Received: headers die bovenaan zijn toegevoegd door door jou vertrouwde mailservers, kan worden vervalst, en dat geldt ook voor DKIM headers [1].
M.a.w. bij spam is meestal het enige dat je kunt vertrouwen, het IP-adres waarvandaan de "verste" (bij jou vandaan), nog door jou vertrouwde mailserver, de e-mail kreeg aangeboden.
Met dat uitgangspunt in het achterhoofd kun je proberen vast te stellen wat er niet vervalst is in de e-mail:
1) Is de e-mail digitaal gesigneerd met PGP of S/MIME? Dat heb ik nog nooit gezien bij spam, maar spammers gaan dat ongetwijfeld een keer gebruiken. Zo ja, is de bijbehorende public key (ter verificatie van de digitale handtekening) aantoonbaar (check op PGP keyserver volstaat niet) van de kennelijke afzender, en is diens private key niet gejat?
2) Staat er een geldig SMTP afzenderadres achter "From:" (mail from dus, niet te verwarren met envelope from of return-path? Zo ja dan kun je checken of DMARC, voor het afzenderdomein, correct en afgedwongen, is ingericht.
3) Als er een DKIM header in staat moet je eerst checken of die is toegevoegd door een mailserver die geautoriseerd is om e-mail te verzenden namens het afzender domein in het SMTP adres achter From: (dat dan natuurlijk wel geldig moet zijn). Zie ook [1].
Zoals Anoniem van 02:29 hierboven schrijft is het bij spam gangbaar om het "Return-Path" (Envelope-From) te vervalsen. Dat wordt gedaan om ten minste de volgende redenen:
1) Een "account" waarop wordt geregistreerd welke spam niet kon worden afgeleverd (voor die domeinen die eerst elke mail aannemen en ergens daarna pas vaststellen of de mail kan worden afgeleverd);
2) Een willekeurig account (hoeft niet te bestaan) van een domain dat SPF records publiceert, dit omdat er suffe spamfilters bestaan waarvan de auteurs denken dat als SPF klopt, het niet om spam kan gaan (onzin natuurlijk);
3) De combinatie van bovenstaande 2 (voorbeeld: [2]).
Jouw accountnaam wordt vermoedelijk achterstevoren geschreven zodat deze niet door mensen zoals jij herkend wordt (faal in dit geval), en de spammers wellicht onvoldoende vertrouwen hebben in hun eigen hashtechnieken (en handmatig willen kunnen checken).
Overigens, als alles van SPF, DKIM en DMARC klopt (en de bijbehorende infornatie correct en volledig is (replay attacks zijn uitgesloten), de testende mailserver goed checkt), bestaan ten minste nog de volgende mogelijkheden voor vervalsingen:
A) De afzender accountnaam kan zijn vervalst (immers alleen het afzenderdomein wordt gevalideerd);
B) Het account kan zijn gehacked;
C) De DKIM private key is gestolen ( d.w.z. kwaadwillenden hebber er een kopie van in handen gektrgeg(;.
D) DNS entries kunnen zijn gewijzigd door de spamners
E) DNS informatie ontvangen door de testende mailserver kan zijn gemanipuleerd;
F) De door jou vertouwde mailserver verdient dat vertrouwen niet;
[1] https://www.security.nl/posting/463813/Waarom+DMARC+(%2BSPF+%2BDKIM)
[2] https://www.security.nl/posting/450934/Personeel+Universiteit+Twente+trapt+in+phishingtest+studenten#posting450942
[3] https://www.security.nl/posting/471357/ICS+Phishing+spamrun
ALLES in een e-mail, inclusief headers, behalve Received: headers die bovenaan zijn toegevoegd door door jou vertrouwde mailservers, kan worden vervalst, en dat geldt ook voor DKIM headers [1].
M.a.w. bij spam is meestal het enige dat je kunt vertrouwen, het IP-adres waarvandaan de "verste" (bij jou vandaan), nog door jou vertrouwde mailserver, de e-mail kreeg aangeboden.
Met dat uitgangspunt in het achterhoofd kun je proberen vast te stellen wat er niet vervalst is in de e-mail:
1) Is de e-mail digitaal gesigneerd met PGP of S/MIME? Dat heb ik nog nooit gezien bij spam, maar spammers gaan dat ongetwijfeld een keer gebruiken. Zo ja, is de bijbehorende public key (ter verificatie van de digitale handtekening) aantoonbaar (check op PGP keyserver volstaat niet) van de kennelijke afzender, en is diens private key niet gejat?
2) Staat er een geldig SMTP afzenderadres achter "From:" (mail from dus, niet te verwarren met envelope from of return-path? Zo ja dan kun je checken of DMARC, voor het afzenderdomein, correct en afgedwongen, is ingericht.
3) Als er een DKIM header in staat moet je eerst checken of die is toegevoegd door een mailserver die geautoriseerd is om e-mail te verzenden namens het afzender domein in het SMTP adres achter From: (dat dan natuurlijk wel geldig moet zijn). Zie ook [1].
Zoals Anoniem van 02:29 hierboven schrijft is het bij spam gangbaar om het "Return-Path" (Envelope-From) te vervalsen. Dat wordt gedaan om ten minste de volgende redenen:
1) Een "account" waarop wordt geregistreerd welke spam niet kon worden afgeleverd (voor die domeinen die eerst elke mail aannemen en ergens daarna pas vaststellen of de mail kan worden afgeleverd);
2) Een willekeurig account (hoeft niet te bestaan) van een domain dat SPF records publiceert, dit omdat er suffe spamfilters bestaan waarvan de auteurs denken dat als SPF klopt, het niet om spam kan gaan (onzin natuurlijk);
3) De combinatie van bovenstaande 2 (voorbeeld: [2]).
Jouw accountnaam wordt vermoedelijk achterstevoren geschreven zodat deze niet door mensen zoals jij herkend wordt (faal in dit geval), en de spammers wellicht onvoldoende vertrouwen hebben in hun eigen hashtechnieken (en handmatig willen kunnen checken).
Overigens, als alles van SPF, DKIM en DMARC klopt (en de bijbehorende infornatie correct en volledig is (replay attacks zijn uitgesloten), de testende mailserver goed checkt), bestaan ten minste nog de volgende mogelijkheden voor vervalsingen:
A) De afzender accountnaam kan zijn vervalst (immers alleen het afzenderdomein wordt gevalideerd);
B) Het account kan zijn gehacked;
C) De DKIM private key is gestolen ( d.w.z. kwaadwillenden hebber er een kopie van in handen gektrgeg(;.
D) DNS entries kunnen zijn gewijzigd door de spamners
E) DNS informatie ontvangen door de testende mailserver kan zijn gemanipuleerd;
F) De door jou vertouwde mailserver verdient dat vertrouwen niet;
G) (aanvulling 23-05-2016, 08:59) De ontvanger weet niet exact welke afzenderdomeinen legitiem zijn of merkt een (minimaal) verschil niet op, zie bijv. de conclusie in [3] ("ics.nl, icscard.nl, icscards.nl, icscards.com, icscards.net, icscards.org, icscards.eu, icscards.ni, icscardonline.nl, icscardsonline.nl, icscard-online.nl, en icscards-online.nl" - wat is echt en wat is nep?)
H) (aanvulling 23-05-2016, 09:28) De vraag is hoe DMARC en/of DKIM, en de ontvanger indien deze hierop let, omgaan met incorrecte (message body-) From: velden. Een voorbeeld uit een drietal ransomware-emails van eind maart en begin april 2016:
From: "noreply@" <kpn.com noreply@kpn.com>
[1] https://www.security.nl/posting/463813/Waarom+DMARC+(%2BSPF+%2BDKIM)
[2] https://www.security.nl/posting/450934/Personeel+Universiteit+Twente+trapt+in+phishingtest+studenten#posting450942
[3] https://www.security.nl/posting/471357/ICS+Phishing+spamrun
Erik heel erg bedankt voor je uitgebreide uitleg heb weer een hoop bij geleerd
24-05-2016, 21:53 door
Neo27
[Verwijderd]
24-05-2016, 21:53 door
Neo27
Door Anoniem: Kan je de Emailclient (bijv.thunderbird,outlook oid) niet instellen dat hij elke mail die binnenkomt op broncode filter op juist dat returnpath adres waar je het hierboven over hebt ? Tenzij die gast niet elke mail van een ander return path voorziet kan je die mailtjes op die manier opvangen en kwijtraken. Thunderbird doet dit meestal vrij goed geloof ik. Misschien heb ik iets gemist van bovenstaand verhaal maar het is dus maar een idee..
Bedankt voor je reactie ik kopieer de header info en de body uit het bericht (outlook 2010) in spamcop en krijg de volgende melding: No source IP address found, cannot proceed.
24-05-2016, 21:58 door
Neo27
Door Anoniem: Return-path is een header die een MTA kan toevoegen om zo duidelijk te maken wat de envelope sender was. De envelope sender wordt misbruikt door massa mailers (niet alleen spammers) om bounces te tracken.
Je moet weten dat Return-Path headers ook door spammers kunnen worden toegevoegd. Veel MTA's wissen die header en vervangen hem door het envelope sender adres.
De envelope sender is het email adres dat is gebruikt tijdens de SMTP sessie (MAIL FROM: <verzender@verzenddomein.tld>)
Over de spam zelf is ook iets te zeggen. Spammers registreren grote aantallen domeinen en gebruiken servers bij providers om hun massa mail te versturen. Die methode heet snowshoe spam. De method is heel "populair" in de Verenigde Staten. In Europa doen bedrijven ongeveer hetzelfde. Er worden email adressen gedeeld met bedrijven in andere landen en zo maken ze het moeilijker om anti-spam waakhonden er iets aan te doen.
Dit soort spammers gebruiken vaak SPF of DKIM om de illussie van vertrouwen te creeeren. Sommige domme filters denken dat email met SPF of DKIM betrouwbaar is. Dat is uiteraard niet zo, want degene die beschikking heeft over het domein kan zonder problemen de benodigde DNS records aanmaken.
Hoezo lukt het niet om deze spam bij Spamcop aan te melden? Wordt daar een reden voor gegeven?
Wat je er zelf aan kunt doen is zorgen dat je email adres niet handen komt van de spammers. Ze proberen emailadressen te verzamelen via reclame op sites om die te delen met "partners". Je doet mee aan een wedstrijd (sweepstake) met een makkelijke vraag om iets te winnen wat je graag wilt hebben. Een Mini of een iPhone bijvoorbeeld. Geef je email adres gewoon niet op. Ook niet op sites zoals consumeo en dergelijke. Die werken met de spammers samen.
De truuk die men toepast is dat het aantal partners oneindig is en als je unsubscribe gebruikt is het alleen voor 1 partner. Dat is uiteraard wettelijk niet in orde. Men moet bij opt in en in iedere email de gelegenheid bieden volledig uit te schrijven, ook bij die "partners". Zomaar persoonlijke gegevens delen met niet met naam en toenaam genoemde partners is overigens wettelijk ook niet ok.
Daarom is voorkomen beter dan genezen: deel je gegevens niet. Ook niet die van je auto (kenteken) en info voor verzekeringen.
Bedankt voor je reactie.Je moet weten dat Return-Path headers ook door spammers kunnen worden toegevoegd. Veel MTA's wissen die header en vervangen hem door het envelope sender adres.
De envelope sender is het email adres dat is gebruikt tijdens de SMTP sessie (MAIL FROM: <verzender@verzenddomein.tld>)
Over de spam zelf is ook iets te zeggen. Spammers registreren grote aantallen domeinen en gebruiken servers bij providers om hun massa mail te versturen. Die methode heet snowshoe spam. De method is heel "populair" in de Verenigde Staten. In Europa doen bedrijven ongeveer hetzelfde. Er worden email adressen gedeeld met bedrijven in andere landen en zo maken ze het moeilijker om anti-spam waakhonden er iets aan te doen.
Dit soort spammers gebruiken vaak SPF of DKIM om de illussie van vertrouwen te creeeren. Sommige domme filters denken dat email met SPF of DKIM betrouwbaar is. Dat is uiteraard niet zo, want degene die beschikking heeft over het domein kan zonder problemen de benodigde DNS records aanmaken.
Hoezo lukt het niet om deze spam bij Spamcop aan te melden? Wordt daar een reden voor gegeven?
Wat je er zelf aan kunt doen is zorgen dat je email adres niet handen komt van de spammers. Ze proberen emailadressen te verzamelen via reclame op sites om die te delen met "partners". Je doet mee aan een wedstrijd (sweepstake) met een makkelijke vraag om iets te winnen wat je graag wilt hebben. Een Mini of een iPhone bijvoorbeeld. Geef je email adres gewoon niet op. Ook niet op sites zoals consumeo en dergelijke. Die werken met de spammers samen.
De truuk die men toepast is dat het aantal partners oneindig is en als je unsubscribe gebruikt is het alleen voor 1 partner. Dat is uiteraard wettelijk niet in orde. Men moet bij opt in en in iedere email de gelegenheid bieden volledig uit te schrijven, ook bij die "partners". Zomaar persoonlijke gegevens delen met niet met naam en toenaam genoemde partners is overigens wettelijk ook niet ok.
Daarom is voorkomen beter dan genezen: deel je gegevens niet. Ook niet die van je auto (kenteken) en info voor verzekeringen.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.