Sender Policy Framework (SPF) en DomainKeys Identified Mail (DKIM) worden als validatiemethoden gebruikt om te controleren of een inkomend e-mailbericht dat aangeeft van een specifiek domein afkomstig te zijn door de eigenaar van dat domein is geautoriseerd. Deze methode beschermt geadresseerden tegen de ontvangst van vervalste e-mailberichten. ESET Mail Security maakt tevens gebruik van DMARC-beoordeling (Domain-based Message Authentication, Reporting and
Conformance; op domein gebaseerde verificatie, rapportage en conformiteit van berichten) voor een verdere verbetering ten opzichte van SPF en DKIM.
SPF
Er wordt een controle uitgevoerd om na te gaan of een e-mail door een legitieme afzender is
verzonden. Een DNS-lookup voor SPF-records van het domein van de verzender wordt uitgevoerd om een lijst met IP-adressen te verkrijgen. Als een van de IP-adressen van de SPF-records overkomt met het werkelijke IP-adres van de afzender, is het resultaat van de SPF-controle Geslaagd. Als het werkelijke IP-adres van deze afzender niet overeenkomt, is het resultaat Mislukt. Niet alle domeinen hebben echter SPF-records die in DNS zijn gespecificeerd. Als er geen SPF-records in DNS aanwezig zijn, is het resultaat Niet beschikbaar. Er kan af en toe een time-out optreden voor de DNS-aanvraag als gevolg waarvan het resultaat ook Niet beschikbaar is.
DKIM
Wordt door organisaties gebruikt om te voorkomen dat e-mailberichten worden vervalst door een digitale handtekening conform de DKIM-standaard toe te voegen aan de kopteksten van uitgaande berichten. Hierbij wordt een privédomeinsleutel gebruikt om de kopteksten van uw uitgaande e-mail te versleutelen en een openbare versie van de sleutel toe te voegen aan de DNS-records van het domein. ESET Mail Security kan vervolgens de openbare versie van de sleutel ophalen om de inkomende kopteksten te ontsleutelen en verifiëren of het bericht werkelijk afkomstig is van uw domein en de kopteksten niet ondertussen zijn gewijzigd.
OPMERKING
Exchange Server 2010 en oudere versies zijn niet volledig compatibel met DKIM, omdat kopteksten die in digitaal ondertekende inkomende berichten zijn gevoegd tijdens de DKIM-validatie worden aangepast.
DMARC
Bouwt voort op twee bestaande mechanismen, SPF en DKIM. U kunt de regels voor beveiliging van e-mailtransport gebruiken ter evaluatie van het DMARC-resultaat en voor de actie DMARC-beleid
toepassen.
DNS-servers automatisch detecteren
Gebruikt instellingen van uw netwerkadapter.
IP-adres van DNS-server
Als u specifieke DNS-servers voor SPF en DKIM wilt gebruiken, voer dan het IP-adres (in IPv4- of IPv6-indeling) van de gewenste DNS-server in.
Time-out van DNS-query (seconden) Geef de time-out voor de DNS-reactie op.
Automatisch berichten afwijzen als SPF-controle is mislukt
Als de SPF-controle onmiddellijk resulteert in Mislukt, kan een e-mailbericht worden afgewezen voordat het wordt gedownload.
VOORBEELD
De SPF-controle wordt uitgevoerd op de laag. Deze kan echter automatisch op de SMTP-laag dan wel tijdens de beoordeling van regels worden afgewezen.
Het is niet mogelijk om afgewezen berichten te registreren in het Gebeurtenissenlogboek als u automatische afwijzing op de SMTP-laag gebruikt. Dat is omdat logboekregistratie gebeurt door een regelactie, terwijl de automatische afwijzing direct plaatsvindt op de SMTP-laag, dus vóór de regelbeoordeling. Omdat de berichten worden afgewezen voordat de regels worden beoordeeld, is er geen informatie beschikbaar voor logboekregistratie op het moment dat de regelbeoordeling plaatsvindt.
U kunt afgewezen berichten registreren, maar alleen als u de berichten afwijst door middel van een regelactie. Als u berichten wilt afwijzen die de SPF-controle niet hebben doorstaan en deze afgewezen berichten in een logbestand wilt registreren, schakelt u Automatisch berichten afwijzen indien SPF-controle mislukt uit en maakt u de volgende regel voor Beveiliging van e-mailtransport:
Gebruiken From: koptekst als MAIL FROM leeg is
De koptekst MAIL FROM kan leeg zijn en kan ook eenvoudig worden vervalst. Als deze optie is geactiveerd en MAIL FROM is leeg, wordt het bericht gedownload en wordt in plaats daarvan de koptekst From: gebruikt.
Greylisting automatisch omzeilen als SPF-controle is geslaagd
Er is geen reden om Greylisting te gebruiken voor een bericht als het resultaat van de SPF-controle Geslaagd was.
SMTP-afwijzingsreactie
U kunt een Reactiecode, Statuscode en Reactiebericht opgeven waarmee de tijdelijke SMTP-afwijzingsreactie wordt gedefinieerd die naar de SMTP-server wordt verzonden als een bericht is afgewezen. U kunt een reactiebericht in de volgende indeling typen:
Reactiecode Statuscode Reactiebericht
550 5.7.1 SPF-controle mislukt
Backscatterbeveiliging
Spambackscatter zijn verkeerd omgeleide niet-bezorgberichten die door mailservers worden verzonden. Backscatter is een ongewenst neveneffect van spam. Wanneer een spambericht wordt geweigerd door de e-mailserver van de ontvanger, wordt er een NDR (Non-Delivery Report), ook wel een niet-bezorgbericht genoemd, verzonden naar de zogenaamde afzender (een e-mailadres dat is vervalst en als afzender van het oorspronkelijke spambericht fungeert), niet de werkelijke afzender van de spam. Een gebruiker, die eigenaar is van het e-mailadres, ontvangt een NDR-bericht, hoewel de gebruiker helemaal niet betrokken was bij het oorspronkelijke spambericht. Dit is het punt waarop Backscatterbeveiliging aan de slag gaat. U kunt voorkomen dat spam-NDR's worden bezorgd bij het postvak van gebruikers in uw organisatie door ESET Mail Security Backscatterbeveiliging te
gebruiken.
Wanneer u NDR-controle inschakelt, moet u Handtekening-seed opgeven (een tekenreeks van minimaal 8 tekens, vergelijkbaar met een wachtwoordzin). ESET Mail Security Backscatterbeveiliging schrijft X-Eset-NDR: <hash> in de koptekst van elk uitgaand e-mailbericht. <hash> is een
versleutelde handtekening met daarin ook de Handtekening-seed die u hebt opgegeven.
Als een legitiem e-mailbericht niet kan worden bezorgd, ontvangt uw e-mailserver doorgaans een NDR, die wordt gecontroleerd door ESET Mail Security, die op zoek gaat naar X-Eset-NDR: <hash> in de kopteksten. Als de X-Eset-NDR: aanwezig is en de handtekening <hash> komt overeen, wordt de NDR bezorgd bij de afzender van het legitieme e-mailbericht om aan te geven dat bezorging van het bericht is mislukt. Als de Eset-NDR: niet aanwezig is of de handtekening <hash> onjuist is, is dat het bewijs dat het om spambackscatter gaat en wordt de NDR geweigerd.
NDR-automatisch negeren indien niet geslaagd voor controle
Als de NDR-controle onmiddellijk resulteert in Mislukt, kan een e-mailbericht worden afgewezen voordat het wordt gedownload.
U kunt de activiteit van Backscatterbeveiliging in het SMTP-beveiligingslogbestand bekijken.