DMARC helpt alleen als de ontvangende MTA aan DMARC doet. Helaas doen de grote Nederlandse providers (Ziggo, KPN) (nog?) niet mee.

SPF alleen bijt naar je, want met SPF op 'strict' mode mag mail niet worden geforward. Denkfout in SPF, is overigens al heel lang bekend. DKIM is de (veel) betere oplossing.

DKIM is niet zo ingewikkeld hoor: DKIM kent een cryptografische ondertekening van de mail. Deze wordt op de verzendende mailserver met een private key gedaan en toegevoegd aan de headers. Opendkim kan dat voor de *nix varianten.

De ontvangende MTA kan de handtekening verifieren doordat de public key in de DNS (als TXT record) van het verzendende domein staat. Wederom kan Opendkim je hierbij helpen.

In DMARC kan dan worden aangegeven dat mail zonder handtekening moet worden geweigerd. Werkt op zich perfect. Bij ISP's die DMARC ondersteunen komt er geen valse email meer door.

Als het gespoofed wordt (dat kan net als de scammers) gebeurt dat op machines die buiten je bereik staan.
Het helpt niet wat je ook doet op je eigen machines. Het verkeer moet bij de ontvangers gefilterd/gevalideerd worden.
Enig idee wat de bron zou kunnen zijn?

Je hebt gelijk dat SPF ervoor zorgt dat forwarding niet meer werkt. Het is echter geen denkfout maar een onvermijdelijk gevolg.

Staat je SPF al op hardfail? En dmarc op alles reject?

Abuse meldingen doen over de mailservers die toch spoofen is dan enige optie.
En anders ligt het vooral in de handen bij de server van de ontvangers.

uit de melding maak ik op de DKIM niet geïmplementeerd is. Dan zal ook DMARC niet werken omdat DKIM daarvoor nodig is.

Als je DMARC goed geïmplementeerd hebt, zal het gros van de grote providers de mail uitfilteren volgens jouw dmarc instelling: (in de spambox of bouncen). In elk geval zal dat gebeuren bij gebruikers van gmail, hotmail, yahoo, xs4all en nog vele andere mail verwerkers.

Ziggo kijkt echter niet naar dmarc. Maar als je king dan klaagt over de spam, kun je ze er op attenderen dat ze naar een echte mail provider moeten overstappen met goede anti-spam maatregelen.

Even inlezen op SPF,DMARC en DKIM .

Dat zijn de enige opties die je binnen je eigen beheerdomein kunt doen , namelijk het publiceren/meegeven van filter/validatie aanwijzingen voor de rest van de wereld wanneer mail wel echt van jou afkomstig is en een advies wat de ontvanger moet doen met mail waarbij dat niet klopt.

TS zoekt dus in de juiste richting.

Als je het ontwikkelproces indertijd gevolgd hebt dan weet je dat dit effect over het hoofd gezien is. Ergo, een ontwerpfout.


Anoniem1 en 2: Het is al duidelijk dat TS probeert om het mogelijke aan zijn kant te doen. De ontvangende MTA moet echter wel meewerken, en helaas doen onder andere Ziggo en KPN (met alle gerelateerde domeinen op xs4all na) niet mee.

Het kennen van de bron helpt je ook totaal niet Achteraf kun je weinig doen. TS mag van geluk spreken dat het maar een heel kleine Joe Job betreft. Ik heb ze veel groter gezien. 70.000 rejects waren geen uitzondering.

Als ik op http://www.openspf.org/Best_Practices/Forwarding kijk, zie ik dat daar wel goede voorstellen staan om forwarden mogelijk te maken. Een deel behelst het niet bouncen van mail maar in de spambox plaatsen door de geforwarde (lapmiddel), maar de laatste alinea lijkt me een goede suggestie voor de mailserver die gaat forwarden.
Dus lijkt er wel over oplossingen nagedacht te zijn, maar ze worden alleen zelden geïmplementeerd.

