Waarom SPF en FairUCE op termijn geen spam bestrijden
Altijd al een mooi wit Security.NL T-shirt willen hebben? Nu heb je de kans. Security.NL is namelijk op zoek naar mensen die interessante, security-gerelateerde artikelen of recensies willen schrijven. Je kunt het artikel naar redactie@security.nl sturen. De redactie zal de beste artikelen op Security.NL plaatsen en de schrijvers met het felbegeerde Security.NL tshirt belonen.
Door Erik van Straten
SPF, dat staat voor Sender Policy Framework (voorheen Sender Permitted From), is een controversieel middel om spam te bestrijden. Zie hier een aardige grafische voorstelling.
FairUCE is een vergelijkbaar mechanisme dat recentelijk door een IBM medewerker is voorgesteld, en wordt momenteel in verschillende maillijsten en forums besproken.
De kern van beide mechanismes is dat een email in principe als spam wordt beschouwd als het IP-adres van de aanbiedende server (of PC) niets te maken heeft met het domain-deel van het afzenderadres in het Return-Path. Het IP-adres is bekend zodra de TCP/IP verbinding tot stand is gebracht; kort daarna, aan het begin van de SMTP transactie, wordt het Return-Path uitgewisseld, d.w.z. nog voordat de email zelf (inclusief alle headers tot op dat moment) wordt overgedragen.
SMTP transacties
Een SMTP transactie kun je vergelijken met een koerier die een pakje komt bezorgen. In het onderstaande gesprek is O de ontvanger en K de koerier:
De bel gaat, je doet open en ziet een busje met kenteken 12-AB-CD.
1 O: "Goedenmorgen"
2 K: "Hallo, ik ben van koerier zoefzoef"
3 O: "Okay"
4 K: "Ik heb hier een pakje van posterderbedrijf X"
5 O: "Okay, dat klinkt als een legitieme afzender"
6 K: "Het is bestemd voor Max Laadvermogen"
7 O: "Dat klopt, die woont hier!"
8 K: De koerier geeft het pakje en zegt: "Nog een prettige dag"
9 O: "Tot ziens!"
Het begin van een SMTP transactie kan er als volgt uit zien:
IP-adres 213.156.1.80 maakt verbinding met jouw mailserver
1 O: 220 ontvanger.nl ESMTP Postfix
2 K: HELO www.security.nl
3 O: 250 Nice to meet you
4 K: MAIL FROM: spammer@example.com
Werking
Zowel SPF als FairUCE grijpen in tussen de regels 4 en 5. Om SPF te laten werken dient posterderbedrijf X een lijst met autokentekens te publiceren van koeriers die namens posterderbedrijf X mogen bezorgen; na regel 4 zal de ontvanger via SPF op zoek gaan naar die gegevens. Als posterderbedrijf X daarwerkelijk zo'n lijst heeft gepubliceerd, en het kenteken 12-AB-CD komt daar NIET op voor, dan zal de ontvanger bij 5 een negatief antwoord geven om daarna de verbinding te verbreken.
Terzijde, om misverstanden te voorkomen: hoewel een autokenteken eenvoudig is te vervalsen lukt dat met IP-adressen in de praktijk niet, waarmee dit de enige zekere factor in een email transactie is. Vergelijkbaar met de koerier hoeft het IP-adres echter niets te zeggen over de identiteit van de afzender, dit is nl. vaak van een mailserver tussen de afzender-PC en jouw mailserver.
SPF records worden in DNS gepubliceerd, en geven aan "wie namens mij mag bezorgen". Om precies te zijn, deze DNS records geven aan welke IP-adressen (of reeksen) namens een domain mail mogen aanbieden aan derden. Dat werkt echter alleen als de ontvangende partij deze check daadwerkelijk uitvoert, en dat gebeurt nauwelijks.
In tegenstelling tot SPF maakt FairUCE geen gebruik van speciale DNS records, maar probeert die gegevens uit het "Return-Path" te halen, d.w.z. het afzenderadres in regel 4. Daarbij probeert FairUCE te gokken wat de IP-reeks van het domain zal zijn, om daarna te bepalen of het IP-adres van de aanbieder binnen die reeks valt. Als dat zo is gaat FairUCE ervan uit dat het NIET om spam gaat. Valt het adres niet binnen die reeks, dan wordt een mailtje "teruggestuurd" met het verzoek om een bevestiging van het eerste mailtje, bijv. door een webpage te bezoeken en iets in te vullen, of door een response-mail als reply op die challenge naar een opgegeven adres te zenden.
Effectiviteit
Zolang dergelijke mechanismes nauwelijks worden toegepast, zullen ze inderdaad een deel van de spam tegenhouden, echter hoofdzakelijk junk die vanaf zombie machines wordt verzonden. Spammers die "netjes" vanaf hun eigen mailservers reclame verzenden (waarbij in veel gevallen regelmatig van IP-adressen wordt gewisseld, zodat blacklisten niet altijd even effectief is), pak je hier niet mee. Niets belet ze om naast hun gewone DNS records ook SPF records aan te passen, en van FairUCE hebben deze spammers al helemaal geen last.
Maar ook spammers die zombies misbruiken hebben niets te vrezen van SPF of FairUCE. Het enige dat ze hoeven te doen is het domain van de PC in het afzenderadres opnemen (i.p.v. een random domain, dit is een koud kunstje). Vanaf een backdoored Chello PC kunnen ze als afzenderadres
Problemen
Waarom klaag ik er zo over als het voorlopig wel een beetje werkt? Omdat gesuggereerd wordt dat dit goede oplossingen zijn tegen spam, terwijl ze andere zaken slopen en tot extra overlast leiden. "Sender" uit SPF wekt de indruk dat de afzender geauthenticeerd wordt; dat is onjuist. Er wordt alleen naar een IP-adres gekeken dat vaak van een legitieme mailserver "onderweg" is, en van het afzenderadres wordt het userdeel genegeerd. Sterker nog, SMTP staat toe dat het afzenderadres geheel ontbreekt (regel 4 luidt dan: MAIL FROM: ); SPF en FairUCE zijn kansloos bij dergelijke mails. Bovendien voeren beide geen enkele check uit op de From: en Reply-To: velden die, in tregenstelling tot het Return-Path, in veel email programma's worden getoond. Daar kunnen spammers dus nog steeds liegen wat ze willen.
Beide mechanismes maken forwarding nagenoeg onmogelijk. Als je bijv. van provider wisselt, en je nieuwe provider checkt SPF records, zal een email die afkomstig is vanaf een domain dat SPF records publiceert en door je oude provider wordt doorgestuurd, door je nieuwe provider worden geweigerd. Ook kun je alleen nog goed vanaf je PC thuis "namens de zaak" mail verzenden als je die via de mailserver van je zaak kunt relayen. FairUCE gaat al mank indien de uitgaande mailserver een IP-adres in een andere reeks heeft dan de MTA waar het MX record voor is gedefinieerd (en meerdere MTA's maken het testen er niet eenvoudiger op).
Daarnaast is FairUCE, net als alle andere "challenge/response" antispam emails, op z'n minst egoistisch te noemen. Deze C/R wordt namelijk toegepast als er twijfel bestaat over de authenticiteit van de afzender. Maar als die liegt, waar gaan die challenges dan wel naar toe? Als je "pech" hebt spoofen spammers JOUW email adres als afzender in een miljoen spams, resulterend in een Joe-job (genoemd naar ene Joe die dit als een van de eersten overkwam). Opzettelijke DoS-attacks zijn zo ook mogelijk; jouw account en/of server wordt dan niet bestookt door die zombies zelf, maar door ISP mailservers. Dit is erger dan gewone spambounces (die het gevolg zijn van spam die niet kan worden afgeleverd), want die worden door de meeste spamfilters ook als spam herkend; deze requests niet. Ten slotte zullen "legitieme" onvangers van challenge/response requests (bijv. omdat jij je mail laat forwarden, wat zeker problemen geeft als je op een maillijst staat ingeschreven) deze nauwelijks op prijs stellen.
Toch zinvol?
SPF is ooit ontworpen om "site-Joe-jobs" te voorkomen, maar is daarna vooral als anti-spam oplossing gepromote. Als je kunt leven met de nadelen, dan kun je voor jouw site SPF records publiceren, en daarmee voorkomen dat email die NIET vanaf jouw site verzonden is daar wel vandaan lijkt te komen. Mits alle ontvangers SPF records checken, en dat zijn er niet zoveel dus is het de vraag of dit veel uithaalt, en je nooit voorkomt dat iemand anders jouw mail adres in het From: veld opneemt. Wel kun je SPF-record checks meenemen als weegfactor bij spamfilters die ook op andere criteria checken. Zolang niet iedereen dit doet (en spammers zich niet aanpassen) hou je er wellicht wat spam mee tegen - maar mogelijk ook legitieme forwards en maillist posts.
FairUCE zou ik helemaal links laten liggen, behalve het aantal spams in je inbox zou ook het aantal vrienden of klanten wel eens af kunnen nemen...
onmogelijk. Als je bijv. van provider wisselt, en je nieuwe
provider checkt SPF records, zal een email die afkomstig is
vanaf een domain dat SPF records publiceert en door je oude
provider wordt doorgestuurd, door je nieuwe provider worden
geweigerd.
moeite om DNS-records te updaten. Wie van provider wisselt
forward niets maar past de MX-records aan zodat het
DNS-record naar het juiste systeem blijft wijzen.
Mail forwarden is iets voor Jan met de Pet.
SPF is ook behoorlijk in gebruik maar checkt een gemiddelde
Nederlandse ISP hier nog niet op.
SPF wil gewoon zeggen: mag dit systeem (sender) voor het
aangegeven domein posten. Zo nee, dan wordt het adres
blijkbaar geforged of probeert het te spammen. Zo ja, dan
weet je dat sender gemachtigd is om voor het aangegeven
domein post te verzenden.
Voor de goede orde: zowel virussen, worms als spammers
weerhouden zich er niet van afzenderadressen te faken. Een
bijkomstig voordeel van SPF is wanneer dit in een omgeving
is geïmplementeerd dat deze mede worden geweerd indien de
sender niet overeenkomt met die in de domainrecords zijn
gemachtigd. Ook wordt het met SPF moeilijker gemaakt om uit
naam van een organisatie valse berichten te versturen.
Daarom heeft bijvoorbeeld Microsoft ook SPF-records
geïmplementeerd. Dus wanneer jij een bericht uit naam van
Microsoft ontvangt die helemaal niet van Microsoft afkomstig
is heb jij een brakke mailserver (of ISP).
Dat is SPF en dus ook SenderID. Niet speciaal tegen Spam,
wel tegen email address forgery.
In plaats van de vele blacklists die er bestaan moet er 1 whitelist komen.
Iedereen die een mailserver wil draaien moet zich daarop met naam -
adres - ipnummer. ..schoenmaat enz. registreren. Op dat moment kan het
koren al van het kaf worden gescheiden. Als men door de registratie heen
komt en er blijkt toch SPAM van de server te komen, dan voor altijd weren:
in ieder geval de eerste 246 jaar.
Elke mailserver die mail ontvangt, MOET op de Whitelist checken (in SMTP
opnemen) of het IPNUMMER van de verzendende mailserver er ook
daadwerkelijk op staat. Zo niet dan verbinding verbreken, voordat er ook
maar iets verzonden is.
In het begin een "beetje" veel werk, maar ik ben er van overtuigd dat er nu
éénmaal een grote operatie nodig is om SPAM uit te bannen.
Commentaar aub !
Weet je wat het hele eieren eten is: spam is ontzettend
relatief, krijgt steeds een ander gezicht en verhoud zich
steeds anders.
M'n vorige bericht (over SPF dat niet speciaal tegen spam is
maar wel tegen email address forgery) was dan ook geheel
conform Erik's stuk. Het geeft aan dat hij gelijk heeft dat
middelen moeten worden ingezet waarvoor zij bedoelt zijn.
Dat er leuke neveneffecten aan verbonden kunnen zijn maakt
dit niet tot dat doel. Dat bedoelt Erik m.i.
Voor het tegenhouden van spam kun je gelet op de aard ervan
geen eenduidige oplossing bedenken, het zal vooral een
individuele oplossing op maat inhouden.
Je wil doorgaans world-wide bereikbaar zijn voor
ondernemingen die nog niet eerder contact met je hebben
gehad, potentiële klanten. Maar je wil geen spam ontvangen.
Dat is opzich een contradictio in terminis :)
Handig maar beduidend minder vaak voorkomend is wanneer van
te voren al duidelijk is van wie er legitiem post
wordt ontvangen. Die whitelist je dan waarbij je al het
overige kunt weren.
Wanneer in het meest voorkomend geval niet vooraf bekend van
wie er legitiem post kan worden ontvangen zijn er een aantal
methoden om bekende spam-definities (vergelijkbaar met die
van virus-definities) te herkennen en te weren. Net als voor
virussen geldt is dat dit niet waterdicht is en er nog
altijd kans bestaat op het (in mindere mate) ontvangen van
spam maar je wel breed bereikbaar bent.
Geheel in de lijn van het artikel kàn SPF wèl een gunstig
bijeffect hebben in het herkennen van spam maar is het daar
niet het middel voor.
Voor wat betreft het wereld-wijd whitelisten: spammers
kunnen zich ook laten whitelisten totdat ze weer verwijderd
worden. Dat zou bovendien een gigantische administratieve
taak inhouden en zou je je zorgen kunnen maken of zo'n
gecentraliseerd gebeuren dan niet teveel macht krijgt. Men
weet nu regelmatig al geen omgang te vinden met blocklists
waardoor bepaalde ISP's onbereikbaar zijn voor legitimate
post. Willekeur (waarschijnlijk door gebrek aan
brainstormen) heeft in zekere zin al de overhand. Grappig is
dat bij zulke ISP's het spamgehalte nog altijd vrij hoog is
zoals bij Zonnet. Dus als je legitieme mail er niet
rechtstreeks wordt afgeleverd, dan waarschijnlijk wel in
spamvorm :)
en single point of failure
adaptatie: niemand gaat het gebruiken tenzij iedereen het
doet, dit is de reden dat we nog steeds vrij oude
protocollen gebruiken, als het niet backwards compatible is
dan gaat dat nooit lukken
single point of failure: er is *geen* manier om zo'n lijst
live bij te houden (het moet electronisch vanwege de
miljoenen servers die erbij komen en eraf gaan steeds), ten
eerste omdat er geen computer is die het aan zou kunnen,
laat staan de bandbreedte heeft om iedereen te serven (of je
zou een hierarchisch systeem van opslaan en daarnaast
caching moeten hebben. dns dus), ten tweede gaan alle
spammers hem tegelijk aanvallen, is het niet om hun naam
erop te krijgen dan dossen ze hem wel, waardoor helemaal
niemand meer kan mailen, en dus terugvalt naar gewone mail.
> Wie van provider wisselt forward niets maar past
> de MX-records aan zodat het DNS-record naar het
> juiste systeem blijft wijzen.
Ja, indien het om een bedrijf gaat dat verhuist. Waar
ik op doel zijn personen die verkassen, waarna zij
nog enige tijd onder hun oude email adres bereikbaar willen
zijn. Bijv. in de wetenschappelijke wereld is het gangbaar
om email adressen in publicaties te zetten, en het is niet
handig als dat doodloopt zodra iemand het onderzoek elders
voortzet. Het mooiste van het verhaal is dat Pobox van
oudsher een bedrijf is dat forwarding services aanbiedt:
http://pobox.com/services.mhtml#fwd.
Waarschijnlijk om die reden gaf Meng Weng Wong, de bedenker
van SPF, begin 2004 toe dat forwarding niet zomaar uit SMTP
geschrapt kan worden, en bedacht in de haast een kansloze
fix genaamd SRS. Een veelzeggende discussie tussen onder
meer Meng Weng Wong, fervent Postfix gebruiker Liviu Daia en
onze landgenoot Wietse Venema (de auteur van Postfix) vind
je om en nabij deze post:
http://archives.neohapsis.com/archives/postfix/2004-01/0980.html.
In message 0982 laat Wietse zien dat SRS open relays
genereert, iets wat er m.i. in de huidige SRS
http://spf.pobox.com/srspng.html nog steeds
griezelig uitziet.
> Ook wordt het met SPF moeilijker gemaakt om uit
> naam van een organisatie valse berichten te versturen.
Enigszins. Wat ik in mijn betoog onvoldoende duidelijk maak
is dat het "pakket" de volledige email message betreft,
inclusief alle headers waaronder het From: veld. SPF
beschermt alleen het domain deel van het return-path.
Voorbeeld: vanaf een gecompromitteerde comcast.net PC wordt
een phishing spam verzonden. Als comcast.net SPF records
publiceert, zal de spammer, om SPF te omzeilen, in het
return path een willekeurige gebruikersnaam @ comcast.net
moeten specificeren; zonder comcast SPF records kan
hij ook het domain vrij kiezen, mits dat
domain ook geen SPF records publiceert. Echter, in het From:
veld kan hij altijd zetten wat hij wil, bijv. elk
willekeurig Microsoft of Visa email adres. En dat is
wat de mensen zien in hun email programma, niet het
return-path.
SPF verhindert dus niet dat persoon A van bedrijf (of ISP) X
zich voordoet als persoon B van X (waarbij X de grootte van
aol.com kan hebben). Zodra SPF en dergelijke gemeengoed
worden, zullen spammers en virusschrijvers zich onmiddellijk
aanpassen, in dit geval is dat een koud kunstje.
Erik van Straten
wordt een mailtje "teruggestuurd" met het verzoek om een
bevestiging van het eerste mailtje, bijv. door een webpage
te bezoeken en iets in te vullen, of door een response-mail
als reply op die challenge naar een opgegeven adres te zenden."
Maar is dat het werkelijke mechanisme van FairUCE?
Zie <news:42420261$0$150$e4fe514c@news.xs4all.nl>.
Mijn anti-spam-voorstel is dat elk bericht een "stempeltje"
van de server krijgt, denk aan een commentaar-veld achterin
de Message-ID-header. Dat stempeltje is net als bij
DCC_CHECK een hash van doorslaggevende delen van het
bericht, maar dan via een public-/private-key ondertekening,
met de public-key in een DNS-record.
Ruud H.G. van Tol
Razor2 en DCC check........misschien als extra:
Reversed lookup van domein (mx) record inbouwen en
verifiëren....eventueel een sessie openen op de SMTP poort en response
verifiëren
Mzls
Ik heb in ieder geval geen last van Spam......onderschep tussen de 200 en
300 spam berichten per dag....ik zit op een percentage van 99.9% met
0.1% false positives(webmail verstuurde e-mails)
> Maar is dat het werkelijke mechanisme van FairUCE?
en noemt een news thread, die zo te zien hier webbased is te
bekijken:
http://groups-beta.google.com/group/nl.internet.misbruik/browse_thread/thread/46c491bb37689043/4f0d96dad34ba51f#4f0d96dad34ba51f
Velen lijken zich te baseren op het artikel "Spamming
spammers?"
http://money.cnn.com/2005/03/22/technology/ibm_spam/
Hoe FairUCE precies werkt weet ik ook niet. De vage
informatie op de webpage (met een gokkende CNN journalist
als gevolg?) helpt ook niet echt, maar dat het een
challenge/response system betreft, is duidelijk.
Onderaan de FAQ page van FairUCE lees ik: "Legitimate
senders know immediately that a user hasn't received their
email, and they can click a button to have it delivered". En
als ik FairUCE download, uitpak en naar de file
"./templates/challenge.template" kijk, zie ik die beginnen met:
Hi $NAME,
Your message entitled "$SUBJECT" has not yet been delivered
to $MYNAME because it arrived from $CLIENTDOMAIN instead of
$EXPECTEDDOMAIN. Please select one of the following
options:
Dit lijkt me niets te maken hebben met numerieke codes die
in SMTP transacties kunnen worden teruggeven. Dit wordt ook
bevestigd door het feit dat er duidelijk sprake is van het,
by default 1 uur, in de MTA (Postfix) queue houden van
twijfelachtige messages, om de al dan niet echte
afzender de kans te geven te reageren (allemaal zaken waar
ervaren postmasters onmiddellijk vraagtekens bij zetten).
I.p.v. aan de poort rejecten worden twijfelachtige messages
dus eerst geaccepteerd, waarna alsnog geweigerde messages na
1 uur worden "teruggestuurd" naar de afzender - die het niet
was, en dus dankzij FairUCE 2x lastig gevallen/gespammed wordt.
N.B. spammers gebruiken vaak random usernames als afzenders,
maar ze hebben natuurlijk al een database met email
adressen, dus waarom zouden ze die niet gebruiken? (Ze
gebruiken meestal wel bestaande afzender domains
omdat daar al veel op gecheckt wordt). Naarmate meer MTA's
"Sender Address Verification" gebruiken, dus testen of het
gehele afzender adres bestaat (met SMTP kun je helaas
niet checken of dat de echte afzender is), zullen
spammers vaker bestaande email adressen gaan misbruiken;
veel virussen doen dat overigens al. Daarbij gebruiken ze
natuurlijk NIET het emailadres van de eigenaar van de
gecompromitteerde PC, maar van een derde.
Ik mag hopen dat gebruikers van FairUCE eerst blacklists als
XBL en Spamcop raadplegen (en wellicht andere technieken
zoals greylisting). In elk geval zie ik in de distributie
wel een file "known-dchp-list" met een aantal patterns om
typische dialups/dsl gebruikers te kunnen filteren
(waaronder "dhcp*.*.rr.com"). Maar ik zou m'n vingers er
niet aan willen branden.
M.b.t. jouw anti-spam-voorstel: elk idee is welkom, maar ik
zie zo snel niet hoe dit spam onderscheidt van legitieme
mail. Misschien kun je een uitgewerkt voorstel schrijven en
aan de redactie vragen dat te publiceren? Dan heb je een
eigen thread waarop men van gedachten kan wisselen.
Erik van Straten
Op woensdag 23 maart 2005 13:15 schreef Anoniem onder meer:
> Wie van provider wisselt forward niets maar past
> de MX-records aan zodat het DNS-record naar het
> juiste systeem blijft wijzen.
Ja, indien het om een bedrijf gaat dat verhuist. Waar
ik op doel zijn personen die verkassen, waarna zij
nog enige tijd onder hun oude email adres bereikbaar willen
zijn.
gelaten terwijl dat inderdaad waar is, waarvan je een
passend voorbeeld geeft:
om email adressen in publicaties te zetten, en het is niet
handig als dat doodloopt zodra iemand het onderzoek elders
voortzet.
respect 'gewone privé gebruikers' waarbij het gebruik van
een emailadres bij hun ISP gemeengoed is.
een bedrijf is dat forwarding services aanbiedt:
http://pobox.com/services.mhtml#fwd.
Waarschijnlijk om die reden gaf Meng Weng Wong, de bedenker
van SPF, begin 2004 toe dat forwarding niet zomaar uit SMTP
geschrapt kan worden, en bedacht in de haast een kansloze
fix genaamd SRS. Een veelzeggende discussie tussen onder
meer Meng Weng Wong, fervent Postfix gebruiker Liviu Daia en
onze landgenoot Wietse Venema (de auteur van Postfix) vind
je om en nabij deze post:
http://archives.neohapsis.com/archives/postfix/2004-01/0980.html.
In message 0982 laat Wietse zien dat SRS open relays
genereert, iets wat er m.i. in de huidige SRS
http://spf.pobox.com/srspng.html nog steeds
griezelig uitziet.
van forwarding dacht ik teveel in m'n eigen straatje maar is
dit inderdaad een punt van aandacht.
Het forwarden zou in een iets andere vorm gegoten kunnen
worden om dit probleem te omzeilen. Bijvoorbeeld het
oorspronkelijke bericht als bijlage forwarden of het in een
ander framework gieten en niet een op een.
> Ook wordt het met SPF moeilijker gemaakt om uit
> naam van een organisatie valse berichten te versturen.
Enigszins. Wat ik in mijn betoog onvoldoende duidelijk maak
is dat het "pakket" de volledige email message betreft,
inclusief alle headers waaronder het From: veld. SPF
beschermt alleen het domain deel van het
return-path.
dat SPF vaak wel op die manier is geïmplementeerd. Daarnaast
heb je de keuze ook van het HELO/EHLO argument het
domeindeel daarmee te toetsen alsook het domeindeel van FROM:
Dit is wel meer 'challenging' en vereist meer inspanning om
te realiseren, waarmee in principe de aangegeven bezwaren
oplossen.
wordt
een phishing spam verzonden. Als comcast.net SPF records
publiceert, zal de spammer, om SPF te omzeilen, in het
return path een willekeurige gebruikersnaam @ comcast.net
moeten specificeren; zonder comcast SPF records kan
hij ook het domain vrij kiezen, mits dat
domain ook geen SPF records publiceert. Echter, in het From:
veld kan hij altijd zetten wat hij wil, bijv. elk
willekeurig Microsoft of Visa email adres. En dat is
wat de mensen zien in hun email programma, niet het
return-path.
SPF verhindert dus niet dat persoon A van bedrijf (of ISP) X
zich voordoet als persoon B van X (waarbij X de grootte van
aol.com kan hebben). Zodra SPF en dergelijke gemeengoed
worden, zullen spammers en virusschrijvers zich onmiddellijk
aanpassen, in dit geval is dat een koud
kunstje.
geïmplementeerd dat deze zich alleen op het return-path
concentreert zijn deze bezwaren terecht.
> Het forwarden zou in een iets andere vorm gegoten
> kunnen worden om dit probleem te omzeilen.
Hier hebben al heel wat knappe koppen over gepeinsd, en geen
goede oplossing gevonden. Feit is dat SMTP vereist dat mail
niet zoekraakt: ofwel het wordt aangenomen, ofwel het wordt
gebounced, ofwel het wordt geweigerd met een foutcode
(waarna het alsnog gebounced kan worden). Dit geldt ook voor
forwarded mail.
Oplossingen waarbij het return-path "onderweg" gewijzigd
wordt (nodig om onder SPF te kunnen forwarden) leiden voor
je het weet tot open relays en/of ondermijnen het
doel van SPF. Daarnaast, de meeste oplossingen
vereisen dat elke internet mail server wordt
aangepast (en het SMTP protocol wordt herzien). Dus: met SPF
kun je niet forwarden; maar zoals ik eerder aangaf, er zijn
best situaties denkbaar waarin dat geen probleem hoeft te zijn.
Erik van Straten schreef:
>> SPF beschermt alleen het domain deel van het
>> return-path.
Anoniem schreef daarop:
> Dat is niet geheel juist. Wel is het zo dat SPF
> vaak wel op die manier is geïmplementeerd
Sorry, maar de bedenkers van SPF beschrijven het zelf
linksonder in http://spf.pobox.com/gauntlet.png,
verwijzend naar het From: veld, als volgt:
[color=blue]Dit is de "From:" header. SPF kijkt niet naar de
header "From:". De meeste maillijsten laten het "From:"
adres ongemoeid, maar wijzigen wel de "envelope sender"
[/color] (d.w.z. het return-path) [color=blue] in een
speciaal lijst-eigenaar adres dat bounces afhandelt. Het zou
onjuist zijn indien SPF het "From:" adres zou checken.
Daarnaast, de test op de "bevoegde afzender" vindt ruim
plaats voordat de header is verzonden, dus deze check
zou zowiezo te laat plaatsvinden.[/color]
Kortom, er zijn legitieme toepassingen (naast maillijsten
ook bounces) waarbij het From: veld afwijkt van het
Return-Path; alle email met verschillen daartussen
als spam bestempelen zal false positives opleveren.
Hetzelfde geldt voor de HELO/EHLO "hostname" (regel 2 in m'n
voorbeelden bovenaan): -helaas- zijn er legitieme
mailservers waarbij deze niet overeenkomt met de DNS
hostname (configuratiefouten en/of DNS problemen kunnen
bijv. EHLO localhost.localdomain opleveren, terwijl het
IP-adres niet 127.0.0.1 is). Prima weegfactor in
SpamAssassin o.i.d. maar ik zou deze niet doorslaggevend maken.
Ik hoop hiermee mijn standpunt voldoende te hebben
beargumenteerd. Ik begrijp nog steeds niet waarom grote
bedrijven als AOL en Microsoft zich achter dergelijke
"antispam" oplossingen scharen, die zelfs als antispoofing
middel uiteindelijk tekort zullen schieten. Waarschijnlijk
is er sprake van een dubbele agenda (mogelijk hebben zij
zelf en/of sommige van hun klanten veel last van
site-Joe-jobs, en/of marketing speelt een rol), zo niet dan
kan ik dit niet anders dan kortzichtig noemen.
Erik van Straten
Spamikaze http://spamikaze.nl.linux.org/?
Want mijn inziens moet je (net als bij virii en
spy-/mal-/adware) sommige dingen combineren zover je
werkomgeving het toelaat.
SPF en / of FairUCE zullen misschien niet geschikt zijn voor
antispam, maar wel meehelpen om misbruik van het netwerk
tegen te gaan op welk front dan ook.
Het is in elk geval creatief omgaan met het oude SMTP zolang
het nog bestaat en overal wordt toegepast.
Mijn idee is, dat Spamikaze meer vraagt van de onschuldige
gebruiker, maar wel ontmoedigend is voor de spammer die
willens en wetens zoveel mogelijk mensen wil bereiken.
- Unomi -
> Zou Erik van Straten misschien een idee hebben over
> Spamikaze http://spamikaze.nl.linux.org/?
In een bijna identieke discussie in januari 2004 werd ik ook
al verleid om hier uitspraken over te doen. Ik heb er toen
en nu naar gekeken. Ik zou het nog steeds niet gebruiken.
Ik beargumenteer dit nu niet omdat:
1) het off-topic is
2) ik niet op verzoek willekeurige producten evalueer
3) (de belangrijkste reden) Unomi verder schreef:
> SPF en / of FairUCE zullen misschien
> niet geschikt zijn voor antispam, maar wel
> meehelpen om misbruik van het netwerk
> tegen te gaan op welk front dan ook
zonder dit verder te onderbouwen, laat staan op mogelijke
nadelen te wijzen.
Dit is nu precies het probleem van veel
anti-narigheid oplossingen. Mensen, helaas ook gezaghebbende
en journalisten, zijn spam e.d. zo zat (of zien brood in de
"fix") dat ze, zonder over consequenties na te denken,
elk voorstel omarmen. En veel erger, dergelijke
voorstellen ongefundeerd promoten. En zodra ze op hun
vingers getikt worden, "mischien niet" gaan zeggen om zich
vervolgens te verdedigen dat het product wel ergens
anders goed voor is.
Spam is een probleem tussen onze oren. We willen in principe
van iedereen mail kunnen ontvangen, maar niet het type
waarvan we na openen vaststellen dat het ongewenst is.
Vervolgens proberen we dit probleem met technische middelen,
die meestal niets anders zijn dan symptoombestrijding, aan
te pakken door patronen te zoeken. N.B. Ik bedoel hier
niet alleen spam content filtering mee, maar alle
antispam maatregelen zoals dichtzetten van open relays,
blokkeren van source-routing etc., allemaal voorzieningen
die [i[niet[/i] tot gevolg hebben gehad dat de hoeveelheid
spam afnam - integendeel.
Zodra we een patroon ontdekken dat in 90% van narigheid
(spam, virussen, spyware) en 10% van legitieme zaken
voorkomt roepen we Eureka en "fixen" het probleem door een
blokkade op te werpen. Waarna narigheidsproducenten zich
snel aanpassen, en het verder helaas pindakaas blijft voor
die 10% legitieme zaken die lijden onder de "fix". Erger, we
dwingen narigheidsproducenten soms in een hoek waar ze nog
meer schade veroorzaken dan ze nu al doen.
Ik wil hier niet mee zeggen dat alle symptoombestrijding
slecht is (er zijn er waar ik ook achter sta), maar wel dat
we te vaak vergeten dat het meestal om een tijdelijke
oplossing gaat, en, als we er zelf geen nadelen van
ondervinden, we ons niet eens in de problemen van derden
wensen te verdiepen.
Unomi, dank je wel voor jouw bijdrage, die precies laat zien
wat ik bedoel. Het is overigens niet mijn bedoeling is om
jou te kleineren; heel veel mensen denken op dezelfde
manier maar hebben niet het lef gehad om zo te reageren -
jij wel.
Zodra je jouw mening over SPF en FairUCE hieronder goed
onderbouwt (in mijn ogen) wil ik ook wel wat kwijt over
Spamikaze.
Erik van Straten
Reverse DNS (MX check) gaat niet altijd op.
ik draai hier zelf een eigen email server, werkt lekker, nu
heb ik sinds een paar maanden een PDA ,waar ik dus ,dank zij
de GPRS verbinding ook mee kan email (etc etc) ,de enige
methode hoe ik email aan de praat kreeg was via mijn eigen
email server, met reverse DNS check UIT !..
Deze posting is gelocked. Reageren is niet meer mogelijk.
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.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
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.