Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
SPF hardfail: niet meer genoeg in mail in spambox te zetten?
09-04-2020, 17:24 door Anoniem, 24 reacties
Vandaag kwam in het nieuws dat er wordt gewaarschuwd voor mails van het ISZW [1].
De mails kwamen van @inspectie.nl.
Op die site, eigendom van een adviesbureau, staat inmiddels uitleg:
LET OP!!! Dit domein heeft NIETS te maken met inspectie SZW!!!
Op dit moment worden er mails verstuurd namens inspectie.nl welke niet door de eigenaar van dit domein worden verstuurd!!!
Klik NIET op een link in die mail!
De verzender misbruikt het domein inspectie.nl om mail te versturen, maar verstuurd deze mail niet via de server van inspectie.nl.
Daarom kunnen wij er niet meer aan doen dan we al gedaan hebben.
Het is namelijk vreemd dat deze mail er door komt omdat de verzendende server niet is opgenomen in het SPF record van het domein.
Personen die deze mail binnen krijgen kunnen wij adviseren hun spamdienst wat strakker te zetten zodat ze ook gebruik maken van SPF!
Hoewel wij er niets aan kunnen doen spijt het ons dat u er last van heeft!
Inspectie.nl
De SPF instellingen van dit domein: v=spf1 include:spf.protection.outlook.com ip4:<1 specifiek adres> -all
DKIM en DMARC ontbreken, maar op zich is SPF natuurlijk genoeg qua indicatie voor de ontvangende mailserver.
Die SPF geeft dus aan: hardfail.
Maar blijkbaar (getest op ook GMAIL) is een hardfail tegenwoordig niet meer afdoende om mail direct naar de spambox te zenden.
Wie kent de gedachtengang daarachter? Waarom zou je mailbeheerders lastig vallen met nog meer verplichtingen als ze SPF al netjes instellen?
[1] https://www.fraudehelpdesk.nl/alert/venijnig-voorbeeld-van-inhaken-op-de-corona-crisis-mail-zogenaamd-van-iszw/
De mails kwamen van @inspectie.nl.
Op die site, eigendom van een adviesbureau, staat inmiddels uitleg:
LET OP!!! Dit domein heeft NIETS te maken met inspectie SZW!!!
Op dit moment worden er mails verstuurd namens inspectie.nl welke niet door de eigenaar van dit domein worden verstuurd!!!
Klik NIET op een link in die mail!
De verzender misbruikt het domein inspectie.nl om mail te versturen, maar verstuurd deze mail niet via de server van inspectie.nl.
Daarom kunnen wij er niet meer aan doen dan we al gedaan hebben.
Het is namelijk vreemd dat deze mail er door komt omdat de verzendende server niet is opgenomen in het SPF record van het domein.
Personen die deze mail binnen krijgen kunnen wij adviseren hun spamdienst wat strakker te zetten zodat ze ook gebruik maken van SPF!
Hoewel wij er niets aan kunnen doen spijt het ons dat u er last van heeft!
Inspectie.nl
De SPF instellingen van dit domein: v=spf1 include:spf.protection.outlook.com ip4:<1 specifiek adres> -all
DKIM en DMARC ontbreken, maar op zich is SPF natuurlijk genoeg qua indicatie voor de ontvangende mailserver.
Die SPF geeft dus aan: hardfail.
Maar blijkbaar (getest op ook GMAIL) is een hardfail tegenwoordig niet meer afdoende om mail direct naar de spambox te zenden.
Wie kent de gedachtengang daarachter? Waarom zou je mailbeheerders lastig vallen met nog meer verplichtingen als ze SPF al netjes instellen?
[1] https://www.fraudehelpdesk.nl/alert/venijnig-voorbeeld-van-inhaken-op-de-corona-crisis-mail-zogenaamd-van-iszw/
Reacties (24)
gmail staat er om bekend dat ze hun regels voortdurend veranderen en dat je daar als klant totaal geen invloed op hebt.
wat je als klant wel kunt doen is je gmail account opheffen en een fatsoenlijke provider kiezen.
wat je als klant wel kunt doen is je gmail account opheffen en een fatsoenlijke provider kiezen.
En zie hier het gevaar van clouddiensten, een simpel outlook.com account is al voldoende om vanaf 1 van de servers te mailen die valt onder spf.protection.outlook.com. Dan maakt het niet meer uit of het een softfail of hardfail is, het komt vanaf een geautoriseerde server. Als er verder geen checks bij Microsoft zijn die controleert of de headers correct zijn dan is spoofen niet lastig meer.
Door Anoniem: En zie hier het gevaar van clouddiensten, een simpel outlook.com account is al voldoende om vanaf 1 van de servers te mailen die valt onder spf.protection.outlook.com. Dan maakt het niet meer uit of het een softfail of hardfail is, het komt vanaf een geautoriseerde server. Als er verder geen checks bij Microsoft zijn die controleert of de headers correct zijn dan is spoofen niet lastig meer.
Die moet je toch even uitleggen hoor. Hoe verstuur je dan een mail van iets@inspectie.nl via outlook.com, zodat deze onder spf.protection.outlook.com valt? Volgens mij moet je dan namelijk eerst bij Office 365 bewijzen dat het domein inspectie.nl onder jouw beheer valt.
E-mail gebruikt, net als papieren brieven, een envelop met daarin de brief zelf. Een verschil is dat e-mailprogramma's nooit zomaar de envelop laten zien (soms kan dat met "view headers" o.i.d.), hooguit (zelfs dat niet altijd) tonen e-mailprogramma's het SMTP afzenderadres zoals gespecificeerd op het briefpapier (in de e-mail zelf dus).
Net zoals bij papieren post kan het afzenderadres op de envelop verschillen van het afzenderadres op het briefpapier.
Een ontvangende mailserver -die op SPF checkt- zal niet naar informatie in "de brief" kijken, maar slechts naar de envelop, en naar het IP-adres van het systeem dat op dat moment de e-mail aanbiedt. Om precies te zijn, als het afzenderadres op de envelop (het retouradres, ook bekend als Return Path) bijv. maaktnietuit@inspectie.nl luidt, zal de ontvangende mailserver kijken of er een SPF record in DNS bestaat voor inpectie.nl. En zo ja, welke IP-adressen namens inspectie.nl e-mail mogen verzenden.
Echter, als de afzenderadressen er als volgt uitzien (met "getoond-From" bedoel ik de afzender op het briefpapier):
dan kijkt geen enkele ontvangende mailserver naar het DNS SPF record van inspectie.nl (ontvangende mailservers die op SPF checken, zullen een DNS SPF record voor example.com opvragen - d.w.z het door de spammers gespecificeerde envelop-afzenderdomein). Spammers schrikken er zelden voor terug om domeinen te registreren (example.com dient hier als voorbeeld, elke willekeurige domeinnaam voldoet voor dit soort spam).
Als inspectie.nl de kans flink wil verkleinen dat hun getoonde domeinnaam wordt misbruikt, moet zij tevens een DMARC record in DNS publiceren. Daarmee kun je afdwingen dat het afzenderdomein in de envelop hetzelfde is als het (meestal) getoonde afzenderdomein, terwijl je met SPF blijft afdwingen van welke IP-addressen er mail namens dat domein verzonden mag worden.
Met andere woorden, stel:
Dan checkt:
1) SPF of 93.184.216.34 e-mail mag zenden namens inspectie.nl uit de envelop;
2) DMARC of het afzenderdomeinen op de envelop identiek is aan het aan de ontvanger getoonde afzenderdomein (waar trouwens ook een eventuele reply naar toe gaat, tenzij er tevens een Reply-To: adres is gespecificeerd).
Aangezien 93.184.216.34 (het IP-adres van example.com) geen mail mag zenden namens inspectie.nl, zal, bij de juiste configuratie van de SPF- en DMARC records in DNS, de mail worden geblokkeerd.
Voor meer info zie https://www.security.nl/posting/650630/RIVM+en+Rijksoverheid+waren+kwetsbaar+voor+e-mailspoofing#posting650643 en daaronder.
P.S. ik heb geen e-mail headers van zo'n spam gezien, uit de beschrijving van de TS maak ik op dat aan de hand kan zijn wat ik beschrijf. Er zou natuurlijk ook een account of (thuis-) PC van een medewerker van inpectie.nl gehacked kunnen zijn, in dat geval zou de spam wel bij hen (c.q. hun cloudprovider) vandaan kunnen komen.
Net zoals bij papieren post kan het afzenderadres op de envelop verschillen van het afzenderadres op het briefpapier.
Een ontvangende mailserver -die op SPF checkt- zal niet naar informatie in "de brief" kijken, maar slechts naar de envelop, en naar het IP-adres van het systeem dat op dat moment de e-mail aanbiedt. Om precies te zijn, als het afzenderadres op de envelop (het retouradres, ook bekend als Return Path) bijv. maaktnietuit@inspectie.nl luidt, zal de ontvangende mailserver kijken of er een SPF record in DNS bestaat voor inpectie.nl. En zo ja, welke IP-adressen namens inspectie.nl e-mail mogen verzenden.
Echter, als de afzenderadressen er als volgt uitzien (met "getoond-From" bedoel ik de afzender op het briefpapier):
envelop-From: maaktnietuit@example.com
getoond-From: maaktnietuit@inspectie.nl
getoond-From: maaktnietuit@inspectie.nl
Als inspectie.nl de kans flink wil verkleinen dat hun getoonde domeinnaam wordt misbruikt, moet zij tevens een DMARC record in DNS publiceren. Daarmee kun je afdwingen dat het afzenderdomein in de envelop hetzelfde is als het (meestal) getoonde afzenderdomein, terwijl je met SPF blijft afdwingen van welke IP-addressen er mail namens dat domein verzonden mag worden.
Met andere woorden, stel:
Een mailserver ontvangt mail van IP-adres 93.184.216.34
envelop-From: maaktnietuit@inspectie.nl
getoond-From: maaktnietuit@inspectie.nl
envelop-From: maaktnietuit@inspectie.nl
getoond-From: maaktnietuit@inspectie.nl
1) SPF of 93.184.216.34 e-mail mag zenden namens inspectie.nl uit de envelop;
2) DMARC of het afzenderdomeinen op de envelop identiek is aan het aan de ontvanger getoonde afzenderdomein (waar trouwens ook een eventuele reply naar toe gaat, tenzij er tevens een Reply-To: adres is gespecificeerd).
Aangezien 93.184.216.34 (het IP-adres van example.com) geen mail mag zenden namens inspectie.nl, zal, bij de juiste configuratie van de SPF- en DMARC records in DNS, de mail worden geblokkeerd.
Voor meer info zie https://www.security.nl/posting/650630/RIVM+en+Rijksoverheid+waren+kwetsbaar+voor+e-mailspoofing#posting650643 en daaronder.
P.S. ik heb geen e-mail headers van zo'n spam gezien, uit de beschrijving van de TS maak ik op dat aan de hand kan zijn wat ik beschrijf. Er zou natuurlijk ook een account of (thuis-) PC van een medewerker van inpectie.nl gehacked kunnen zijn, in dat geval zou de spam wel bij hen (c.q. hun cloudprovider) vandaan kunnen komen.
Door Erik van Straten: E-mail gebruikt, net als papieren brieven, een envelop met daarin de brief zelf. ... enz.
Dank U voor deze (voor mij heldere) "jip & janneke" uitleg.
Ps.: ik ben niet de TS.
10-04-2020, 10:00 door
Briolet
Door Anoniem: Die SPF geeft dus aan: hardfail.
Maar blijkbaar (getest op ook GMAIL) is een hardfail tegenwoordig niet meer afdoende om mail direct naar de spambox te zenden.
Wie kent de gedachtengang daarachter? Waarom zou je mailbeheerders lastig vallen met nog meer verplichtingen als ze SPF al netjes instellen?
Maar blijkbaar (getest op ook GMAIL) is een hardfail tegenwoordig niet meer afdoende om mail direct naar de spambox te zenden.
Wie kent de gedachtengang daarachter? Waarom zou je mailbeheerders lastig vallen met nog meer verplichtingen als ze SPF al netjes instellen?
Uit jouw link is nergens op te maken dat de mails van 'inspectie.nl" komen. Als ik de gegeven voorbeelden doorlees, vind ik alleen voorbeelden met afzender "Inspectie SZW". Dat is altijd al zelf in te stellen geweest en gewoon nalatig van de gebruikers om niet naar de echte afzender te kijken.
Verder kan het zijn dat de SPF toch geen fail geeft want de gewone SPF test niet op de leesbare afzender, maar op de enveloppe afzender, zoals Erik hierboven schrijft. Deze slechte SPF test is ooit ingevoerd om het mailingbedrijven gemakkelijker te maken om mail namens hun klanten te kunnen versturen.
En als er echt een hard fail doorgelaten wordt, is dat misschien toch de angst om goede mail tegen te houden en daardoor boze gebruikers te krijgen. Er zijn gewoon veel mensen die hun mail slecht configureren. Als wij een mailing versturen krijgen we van google de statistieken over de mail naar een google mailbox. Ongeveer de helft van de mail geeft een SPF fail. Allemaal veroorzaakt doordat mensen hun mail forwarden naar een GMail mailbox. Maar dat forwarden doen ze fout waardoor de oude afzender als afzender van de geforwarde mail blijft staan. Met een hard fail instelling en dmarc instelling zou deze mail bouncen.
Overigens een terechte bounce in mijn opinie.
Door Briolet:
En als er echt een hard fail doorgelaten wordt, is dat misschien toch de angst om goede mail tegen te houden en daardoor boze gebruikers te krijgen. Er zijn gewoon veel mensen die hun mail slecht configureren.
Dit is kennelijk weer veranderd door google want er zijn tijden geweest dat ze er bij google totaal geen probleem meeEn als er echt een hard fail doorgelaten wordt, is dat misschien toch de angst om goede mail tegen te houden en daardoor boze gebruikers te krijgen. Er zijn gewoon veel mensen die hun mail slecht configureren.
hadden om goede mail weg te gooien als spam. En dan te scoren met het feit dat er geen spam in de mailbox kwam.
Wellicht heeft dat op een gegeven moment toch te veel klachten opgeleverd.
(hoewel het me onduidelijk is hoe je überhaupt klachten naar google zou kunnen sturen, wellicht "via de media" ofzo?)
Als wij een mailing versturen krijgen we van google de statistieken over de mail naar een google mailbox. Ongeveer de helft van de mail geeft een SPF fail. Allemaal veroorzaakt doordat mensen hun mail forwarden naar een GMail mailbox. Maar dat forwarden doen ze fout waardoor de oude afzender als afzender van de geforwarde mail blijft staan. Met een hard fail instelling en dmarc instelling zou deze mail bouncen.
Overigens een terechte bounce in mijn opinie.
Ik zit eens te kijken in de DMARC rua logs en ik zie nu dat google al maanden lang een mail meer quarantined heeft, zelfsOverigens een terechte bounce in mijn opinie.
niet als zowel DKIM als SPF een fail geven. Kennelijk is dat weer uitgefaseerd ofzo, vroeger zag ik nog wel eens
quarantined mail. Kennelijk worden er nu ook weer andere metrics bij gevoegd en wordt DMARC niet meer als
absoluut gehanteerd. Waarschijnlijk komt een legitiem uitziende mail er nu altijd wel door.
Die mensen van inspectie.nl (ik heb al weinig medelijden met iemand die zo'n domein registreert en het vervolgens ook
nog eens niet actief gebruikt) doen net of ze alles gedaan hebben maar inderdaad zit er geen DMARC op dus wellicht
ook geen DKIM. Dit kan tegenwoordig wel bij outlook.com maar ze listen ook hun eigen server bij plesk dus wellicht
stuurt die ook wel eens mail, en dan moeten ze zelf dus ook aan de slag op hun server. Dat is ze kennelijk teveel
moeite.
Probleem is natuurlijk ook dat je wel kunt roepen "dan hadden ze maar DMARC moeten doen" maar ja morgen is er
wellicht weer een andere hoepel waar ze doorheen hadden moeten springen.
@Erik van Straten: bedankt voor de heldere uitleg.
In de voorbeelden op de site staat zoals @Briolet aangeeft "Inspectie SWZ" als afzender. Samen met jouw voorbeeld wordt dit in mijn mail client zichtbaar als: Inspectie SWZ <maaktnietuit@example.com>
Dus de oplettende lezer heeft dan waarschijnlijk wel door dat het niet pluis is.
Wel bizar dat Google dit niet in je spam folder aflevert. In de beschrijving van het SPF (RFC 7208, zie: https://tools.ietf.org/html/rfc7208) vond ik het volgende:
In de voorbeelden op de site staat zoals @Briolet aangeeft "Inspectie SWZ" als afzender. Samen met jouw voorbeeld wordt dit in mijn mail client zichtbaar als: Inspectie SWZ <maaktnietuit@example.com>
Dus de oplettende lezer heeft dan waarschijnlijk wel door dat het niet pluis is.
Wel bizar dat Google dit niet in je spam folder aflevert. In de beschrijving van het SPF (RFC 7208, zie: https://tools.ietf.org/html/rfc7208) vond ik het volgende:
If the checking software chooses not to reject the mail during the
SMTP transaction, then it SHOULD add a Received-SPF or
Authentication-Results header field (see Section 9) to communicate
this result to downstream message processors. While this is true for
all SPF results, it is of particular importance for "fail" results
since the message is explicitly not authorized by the ADMD.
SMTP transaction, then it SHOULD add a Received-SPF or
Authentication-Results header field (see Section 9) to communicate
this result to downstream message processors. While this is true for
all SPF results, it is of particular importance for "fail" results
since the message is explicitly not authorized by the ADMD.
Door Anoniem: @Erik van Straten: bedankt voor de heldere uitleg.
In de voorbeelden op de site staat zoals @Briolet aangeeft "Inspectie SWZ" als afzender. Samen met jouw voorbeeld wordt dit in mijn mail client zichtbaar als: Inspectie SWZ <maaktnietuit@example.com>
Wat heb jij voor mail client dan?? Ik ken geen mail clients die dat doen, alle mij bekende mail clients tonen ofwelIn de voorbeelden op de site staat zoals @Briolet aangeeft "Inspectie SWZ" als afzender. Samen met jouw voorbeeld wordt dit in mijn mail client zichtbaar als: Inspectie SWZ <maaktnietuit@example.com>
alleen Inspectie SWZ ofwel Inspectie SWZ <maaktnietuit@inspectie.nl> in het voorbeeld wat Erik geeft!
Dus de oplettende lezer heeft dan waarschijnlijk wel door dat het niet pluis is.
Ja als ie jouw mail client heeft. Maar dat komt vast niet vaak voor.
10-04-2020, 12:18 door
Erik van Straten
Door Anoniem: Dank U voor deze (voor mij heldere) "jip & janneke" uitleg.
Graag gedaan!Door Anoniem: Probleem is natuurlijk ook dat je wel kunt roepen "dan hadden ze maar DMARC moeten doen" maar ja morgen is er wellicht weer een andere hoepel waar ze doorheen hadden moeten springen.
Eens, maar een pagina als http://inspectie.nl/ tuig je alleen op als je veel boze reacties krijgt. Als je dat niet wilt kun je, desgewenst, door een hoepel springen.Aangezien inspectie.nl geen domein is van ISZW (net zo min als iszw.nl trouwens; je moet toevallig maar weten dat dit inspectieszw.nl is), zou je ALLE domeinen waarvan e-mailontvangers kunnen denken dat deze van ISZW zijn, met DMARC plus SPF en/of DKIM moeten dichttimmeren om te voorkomen dat die e-mailontvangers onterecht denken dat een ontvangen e-mail daadwerkelijk verzonden is door ISZW. En dat is natuurlijk een kansloze operatie, alleen al voor ISZW; laat staan voor alle domeinnamen die we moeten kunnen vertrouwen.
Een veelgemaakte fout bij informatiebeveiliging is ervan uitgaan dat als jij redelijkerwijs aantoont dat jouw informatie authentiek is, dat anderen dan niet in staat zullen zijn om informatie te produceren die (bijna) net zo authentiek door jou geproduceerd lijkt. Dat onmogelijk maken is meestal veel lastiger dan authenticiteit bewijzen.
Daar komt bij dat e-mailontvangers geen idee hebben welke onzichtbare maatregelen beheerders van mailservers hebben getroffen en/of wanneer ze hier wijzigingen in aanbrengen (zoals duidelijk is uit de discussie). Daarom vrees ik dat er niks anders opzit dan mensen (die het willen horen) te vertellen dat je een getoond afzenderadres niet kunt vertrouwen - tenzij je e-mail headers bekijkt en weet hoe je die moet interpreteren, en weet welke checks er gedaan moeten zijn en door wie.
Door Anoniem: Samen met jouw voorbeeld wordt dit in mijn mail client zichtbaar als: Inspectie SWZ <maaktnietuit@example.com>
Nee, zolang inspectie.nl geen restrictief DMARC DNS record publiceert, kun jij in jouw mail programma zien:Inspectie SWZ <inspectorgadget@inspectie.nl> (waarbij "inspectorgadget" vanalles kan zijn, ook een bestaand account)
terwijl in de envelop een ander afzenderdomein gebruikt is. Dat weet ik nagenoeg zeker, anders zou niet op http://inspectie.nl/ te lezen zijn wat er nu staat. Dat is een voorspelbare reactie op e-mails van boze gebruikers die op Reply/Antwoorden drukken en inspectie.nl beschuldigen van spammen.
Door Erik van Straten:
Daar komt bij dat e-mailontvangers geen idee hebben welke onzichtbare maatregelen beheerders van mailservers hebben getroffen en/of wanneer ze hier wijzigingen in aanbrengen (zoals duidelijk is uit de discussie). Daarom vrees ik dat er niks anders opzit dan mensen (die het willen horen) te vertellen dat je een getoond afzenderadres niet kunt vertrouwen - tenzij je e-mail headers bekijkt en weet hoe je die moet interpreteren, en weet welke checks er gedaan moeten zijn en door wie.
Inderdaad! En ook dat je je mail provider niet kunt vertrouwen, en meer in het algemeen: dat je mail niet meer kunt vertrouwen. Want door al die spamfilter maatregelen wordt een steeds groter deel van de legitieme mail niet afgeleverd.Daar komt bij dat e-mailontvangers geen idee hebben welke onzichtbare maatregelen beheerders van mailservers hebben getroffen en/of wanneer ze hier wijzigingen in aanbrengen (zoals duidelijk is uit de discussie). Daarom vrees ik dat er niks anders opzit dan mensen (die het willen horen) te vertellen dat je een getoond afzenderadres niet kunt vertrouwen - tenzij je e-mail headers bekijkt en weet hoe je die moet interpreteren, en weet welke checks er gedaan moeten zijn en door wie.
Tot voor een paar maanden was het wel haast onmogelijk om mail bij gmail afgeleverd te krijgen zonder DKIM en met een SPF record wat ~all vermeldt, nu is het ineens weer onnodig om dit op te tuigen kennelijk , nu zullen ze wel weer wat anders doen.
"ik heb u een mail gestuurd dus die moet u hebben ontvangen" dat was al nooit zo (mail is net als post een best-effort systeem) maar het komt tegenwoordig steeds vaker voor dat volkomen legitieme mail onderweg wordt weggegooid.
En dat is een duidelijk geval van het kind met het badwater weggooien als je ziet dat phishing mail er evengoed wel doorkomt.
Door Erik van Straten:
Inspectie SWZ <inspectorgadget@inspectie.nl>
Zijn er dan mail clients die wat ze tonen aan de gebruiker baseren op de beschikbaarheid van een DMARC record???Door Anoniem: Samen met jouw voorbeeld wordt dit in mijn mail client zichtbaar als: Inspectie SWZ <maaktnietuit@example.com>
Nee, zolang inspectie.nl geen restrictief DMARC DNS record publiceert, kun jij in jouw mail programma zien:Inspectie SWZ <inspectorgadget@inspectie.nl>
Ik zou denken dat dit alleen bepaalt of je mail in je INBOX of in je Spam map of helemaal nergens terecht komt, maar
niet bepaalt hoe een mail die je geopend hebt getoond wordt aan de gebruiker. Dat gedrag ken ik in ieder geval niet,
hier wordt gewoon de waarde van de From: header getoond wat daar ook in staat.
(het spamfilter bekijkt uiteraard wel of de From header afwijkt van de envelope from en kent daar punten aan toe)
Door Anoniem: Zijn er dan mail clients die wat ze tonen aan de gebruiker baseren op de beschikbaarheid van een DMARC record???
Nee natuurlijk niet.Ik probeer het stapsgewijs uit te leggen aan de hand van een transactie tussen een zendende mailserver (dat kan ook een zombie-PC zijn die staat te spammen) en een mailserver voor example.com waar jij een e-mail account hebt. Ik gebruik hierbij in de envelop (dat is tot en met "DATA") enkele gegevens van een spam die ik gisteren ontving:
== Zendende mailserver of zombie-PC ===||===== Ontvangende mailserver ======
----------------------------------------------------------------------------
(maakt verbinding) -> ah, we hebben een mailer
<- je mailt met mail.example.com
----------------------------------------------------------------------------
Hoi, met slap.pcgaboma.com -> dat zou kunnen, ik zie dat
217.112.128.177 jouw IP adres is
Vraagt aan DNS server:
Wat is PTR van 217.112.128.177?
Antwoord: slap.kranbery.com
Hmm, vreemd maar OK
Ik zet dit wel ff in een header
zodat spam-hunters verder kunnen
onderzoeken (zie tekst verderop)
<- Hoi slap.pcgaboma.com
----------------------------------------------------------------------------
MAIL FROM: <raffmwywqfn@pcgaboma.com> -> domein is dus pcgaboma.com
Vraagt aan DNS: bestaat er een SPF
record voor pcgaboma.com?
Jazeker: "v=spf1 a mx
ip4:63.82.48.0/24
ip4:63.82.50.245
ip4:63.82.50.246
ip4:63.82.50.247
ip4:63.82.50.248
ip4:63.82.50.249 ~all"
Hmm, 217.112.128.177 staat niet
in die lijst, maar die "~all" op
het einde dwingt dit niet af.
Dus accepteer ik dit maar
<- Sender OK
----------------------------------------------------------------------------
RCPT TO: <jou@example.com> -> ff checken, bestaat die? Ja,
gevonden. Mailbox is ook niet vol.
<- Recipient OK
----------------------------------------------------------------------------
DATA -> OK, slechts 1 ontvanger op de
envelop.
<- Stuur een lege regel, een punt en
nog een lege regel om aan te
duiden dat je alles gestuurd hebt.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
(maakt verbinding) -> ah, we hebben een mailer
<- je mailt met mail.example.com
----------------------------------------------------------------------------
Hoi, met slap.pcgaboma.com -> dat zou kunnen, ik zie dat
217.112.128.177 jouw IP adres is
Vraagt aan DNS server:
Wat is PTR van 217.112.128.177?
Antwoord: slap.kranbery.com
Hmm, vreemd maar OK
Ik zet dit wel ff in een header
zodat spam-hunters verder kunnen
onderzoeken (zie tekst verderop)
<- Hoi slap.pcgaboma.com
----------------------------------------------------------------------------
MAIL FROM: <raffmwywqfn@pcgaboma.com> -> domein is dus pcgaboma.com
Vraagt aan DNS: bestaat er een SPF
record voor pcgaboma.com?
Jazeker: "v=spf1 a mx
ip4:63.82.48.0/24
ip4:63.82.50.245
ip4:63.82.50.246
ip4:63.82.50.247
ip4:63.82.50.248
ip4:63.82.50.249 ~all"
Hmm, 217.112.128.177 staat niet
in die lijst, maar die "~all" op
het einde dwingt dit niet af.
Dus accepteer ik dit maar
<- Sender OK
----------------------------------------------------------------------------
RCPT TO: <jou@example.com> -> ff checken, bestaat die? Ja,
gevonden. Mailbox is ook niet vol.
<- Recipient OK
----------------------------------------------------------------------------
DATA -> OK, slechts 1 ontvanger op de
envelop.
<- Stuur een lege regel, een punt en
nog een lege regel om aan te
duiden dat je alles gestuurd hebt.
----------------------------------------------------------------------------
BELANGRIJK: onderstaande info is niet afkomstig uit de spam die ik ontving! Dit is een voorbeeld van hoe spam namens inspectie.nl er uit zou kunnen zien (merk op dat de mailserver pas antwoord geeft als de hele "brief" binnen is):
== Zendende mailserver of zombie-PC ===||===== Ontvangende mailserver ======
----------------------------------------------------------------------------
From: "Inspectie SWZ" (dit is 1 regel maar dat paste hier niet)
<inspectorgadget@inspectie.nl> -> domein is dus inspectie.nl
Vraag aan DNS: bestaat er een DMARC
record voor inspectie.nl?
DNS antwoord: nee.
ZIE DE TEKST VERDEROP VOOR ALS ER
WEL EEN DMARC RECORD HAD BESTAAN
----------------------------------------------------------------------------
To: "undisclosed-recipients:;" -> Whatever, ik lever mail sowieso
alleen af op e-mailadres(sen) op
de envelop
----------------------------------------------------------------------------
Date: Fri, 10 Apr 2029 12:34:56 +0600 -> Ah, een tijdreiziger.
Ook daar bemoei ik mij niet mee
----------------------------------------------------------------------------
Subject: factuur -> Dit zou ik als spam kunnen taggen
----------------------------------------------------------------------------
Klik hier voor uw factuur -> Dit zou ik als spam kunnen taggen
----------------------------------------------------------------------------
<lege regel> -> ah, een lege regel
. -> gevolgd door een punt
<lege regel> -> gevolgd door nog een lege regel
<- Dank voor jouw mail en de groeten
----------------------------------------------------------------------------
----------------------------------------------------------------------------
From: "Inspectie SWZ" (dit is 1 regel maar dat paste hier niet)
<inspectorgadget@inspectie.nl> -> domein is dus inspectie.nl
Vraag aan DNS: bestaat er een DMARC
record voor inspectie.nl?
DNS antwoord: nee.
ZIE DE TEKST VERDEROP VOOR ALS ER
WEL EEN DMARC RECORD HAD BESTAAN
----------------------------------------------------------------------------
To: "undisclosed-recipients:;" -> Whatever, ik lever mail sowieso
alleen af op e-mailadres(sen) op
de envelop
----------------------------------------------------------------------------
Date: Fri, 10 Apr 2029 12:34:56 +0600 -> Ah, een tijdreiziger.
Ook daar bemoei ik mij niet mee
----------------------------------------------------------------------------
Subject: factuur -> Dit zou ik als spam kunnen taggen
----------------------------------------------------------------------------
Klik hier voor uw factuur -> Dit zou ik als spam kunnen taggen
----------------------------------------------------------------------------
<lege regel> -> ah, een lege regel
. -> gevolgd door een punt
<lege regel> -> gevolgd door nog een lege regel
<- Dank voor jouw mail en de groeten
----------------------------------------------------------------------------
Met andere woorden, een DMARC record heeft geen effect op wat jouw e-mailprogramma toont, maar bepaalt wat een mailserver (de postbode zeg maar) doet met een e-mail.
M.b.t. de header die bij de spam werd toegevoegd, deze luidde (waarbij ik mijn e-mail adres heb vervangen door "<verwijderd>"):
Received: from slap.pcgaboma.com (slap.kranbery.com [217.112.128.177])
by mxdrop302.xs4all.net (8.14.9/8.14.9/Debian-xs4all~5) with ESMTP id
039E6GUP030593 for <verwijderd>; Thu, 9 Apr 2020 16:06:18 +0200
by mxdrop302.xs4all.net (8.14.9/8.14.9/Debian-xs4all~5) with ESMTP id
039E6GUP030593 for <verwijderd>; Thu, 9 Apr 2020 16:06:18 +0200
Nadat de spam die ik ontving binnen was, voegde de XS4All mailserver de volgende header toe boven bovenstaande header:
Authentication-Results: xs4all.nl; spf=softfail smtp.mailfrom=pcgaboma.com;
dkim=pass header.i=raffmwywqfn@pcgaboma.com; dkim=pass
header.d=pcgaboma.com; dmarc=pass header.from=pcgaboma.com
dkim=pass header.i=raffmwywqfn@pcgaboma.com; dkim=pass
header.d=pcgaboma.com; dmarc=pass header.from=pcgaboma.com
Door Erik van Straten:
Inspectie SWZ <inspectorgadget@inspectie.nl> (waarbij "inspectorgadget" vanalles kan zijn, ook een bestaand account)
terwijl in de envelop een ander afzenderdomein gebruikt is. Dat weet ik nagenoeg zeker, anders zou niet op http://inspectie.nl/ te lezen zijn wat er nu staat. Dat is een voorspelbare reactie op e-mails van boze gebruikers die op Reply/Antwoorden drukken en inspectie.nl beschuldigen van spammen.
Door Anoniem: Samen met jouw voorbeeld wordt dit in mijn mail client zichtbaar als: Inspectie SWZ <maaktnietuit@example.com>
Nee, zolang inspectie.nl geen restrictief DMARC DNS record publiceert, kun jij in jouw mail programma zien:Inspectie SWZ <inspectorgadget@inspectie.nl> (waarbij "inspectorgadget" vanalles kan zijn, ook een bestaand account)
terwijl in de envelop een ander afzenderdomein gebruikt is. Dat weet ik nagenoeg zeker, anders zou niet op http://inspectie.nl/ te lezen zijn wat er nu staat. Dat is een voorspelbare reactie op e-mails van boze gebruikers die op Reply/Antwoorden drukken en inspectie.nl beschuldigen van spammen.
Je hebt helemaal gelijk. Wat ik beschreef geldt alleen als er in de message body geen From: veld voorkomt. Alleen dan zie je de envelope MAIL FROM waarde. Weer wat geleerd.
Nog even terugkomend op de actie door een mail cliënt. Deze kan geen DMARC checken omdat hij niet betrouwbaar DKIM kan checken. DKIM kan alleen correct door de mailserver zelf gecontroleerd worden.
Een mailserver kan nml de mail aanpassen bij binnenkomst zodat de DKIM niet meer klopt als hij in de inbox beland. Denk b.v. aan een spamwaarschuwing toevoegen aan de titel. Of het verwijderen van trackers, executable attachents etc. uit de mail, wat sommige mailservers kunnen doen.
Een mailserver kan nml de mail aanpassen bij binnenkomst zodat de DKIM niet meer klopt als hij in de inbox beland. Denk b.v. aan een spamwaarschuwing toevoegen aan de titel. Of het verwijderen van trackers, executable attachents etc. uit de mail, wat sommige mailservers kunnen doen.
11-04-2020, 01:13 door
Erik van Straten
Door Anoniem: Wat ik beschreef geldt alleen als er in de message body geen From: veld voorkomt. Alleen dan zie je de envelope MAIL FROM waarde.
Hmm, ik kan me inderdaad niet herinneren ooit een e-mail gezien te hebben zonder header-From: veld.Test met verwijderen From: regel in Thunderbird
Als ik een e-mail uit Thunderbird naar m'n desktop sleep (kopieer), het bestand open met notepad, de From: regel verwijder, het bestand opsla en terugsleep (kopieer) naar mijn inbox Thunderbird, dan zie ik een leegte in de kolom From. Als ik die mail open, is de plaats waar normaal gesproken From: staat, leeg.
Als ik vervolgens webmail open (https://roundcube.xs4all.nl/) staat diezelfde mail daar ook (dankzij IMAP), maar ook daar is het From: veld leeg (zowel in de lijst met mails als na openen). In elk geval Thunderbird en Roundcube voegen dus niet zo'n regel toe.
Test zenden e-mail zonder From: regel
Maar je hebt gelijk! Ik heb met PuTTY ingelogd op shell.xs4all.nl en met telnet (naar poort 25 van een xs4all mailserver) mezelf een e-mail gestuurd zonder daarin een header-From: te specificeren. Tot mijn verrassing kwam de mail binnen met in header-From een kopie van envelope-From!
Niet alleen jij hebt wat geleerd... :-)
Ik weet alleen niet welke mailserver die regel heeft toegevoegd (de server waar ik naar telnette, of de server die de mail aan mijn inbox toevoegde). Overigens verwacht ik niet dat spammers het From: veld vaak leeg zullen laten.
Test zenden e-mail zonder From: regel en met MAIL FROM: <>
Tweede test met MAIL FROM: <> en geen From: regel (opnieuw gebruikmakend van telnet): zo kun je dus ook mailen (niks klaagt, mail komt aan). Daarbij ontbreekt de From: regel in de body (het DATA deel) nu wel geheel.
Mail met e-mail adres achter From: regel met MAIL FROM: <>
Niet getest maar dit werkt ongetwijfeld: MAIL FROM: <> en From: inspectorgadget@inspectie.nl. Daardoor kan er geen SPF check worden uitgevoerd, en zolang inspectie.nl geen restrictief DMARC record publiceert, zal hooguit een spamfilter de mail tegenhouden of taggen vanwege het ontbreken van een Return-Path in combinatie met de inhoud van de mail.
Regels in de tekst die met "From" beginnen
@Briolet of iemand anders die dit weet: als ergens in de body van de mail de auteur een regel met From heeft laten beginnen, ziet de ontvanger meestal dat "iets" daar > From van gemaakt heeft (in elk geval in platte-tekst-mails). Weet jij toevallig wie dat doet? D.w.z. als dat gebeurt nadat de DKIM signature is gezet, de ontvangende mailserver bijvoorbeeld, wordt die signature natuurlijk ongeldig.
Door Erik van Straten:
@Briolet of iemand anders die dit weet: als ergens in de body van de mail de auteur een regel met From heeft laten beginnen, ziet de ontvanger meestal dat "iets" daar > From van gemaakt heeft (in elk geval in platte-tekst-mails). Weet jij toevallig wie dat doet? D.w.z. als dat gebeurt nadat de DKIM signature is gezet, de ontvangende mailserver bijvoorbeeld, wordt die signature natuurlijk ongeldig.
@Briolet of iemand anders die dit weet: als ergens in de body van de mail de auteur een regel met From heeft laten beginnen, ziet de ontvanger meestal dat "iets" daar > From van gemaakt heeft (in elk geval in platte-tekst-mails). Weet jij toevallig wie dat doet? D.w.z. als dat gebeurt nadat de DKIM signature is gezet, de ontvangende mailserver bijvoorbeeld, wordt die signature natuurlijk ongeldig.
Dit doen alleen ouderwetse mailservers die hun mailboxen opslaan als 1 enkele file in het klassieke "Unix mailbox format".
Daarbij was een mailbox een opeenvolging van alle mailtjes waarbij deze gescheiden waren door een regel die begint
met "From ..." (de naam en datum) en daaronder dan de mailheaders (waaronder From: dus met : erachter) en dan een
lege regel en de mailtekst, daarna dan weer een lege regel en de volgende "From ..." header.
Het omzetten van "From " naar ">From " was een truuk om te voorkomen dat de server deze tekst als een nieuw
mailtje zou zien en daarmee alles fout zou lopen.
Het grote nadeel van dit format (wat een probleem werd toen mensen heel veel en heel grote mails gingen uitwisselen)
is dat alle mail in 1 file staat en dus als je een mailtje delete dan moet die hele file gecopieerd worden m.u.v. dat ene
mailtje. Om dit wat efficienter te maken frommelen de mailservers er dan meestal wel een header in zoals Status: waar
al een plek achter gereserveerd is om die mail "deleted" te maken en als er dan een bepaalde hoeveelheid mailtjes
op deleted staat gaan ze pas die copieslag doen.
Maar ik heb vroeger wel eens een dergelijke server gedraaid in een zakelijke omgeving en met vele mailboxen die
gigabytes in size worden wordt dit een nachtmerrie voor de performance.
Daarom wordt dit format tegenwoordig niet meer zo veel gebruikt, een alternatief is "maildir" waarbij een mailbox een
directory is met een file per mailtje, zodat je deze gewoon onafhankelijk van elkaar kunt deleten of verplaatsen naar een
andere folder. Dit heeft uiteraard weer andere nadelen, bijv dat het inefficient is bij heel kleine mailtjes. Maar die komen
toch zowat niet meer voor op de meeste servers. (vroeger kon een mailtje 200 bytes zijn incl headers...)
Ook zijn er tegenwoordig wel servers die de mail in een database zetten.
11-04-2020, 12:22 door
Briolet
Door Erik van Straten: @Briolet of iemand anders die dit weet: als ergens in de body van de mail de auteur een regel met From heeft laten beginnen, ziet de ontvanger meestal dat "iets" daar > From van gemaakt heeft
Anoniem hierboven heeft het al grotendeels beantwoord. Ik kende het fenomeen niet. Ik kon het ook niet reproduceren door mailtjes naar diverse andere mailboxen te sturen. (iCloud, GMail, etc)
Ik gebruik een PostFix mailserver. Mij viel wel op dat hij de 'F' in 'From' escaped door '=46'. (alleen in de bodytekst). Dat gebeurd al bij het verzenden. NB 46 is de utf-8 code voor een F
Het verhaal van anoniem hierboven lezende, snap ik nu de reden van het 'wegwerken van die 'F'. Op die manier zullen de oude mailservers de From niet interpreteren als de start van een nieuwe mail.
11-04-2020, 13:13 door
Erik van Straten
@Anoniem 09:07: dank voor de verklaring! Dat mailbox format ken ik inderdaad, maar deze link had ik niet gelegd.
M.b.t dat het oud is: ik heb niet zo lang geleden, waarschijnlijk in een webbased archief van een maillijst (zoals bijv. te vinden zijn https://seclists.org/), nog zo'n mail gezien - maar ik weet niet meer waar (en ik kan het ook niet terugvinden). Ik heb geen idee waar in zo'n situatie die conversie wordt gedaan - die natuurlijk ook desastreus is voor persoonlijke signatures gezet met PGP/GnuPG/GPG of S/MIME (indien gezet vóór de conversie).
Daarbij, die utf-8 code kan natuurlijk alleen als de MIME-header aangeeft dat de inhoud utf-8 is (bij ASCII zal de ontvanger dan '=46' zien i.p.v. 'F').
M.a.w. als in de tekst van een e-mail een regel met "From" begint, en de gebruikte mailclient dit niet "repareert" vóór het zetten van een persoonlijke digitale handtekening, dan lijkt het risico groot dat die handtekening, en mogelijk een DKIM signature, ergens onderweg "kapotgaat". Dat geldt ook voor unicode en/of HTML mails; als de mailclient de sequence "<LF>From" (in de body) niet wijzigt, kan dat onderweg alsnog gebeuren. Met SMTP mail sjouwen we een hoop legacy rommel mee die niet bepaald helpt bij digitale handtekeningen...
M.b.t dat het oud is: ik heb niet zo lang geleden, waarschijnlijk in een webbased archief van een maillijst (zoals bijv. te vinden zijn https://seclists.org/), nog zo'n mail gezien - maar ik weet niet meer waar (en ik kan het ook niet terugvinden). Ik heb geen idee waar in zo'n situatie die conversie wordt gedaan - die natuurlijk ook desastreus is voor persoonlijke signatures gezet met PGP/GnuPG/GPG of S/MIME (indien gezet vóór de conversie).
Door Briolet: Ik kende het fenomeen niet. Ik kon het ook niet reproduceren door mailtjes naar diverse andere mailboxen te sturen. (iCloud, GMail, etc)
Ik gebruik een PostFix mailserver. Mij viel wel op dat hij de 'F' in 'From' escaped door '=46'. (alleen in de bodytekst). Dat gebeurd al bij het verzenden. NB 46 is de utf-8 code voor een F
Dank ook voor jouw reactie en onderzoekjes. Als PostFix mails gaat wijzigen, zal dat in elk geval persoonlijke digitale handtekeningen ongeldig maken.Ik gebruik een PostFix mailserver. Mij viel wel op dat hij de 'F' in 'From' escaped door '=46'. (alleen in de bodytekst). Dat gebeurd al bij het verzenden. NB 46 is de utf-8 code voor een F
Daarbij, die utf-8 code kan natuurlijk alleen als de MIME-header aangeeft dat de inhoud utf-8 is (bij ASCII zal de ontvanger dan '=46' zien i.p.v. 'F').
M.a.w. als in de tekst van een e-mail een regel met "From" begint, en de gebruikte mailclient dit niet "repareert" vóór het zetten van een persoonlijke digitale handtekening, dan lijkt het risico groot dat die handtekening, en mogelijk een DKIM signature, ergens onderweg "kapotgaat". Dat geldt ook voor unicode en/of HTML mails; als de mailclient de sequence "<LF>From" (in de body) niet wijzigt, kan dat onderweg alsnog gebeuren. Met SMTP mail sjouwen we een hoop legacy rommel mee die niet bepaald helpt bij digitale handtekeningen...
Erik van Straten, dank! Zeer heldere uitleg.
Ik begrijp inmiddels ook dat je dus altijd SPF+DMARC moet doen om de enveloppe-truukjes ook te blokkeren.
Of (expliciet of, want een van beide mag falen, al is het dus wel verstandig beide tegelijk actief te hebben) DKIM+DMARC, wat weer handig is bij mails die forwarded worden.
TS.
Ik begrijp inmiddels ook dat je dus altijd SPF+DMARC moet doen om de enveloppe-truukjes ook te blokkeren.
Of (expliciet of, want een van beide mag falen, al is het dus wel verstandig beide tegelijk actief te hebben) DKIM+DMARC, wat weer handig is bij mails die forwarded worden.
TS.
Door Erik van Straten: …Als PostFix mails gaat wijzigen, zal dat in elk geval persoonlijke digitale handtekeningen ongeldig maken.
Nee omdat dit natuurlijk gebeurd vóór het ondertekenen.
Verder klopt mijn verhaal niet. Ik heb het beter getest en nu blijkt het niet PostFix te zijn die dit doet, maar Apple Mail. Als ik de mail nml met Roundcube of Thunderbird verstuur gebeurd dit niet op deze manier. Deze twee mailprogramma's passen de From echter ook aan. Nu door er een speciaal teken voor te zetten. Ik zie zo snel niet welk ascii symbool dit is. In gewone weergave zie je dit teken niet, maar bij weergave als bron, zie ik het als spatie.
Dat het woord 'From' in de bodytekst problemen kan geven wordt blijkbaar door diverse mailprogrammas onderkend.
Door Erik van Straten:Daarbij, die utf-8 code kan natuurlijk alleen als de MIME-header aangeeft dat de inhoud utf-8 is (bij ASCII zal de ontvanger dan '=46' zien i.p.v. 'F').
Het kan ook zijn dat dit ascii code is. Bij de karakter F zijn die waardes gelijk. (-:
Het is een beetje idioot om deze conversie te doen aan de verzendkant. Dit hoort de ontvangende mailserver te doen op
het moment dat ie een mail in een Unix mailbox file zet. Als er een ander format in gebruik is dan hoeft ie dat helemaal niet
te doen! Bijv met maildir of een andere opslag. Gmail zal uiteraard een ander format hebben en dan is deze hele issue
er niet, het is dan kolder om dit aan de verzendkant op te lossen.
Ik heb het even getest als ik met mutt een mail stuur naar mijn eigen mailserver die sendmail gebruikt met lda om af te
leveren in een maildir dan wordt er niks gedaan met "From ", het staat gewoon in de mail en de DKIM signature is OK.
Maar als sendmail mail aflevert in een maildir dan zet ie dus die > ervoor en dan is de DKIM signature invalid.
(kennelijk bevat de DKIM checker niet de hack om ">From " om te zetten in "From " voor hij het checked, wat natuurlijk
ook linke soep is want als er dan >From in een mail staat dan maakt ie het juist weer kapot.
het moment dat ie een mail in een Unix mailbox file zet. Als er een ander format in gebruik is dan hoeft ie dat helemaal niet
te doen! Bijv met maildir of een andere opslag. Gmail zal uiteraard een ander format hebben en dan is deze hele issue
er niet, het is dan kolder om dit aan de verzendkant op te lossen.
Ik heb het even getest als ik met mutt een mail stuur naar mijn eigen mailserver die sendmail gebruikt met lda om af te
leveren in een maildir dan wordt er niks gedaan met "From ", het staat gewoon in de mail en de DKIM signature is OK.
Maar als sendmail mail aflevert in een maildir dan zet ie dus die > ervoor en dan is de DKIM signature invalid.
(kennelijk bevat de DKIM checker niet de hack om ">From " om te zetten in "From " voor hij het checked, wat natuurlijk
ook linke soep is want als er dan >From in een mail staat dan maakt ie het juist weer kapot.
Door Erik van Straten:
Test zenden e-mail zonder From: regel
Maar je hebt gelijk! Ik heb met PuTTY ingelogd op shell.xs4all.nl en met telnet (naar poort 25 van een xs4all mailserver) mezelf een e-mail gestuurd zonder daarin een header-From: te specificeren. Tot mijn verrassing kwam de mail binnen met in header-From een kopie van envelope-From!
Lang geleden dat ik het heb uitgezocht, maar AFAIK is RFC5322.From verplicht! Dit in tegenstelling tot RFC5322.To... Als er geen header To is, kan (MAY) de ontvangende mailserver, bijvoorbeeld sendmail, hier een header "To: undisclosed-recipients:;" toevoegen.Test zenden e-mail zonder From: regel
Maar je hebt gelijk! Ik heb met PuTTY ingelogd op shell.xs4all.nl en met telnet (naar poort 25 van een xs4all mailserver) mezelf een e-mail gestuurd zonder daarin een header-From: te specificeren. Tot mijn verrassing kwam de mail binnen met in header-From een kopie van envelope-From!
Overigens kun je helaas vanaf shell.xs4all.nl niet meer rechtstreeks telnetten naar poort 25 (van een server buiten het netwerk van XS4all?), maar maak je een verbinding met een mailserver van XS4all zelf! Dit omdat er teveel misbruik van werd gemaakt.
Ik kwam hier enkele maanden geleden achter toen ik iets op mijn eigen mailservers wou testen.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