Als ik naar mijn, relatief kleine aantal, mailings kijk, merk ik via de dmarc terugmeldingen dat ca 25% van mijn ontvangers hun mail ook nog forward. Dit resulteert in een SPF fail, maar ik heb in het mail-log nog nooit iets gezien van een verzoek van de ontvangende server om de mail maar opnieuw naar een ander adres te sturen, zoals de suggestie op OpenSPF.

SPF op ~ en DKIM op - maakt het leven zoooo veel eenvoudiger. DKIM is nu eenmaal een veel sterkere methode (want cryptografische ondertekening) dan SPF. Wel keys van 2048 bit gebruiken...

SPF heeft eigenlijk gewoon geen zin als je DKIM hebt ingericht.

Get real - keys van 2048 bit voor _spam filtering_ ?
1024 bit is meer dan genoeg.
Zonde van de processing tijd overal om 2K crypto processing te laten doen.

Nee, 2048 voor handtekening onder email... Je bent het verhaal van Google al vergeten, die dacht te kunnen tekenen met 512 bits? Je hebt de berichtgeving gemist dat 1024 bits niet genoeg meer is? Het is een MAC. Het is niet erg dat die sterk is...

http://www.wired.com/2012/10/dkim-vulnerability-widespread/
http://www.techworld.com/news/security/rsa-1024-bit-private-key-encryption-cracked-3214360/

Er is een wereld van verschil tussen 512 en 1024 .
512 bit is binnen bereik van individuele personen met een bak hardware (en redelijk wat tijd en kennis ).
De eerste 512 bit factorisatie was in _1999_

Maar lees jij je links ook, of ga je alleen af op een clickbait headline ?

De gelinkte 1024 bit 'crack' is GEEN 1024 bit factorisatie . Het is een side-channel attack waarbij een private key afgeleid is uit het observeren van stroomgebruik van de processor die de private key gebruikt.
Noem je een server hack waarbij een 4096 bit private key van de server gehaald wordt ook een bewijs dat 4096 bit keys te kort zijn ?

Het huidig record van het factorization van een rsa sleutel (+- 2010) , "net" haalbaar door een vrij massaal project van ca twee jaar is een 768 bit key .
De auteurs speculeren dat het factoriseren van een enkele 1024 bit sleutel mogelijk net wel of net niet haalbaar zou zijn voor een project van hun schaalgrootte in het komende decennium .

Nu moet je je ook afvragen wat je aan het beveiligen bent, tegen wie, en voor hoe lang - en voor niks meer dan een spam check op email zie ik heel weinig noodzaak als het factorizeren van een enkele key een serie top researchers twee jaar kost .
- je kunt gewoon je keys op half jaar of jaar basis roteren . Dat is überhaupt noodzakelijk, want de kans dat je private key ergens uit lekt (hoeveel beheerders zijn er in die tijd langsgekomen en weer vertrokken ?)
is over het algemeen heel veel groter dan dat een wereldploeg een paar jaar bezig gaat op precies jouw key .

'te' grote keys zijn niet gratis - crypto processing kost tijd/throughput/stroom op alle plekken waar het gedaan moet worden .

Vertel: waarom NCSC, Enisa adviseren om op minimaal 2048 bits te gaan zitten? Waarom adviseert NIST, NSA op minimaal 2048 bits te gaan zitten? Waarom gaat Google (en andere grote partijen) op 2048 bits zitten?

Ik vermoed dat die toch iets meer kijk op de zaak hebben dan Anoniem 1952. Je kunt vast zelf wel de linkjes vinden. En clickbait? Heb je de reactie van Google gezien? 512 bits was in 2012 binnen 72 uur te factoriseren. Daar heb je op zich niet al te veel kennis voor nodig, iedere VWO'er met wiskunde kennis kan het. Heb je enig idee hoe krachtig een AWS cluster is, en hoe goedkoop dat dan is?

De spammers hebben een heleboel geld te investeren. Cybercriminelen (die graag phishing sturen) nog veel meer.

