AOL dumpt Sender ID van Microsoft
America Online heeft haar steun voor de controversiele Sender ID technologie van Microsoft teruggetrokken en zal voortaan het Sender Policy Framework (SPF) gaan gebruiken. "Gegeven de recente beslissing van de Internet Engineering Task Force (IETF) en de matige ontvangst van Sender ID door de open source gemeenschap, heeft AOL besloten om te kiezen voor SPF," aldus een woordvoerder van AOL. Ondanks de beslissing heeft de grootste provider ter wereld niet alle banden met Sender ID verbroken. Zo zal het bedrijf nog steeds Sender ID bestanden publiceren zodat haar gebruikers compatible zijn met servers en applicaties die wel van Sender ID gebruik maken. Toch laat de ISP wel zien dat het geen vertrouwen meer in de e-mail authenticatie strategie van Microsoft heeft. (Internet News)
Bij beide worden toch geautoriseerde mailservers bekendgemaakt in een
TXT record in de DNS server. Of is er nog meer ?
artikelen (en vooral de links) hier op security.nl.
met een kleine aanvulling van Microsoft (iets uit hun CallerID).
Ik noem het nog maar een keer, SenderID is gewoon SPF, maar
met een kleine aanvulling van Microsoft (iets uit hun CallerID).
Wat is die kleine aanvulling dan ?
ik zie het hier zo niet http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx
Specification
(http://download.microsoft.com/download/4/3/9/439b024b-09fd-44ee-8ff0-10e834004c36/senerid_spec3.pdf)
is hun toevoeging
Mijn mening is dan ook dat Sender-ID geen toekomst heeft nu ik lees dat het
volledig op de resend from en sender headers is gebasseerd.
Iedere Spammer kan deze zelf creeren.
Daarnaast veroorzaakt dat nog steeds veel verkeer omdat de mail immers
eerst volledig binnengehaald moet worden voordat de Sender ID bepaald
kan worden.
Dan zie ik SPF toch als betere mogelijkheid. Daar moeten spammers al
toegang tot de DNS servers van het betreffende domein hebben om als
geautoriseerde sender door te kunnen gaan. En zelfs dan staat deze binnen
de kosrtste keren op de blacklisten.
Dan zie ik SPF toch als betere mogelijkheid. Daar moeten spammers al
toegang tot de DNS servers van het betreffende domein hebben om als
geautoriseerde sender door te kunnen gaan. En zelfs dan staat deze binnen
de kosrtste keren op de blacklisten.
[/quote}
eindelijk een zinnige reactie heel veel mensen dachten denken dat SPF of
SENDER_ID spam tegen houdt
dat is onzin
het maakt het slechts een paar minuten lastiger
eindelijk een zinnige reactie heel veel mensen dachten denken dat SPF of
SENDER_ID spam tegen houdt
dat is onzin
het maakt het slechts een paar minuten lastiger
Tegenhouden doet het spam niet maar het indentificeert spammers en in
combinatie met bv spamcop houd het ook spammers tegen.
indentificeert spammers en in combinatie met bv spamcop houd
het ook spammers tegen.
Ach, spammers zullen nog steeds hun eigen domeinen hebben om
vanaf te spammen, en daarnaast gebruik maken van zombie
pc's. Maar SPF maakt het ze weer net even moeilijker, en
da's altijd goed.
kunnen nog sneller geblacklisted worden.
Bovendien eisen veel Registars persoons-gegevens die niet zo makkelijk
gefaked kunnen worden.. En degene die dit niet eisen gaan dat waarschijnlijk
Heeeel snel doen, als ze massaal misbruikt worden door spammers.
De enige mogelijkheid die dan nog open blijft, is gebruik van machines die
een trojan hebben/gehacked zijn.. Maar die kunnen Geen rechtstreekse mail
meer versturen.. alleen nog maar via de smtp-server van de provider
(die daar checks op zetten om spammen/virii te voorkomen).
Wat is technisch het verschil tussen SPF en Sender ID???
Bij beide worden toch geautoriseerde mailservers bekendgemaakt in een
TXT record in de DNS server. Of is er nog meer ?
Sender-ID gebruikt gesignde XML records die in DNS TXT gezet worden,
terwijl SPF zeer simpel te genereren (en begrijpen) text rules gebruikt, en die
in DNS TXT zet.
SPF :
aol.com. 300 IN TXT "v=spf1 ip4:152.163.225.0/24
ip4:64.12.138.0/24 ptr:mx.aol.com ?all"
Caller-ID:
aol.com. 300 IN TXT "<?xml version="1.0" encoding="UTF-
8"?>
<ep xmlns='http://ms.net/1'>
<scope>
<domain>example.com</domain>
</scope>
<out>
<m>
<a>1.2.3.4</a>
</m>
<m><mx/></m>
</out>
</ep> "
Om Caller/Sender-ID te implementeren moet je grote hoeveelheden XML in
de DNS gaan zetten, en complexe XML-parsers in Mail-servers bouwen die
de ALLE data moeten checken voor een mailtje verder doorgegeven wordt,
in plaats van het rubuste lightgewicht systeem dat iedereen nu gebruikt, waar-
bij de controle alleen in (E)SMTP zelf zit. (behalve MS Exchange natuurlijk..)
Het zou mail-servers kortom net zo kwetsbaar & bloated maken als de mail-
server van Microsoft.
Daar komt nog bij dat je problemen zou kunnen krijgen als de hoeveelheid
XML in een record zo groot is dat het niet via een enkel UDP-pakketje kan
gaan, en dus over TCP moet (volgens de RFC's).. Dit omdat netwerk-
beheerders soms terecht inkomen tcp-verkeer op poort 53 blocken, omdat het
NU alleen maar gebruikt wordt voor zone-transfers..
Toen ik hoorde dat iemand bedacht had dat het een goed idee was om
XML te stoppen in DNS, vroeg ik me al af wie dat in hemelsnaam bedacht
had. Het MOEST wel een programmeur zijn .. eentje die tegen de muur moet.
Het bleek een programmeur van MS te zijn, wat alles verklaard.
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.