We leven overigens bijna in 2016, om je dan te verlaten op aanbevelingen van 2010 is enigszins gevaarlijk.

Ik baseer me op standaarden. De standaarden van dit moment zeggen dat we weg moeten blijven bij alles wat minder dan 2048 bits is. Onderschatten van 'de tegenstander' is het gevaarlijkste dat je kan doen, en precies dat promoot je.

En maak je geen zorgen over toepassing van wat langere sleutels. Mail is geduldig, en ook bij, zeg 1 mljoen mass mailtjes is de invloed van sterke crypto prima te verantwoorden als je daarmee de phishers uitsluit.

Ik gebruik gewoon een betaalde third party email provider. Dan heb je ook geen kennis nodig om je dkim goed in te stellen. Je hoeft alleen de dns records goed te zetten en klaar.

Omdat die adviezen zijn voor alle soorten gebruik, voor data die langdurig beschermd moet blijven en potentieel erg waardevol is.
Onder die vraagstelling ben ik het ook volkomen eens met adviesen van 2048 of meer. - en vandaar dat ik mijn statement hier kwalificeerde met _slechts voor spam filtering_ . En het advies dat je die key vooral moet roteren.

Overigens geeft bv de NIST SP800-57 publicatie wel heel uitgebreid gebruikersdoelen, levensduur en bijbehorende afwegingen , en schat rsa-1024 equivalent met ca 80 bits symmetrische encryptie .
Ook ECRYPT2 geeft een hoop gebruikscriteria bij de diverse aanbevelingen.


De gemiddelde security expert moet je ook vooral niet lastig vallen met details en kwalificaties, maar alleen maar een bitlengte geven die onder geen enkel soort gebruik te kort is.


Clickbait - je geeft en gelooft een linktitel die zegt "1024 bit rsa gebroken" terwijl het alleen maar een side channel attack is.
Dat 512 bit te kort is heb ik beaamd - iets wat in _1999_ behoorlijk state of the art was, is in 2012 inderdaad wel binnen bereik van een individu dat een punt wil maken .

Ik heb wat meer dan VWO wiskunde - en ik weet dat _grootschalige_ factorisatie gewoon moeilijk is.
En die papers en records worden ook niet door VWO'ers geschreven. (ook niet door mij, trouwens).
Dee rand van de state of the art is echt geen VWO stof , maar bestaat uit een serie promotie waardig onderwerpen.
Het schaalt ook niet alleen maar met CPU snelheid of aantallen CPUs, maar ook met de hoeveelheid geheugen , in zowel de 'zeef'fase , en nog meer in de matrix eliminatie stap . Ook het kiezen van parameters (aantallen relaties wat gezocht gaat worden in de zeef-fase ) is een vak apart, en zeker geen invuloefening in een spreadsheet.

Je kunt hier niet simpelweg aantallen #cpu's/cycles/MIPSen uitruilen tegen tijd , voor factorizatie.
Dat is anders voor het dictionary of brute force searchen van wachtwoord hashes - dat is pas echt een schoolvoorbeeld van triviaal te paralleliseren en puur CPU bound.

Heb je overigens voorbeelden van VWO'ers die 512 bits factorizatie doen ? Het huren van AWS wil ik ze wel toevertrouwen,
het doen van een 512 bit factorisatie zou ik nog steeds behoorlijk knap vinden.
Je zult gezien hebben dat degene die de google 512 bit key factoriseerde een wiskundige was met een hobby voor factorizatie - en daar heb je , in dat gebied, meer aan dat het zijn van een 'security researcher' (wat hij niet was).


Het is het meest recente factorisatie record, de auteurs zijn (een deel van) de bekende namen die echt in dat gebied werken en publiceren, en ik ben geen recentere wiskundige doorbraken tegengekomen waardoor hun extrapolatie opeens enorm onjuist zou zijn.

Als je de referenties leest van de aanbevelingen zoals de door jou genoemde instituten doen, zie je dat die uitgebreid leunen op publicaties van tussen 2000 en heden voor het schatten van de hoeveelheid werk om bepaalde keylengtes te kraken.

Voorbeeld : NCSC (beveiligingsrichtlijnen voor TLS ) citeert Enisa 2013, en Enisa 2013 geeft een tabel gevuld met
Lenstra-Verheul 2000, Lenstra 2004 , IETF 2004, SECG 2009, NIST 2012 en ECRYPT2 2012 .

Oftewel - voor de research waar de diverse aanbevelingen op gebaseerd zijn is 2010 gewoon recent.


Ik lees ze ook - en vooral de referenties die ze geven.

Ik maak me niet veel zorgen over iets wat vrijwel een wegwerp key moet zijn en naar beste schatten een jaar of twee werk van een set van top experts vergt .

Denken dat de tegenstanders zich vooral richten op de sterkste schakel, en al mijn aandacht daarop richten is wat ik probeer te vermijden. Ook al is het verleidelijk omdat die sterkste schakel ongeveer als enige zo lekker makkelijk kwantificeerbaar is, en met zo weinig moeite NOG sterker gemaakt kan worden. Lijkt het net alsof je heel effectief bezig bent.

Bespaar je de moeite, je kunt er niets aan doen dat ergens anders spam met jouw email adres wordt verstuurd. Vooral niets gaan implementeren wat je eigen mail raakt, dat is al snel zo als je met flutoplossingen zoals SPF. DKIM en DMARC inlaat. Daar heeft vrijwel niemand wat aan. Toepassen is het kind met het badwater weggooien.


Nee, dat is niet zo. Spammers doen het absolute minimum wat nodig is. Ze investeren weinig tot niets en het laatste wat ze zullen proberen is keys te kraken. Phishers investeren nog wel het minst van alle soorten spammers, die doen het vooral met gehackte servers.

Enige uitzondering zijn de zogenaamde snowshoe spammers die vooral in de VS werken. Die kopen op grote schaal domeinen en gedistribueerde hosting in. Ze gebruiken SPF en DKIM. Want dat lijkt het ok. Er was een tijd dat spammers de grootste gebruikers van SPF en DKIM waren. Logisch, want het kost niks.

Mijn ervaring is dat DMARC dit probleem wel vermindert, maar je moet niet verwachten dat het van de ene op de andere
dag werkt. Het heeft namelijk niet veel invloed op de bounces die je terug krijgt, maar alleen op de kans dat ze jouw adres
gebruiken als bron van de spam.
De spammer wil dat zijn mail aankomt en als ie in de gaten krijgt dat jij DMARC gebruikt dan zal hij een ander adres
nemen wat dat niet heeft.
Dit werkt uiteraard niet als de joe job een wraakactie is die op jou gericht is, maar wel als je alleen maar geselecteerd
bent als afzender adres voor spam.
Op het werk hebben we een jaar ofzo DMARC gebruikt en het aantal rare bounces nam behoorlijk af in die periode, op een
gegeven moment is het uitgezet omdat een andere mailserver de DKIM niet out-of-the-box ondersteunde en sindsdien is
het weer opgelopen.
Maar een dramatisch verschil van 500 per week naar nul moet je niet verwachten.

Bedankt for alle replies!!!

Mijn Conclusies:

Ik zal wel proberen ook dkim op te zetten. Net zoals SPF en DMARC heb je medewerking van de ontvanger nodig, maar ja, baat het niet dan schadt het ook niet.
Ik forward niet, en ik zal uitkijken hiervoor, maar ja, waarom geeft SPF problemen bij forwarding en DKIM niet??

Ik geloof ook wel dat 1024 bits moet genoeg zijn.

Goed punt dat spammers minder geneigde zullen om je domein te gebruiken als ze zien dat je SPF, _DMARC (en DKIM) erop heb, lijkt mij ook.

Ik zal mijn resultaten hier posten, maaar in de tussentijd, super bedankt voor alle hulp!

Bij mijn provider is er geen support voor DKIM. Jammer.

Dave

Let op : het probleem ontstaat als *ontvangers* mail van een beschermd (spf ) domein forwarden, en de plek waar ze naar toe forwarden een check doet.
Bij het forwarden wordt de machine vanaf waar geforward wordt , gezien vanaf de definitieve bestemming, de bron van de mail maar is die machine niet opgenomen in het spf record van genoemd voor het afzender domein (nl : jouw domein) .

De vraag is dus niet of jij forward op jouw domein, maar of ontvangers van mail vanaf jouw domein dat veel doen .

Als de mail echt ongewijzigd geforward wordt, blijft de dkim signature kloppen en klopt de dkim check .
dkim kijkt namelijk naar (ongewijzigde - op basis van een signature) mail headers, en niet zozeer naar het ip adres waar de mail van afgeleverd wordt.

DKIM heeft wel een probleem als de mail(header) deels herschreven wordt bij forwarding - zoals bij een mailing list vaak gebeurt .
Bijvoorbeeld het Subject wordt herschreven naar Subject [mailing list naam ] origineel subject .

Dan klopt de dkim signature niet meer.
(google maar op dmarc, dkim , mailinglist voor details, en voor- en nadelen van diverse workarounds ).

[..]

Dat is een verkeerde conclusie. Stel je hebt je laptop mee en je wilt mail versturen. Je mail komt dan niet meer vanaf de gebruikelijke mail server. Of je bent op vakantie. Dus als er iemand zo dom is om te blokkeren (in SpamAssassin bijvoorbeeld scoor je spampunten met een verkeerde mail server). Of de mail server van je provider is down, maar je moet dringend een mailtje versturen. Of je iemand stuurt jouw mail door, bijvoorbeeld een mailing list.

Dat is dan jammer. Dus hoe erg is het probleem dat je deze forse nadelen neemt? Niet alles wat men op Internet adviseert is een goed advies. Het wordt vaak gegeven door mensen die geen verstand van email hebben. Bijvoorbeeld door security amateurs en theoretici.

Alleen als je bijvoorbeeld een bank bent of op grote schaal rekeningen per email stuurt dan hebben zulke settings zin. Anders kun je maar beter accepteren dat er backscatter bestaat.

Je doet hier aannames over een bepaald gebruiksmodel of mail instellingen.

Een mail client kan prima via SMTP SUBMIT (tcp/587) , via SSL , een externe mailserver gebruiken.
Dat is veel normaler dan dat je , onderweg/op vakantie , "de mailserver van de camping ISP" moet opzoeken om die te gebruiken als smarthost .
Laat staan dat je op een laptop zelf een volledige mailserver gebruikt - dat is echt alleen voor hobby nerds.

Clients zoals 'Mail' van Apple gebruiken ook voor verschillende identiteiten verschillende uitgaande mail servers ,als je die hebt opgegeven. Je mail van jou@gmail gaat dus via de gmail smarthost naar buiten, je mail van jou@isp via de smarthost van de jsp , en mail van jou@eigendomein dan via je eigen mailserver die de dkim signing doet.

Heb je, zoals TS , blijkbaar een eigen domein en eigen mailserver kun met dat model ook prima altijd vanaf je eigen mailserver mailen.

Tenslotte is er natuurlijk het concept webmail (ook erg gebruikelijk voor veel mensen, zeker op vakantie), waarbij het probleem van de verkeerde uitgaande mailserver ook niet bestaat.

Kortom - ja, bij sommige soorten configuraties (ik ben geneigd te zegggen 'oude stijl' gebruik) loop je met spf/dkim tegen problemen aan als je van een andere dan je vaste plek werkt .

M.i. zijn die soorten gebruik aan het verdwijnen - en zijn er in elk geval meer dan genoeg manieren waarop dit kan werken, ook als je "op vakantie" mail wilt sturen.

sic
Wauw. wat een ware uitspraak op dit forum.

sic

Je kunt wachten op reacties zoals die van jou. Het zijn niet meer dan excuses en zwakke workarounds voor intrinsiek foute methodes. Je moet methodes beoordelen op hun effectiviteit. Die is zwaar onder de maat, veel ongewenste bijwerkingen en het zorgt niet voor een oplossing voor het probleem. Waarop het op neer komt is dat je vooral jezelf straft met deze methodes en niet het beoogde doel bereikt.

Je moet niet proberen recht te praten wat scheef is.

Sorry voor de late reactie!

Zeker heb ik het ontwikkelproces destijds gevolgd; ik had vanaf ca. 2003 zelf enorm veel last van een Joe-job (zie http://seclists.org/fulldisclosure/2004/Jan/1132 en https://www.security.nl/posting/10403/Waarom+SPF+en+FairUCE+op+termijn+geen+spam+bestrijden (in dat artikel is de 2e regel "5." weggevallen)). De grootste fout van SPF is dat het, na de oorspronkelijke publicatie, werd gepresenteerd als een middel om spam te bestrijden, en dat is het niet (zoals recentelijk spam aan TalkTalk klanten, met SPF, zogenaamd verzonden vanaf cisco.com, aantoont, zie https://www.security.nl/posting/450934/Personeel+Universiteit+Twente+trapt+in+phishingtest+studenten#posting450942).

Voor alle geïnteresseerden: nederlandstalige informatie over SPF, DKIM en DMARC kun je vinden in http://www.cip-overheid.nl/downloads/e-mailauthenticatie/ en https://www.ncsc.nl/actueel/factsheets/factsheet-bescherm-domeinnamen-tegen-phishing.html. Nb. in de NCSC publicatie staat een fout:Die "~all" betekent SOFTFAIL, dat zorgt er dus niet voor dat andere mailservers geen e-mail mogen versturen namens deze domainname (en ja, ik heb NCSC hierop gewezen).

Op dit punt ben ik het volstrekt met jou eens. Cisco adviseert zelfs om minimaal 3072 bits voor RSA en DH sleutels te gebruiken (zie https://www.security.nl/posting/449053/Cisco%3A+gebruik+3072+ipv+2048+bits+asymmetrische+sleutels+%28RSA%2C+DH%29).

De trieste waarheid is dat ik gisteren zag dat er nog 13 rootcertificaten met 1024bit RSA sleutels in de root certificate store op mijn Windows PC zitten, waarvan er 3 zijn verlopen (maar die kunnen nog wel gebruikt worden voor Authenticode verificatie). Doordat, in een standaard setup, een bedrijf uit Redmond hier naar believen certificaten aan kan toevoegen, kan dit aantal kleiner of zelfs groter zijn op jouw PC. Een aanvaller hoeft slechts van één zo'n certificaat een keypair te kraken (de private key erbij te berekenen) om intermediate- en/of end entity certificaten naar keuzen te kunnen genereren, die door Windows PC's worden vertrouwd. Als je zo'n root certificate niet op jouw PC hebt, zal Windows dat, heel bereidwillig, voor je downloaden en toevoegen aan de root certificate store.

Deze certificaten voldoen overigens geen van allen meer aan de eisen van CA|B Forum (zie https://cabforum.org/baseline-requirements-documents/). Waarom Google slechts 1 certificaat daarvan lijkt te gaan blokkeren (https://www.security.nl/posting/454295/Google+gaat+rootcertificaat+Symantec+blokkeren) ontgaat me.

Bla bla. Als je op basis van een erg verouderde stijl van mail gebruik nadelen benoemt die niet van toepassing zijn bij de huidige stijl van client gebruik , zoals anoniem 15-12 18:17 deed, kun je (gelukkig) nog steeds wachten op een correctie van iemand die het wel snapt - zoals ik .

Ik schreef 15-12 23:40 - en ik denk dat jij 18:17 was.