Sambar Server Tips en Trucs !
|
|
Tips Home | ||
|
Sambar Server Tips en Trucs ! |
|
||
|
Email Headers Lezen Alles over Email HeadersInleidingDit document stelt zich tot doel om op begrijpelijke wijze de werking van email headers te beschrijven. In de eerste plaats is het gericht aan slachtoffers van ongewenste commerciële email ("spam"). We leggen uit hoe men deze berichten dient te begrijpen, en hoe men de oorsprong ervan kan achterhalen. Dit is niet altijd even evident, omdat spammers meestal een aantal technieken gebruiken om hun ware identiteit te verhullen. Hiernaast kan dit document ook nuttig zijn in het begrijpen van de algemene werking van email op het Internet. In dit document wordt niet rechtstreeks beschreven hoe u zelf email headers kan manipuleren, maar sommige informatie kan hiertoe wel een aanzet zijn. De auteur is echter op geen enkele wijze verantwoordelijk hiervoor en is zelfs tegenstander om header-informatie van emails zonder goede reden te veranderen. Elk gebruik van dit document voor dergelijke doeleinden is tegengesteld aan de opzet van dit document. De voorbeelden in dit document gebruiken verschillende fictieve domeinnamen met bijbehorende IP-adressen ("Internet Protocol"-adressen). De kans dat deze domeinnamen in de toekomst ook effectief zullen gebruikt worden is niet onbestaande. Hetzelfde geldt voor alle IP-adressen in de voorbeelden - deze zijn niet geïdentificeerd op het moment van schrijven, maar zullen vroeg of laat toegekend worden. Uiteraard heeft niets in dit document betrekking op de toekomstige gebruikers van de genoemde domeinnamen of IP-adressen. Waar komt email vandaanDit gedeelte bestaat uit een korte analyse van de levenscyclus van een email. Deze achtergrondinformatie is belangrijk om te kunnen begrijpen welke informatie email-headers nu eigenlijk bevatten. Op het eerste zicht lijkt het erop dat een email van de verzender direct bij de ontvanger terechtkomt zonder omwegen. Dit is onder normale omstandigheden echter nooit het geval. Elke normale email passeert tenminste 4 computers tijdens zijn levenscyclus.
De meeste organisaties beschikken over een aparte machine om email te behandelen, een zogenaamde mailserver, en dit is normaal gesproken niet dezelfde machine als degene die de ontvangers gebruiken om hun emails te lezen. De uiteindelijke ontvangers zijn surfers die via hun provider (ISP) een verbinding maken met het Internet. De "client" computer is de eigenlijke computer van de surfer en de "server" is dan één van de machines aan de kant van de provider. Als een surfer een email verzendt, stelt hij eerst de email samen op zijn eigen machine en verzendt deze vervolgens naar de mailserver van de provider. Op dit moment geeft de computer van de gebruiker de email uit handen en heeft er verder geen controle meer over. De mailserver van de provider dient de email echter nog af te leveren. Hiervoor gaat deze op zoek naar de mailserver van de ontvanger, communiceert hiermee en levert de email af. De email blijft dan op de mailserver van de ontvanger staan totdat de ontvanger zijn mailbox opent om de email binnen te halen op zijn eigen computer. Door het binnenhalen wordt de email meestal verwijderd op de mailserver van de ontvanger. Neem bijvoorbeeld 2 fictieve gebruikers, <rth@bieberdorf.edu> en <tmh@immense-isp.com>. tmh is een gebruiker van N.V. Immense ISP, en gebruikt een emailprogramma genaamd Loris Mail (fictieve benaming). Gebruiker rth behoort tot een faculteit van het Bieberdorf Instituut, met een computer op zijn bureau die in netwerk staat met de andere computers van het instituut. Als rth een email naar tmh wil sturen, typt hij de boodschap op zijn computer (die bijvoorbeeld de naam alpha.bieberdorf.edu heeft), de tekst wordt dan verzonden naar zijn mailserver, mail.bieberdorf.edu. Dit is het laatste wat rth van deze email afweet, vanaf dit moment wordt de mail verder afgehandeld door machines waarover rth geen controle heeft. De mailserver mail.bieberdorf.edu ziet vervolgens dat er een email binnenkwam gericht aan iemand van immense-isp.com. De mailserver mail.bieberdorf.edu contacteert aldus de mailserver bij N.V. Immense ISP (mailhost.immense-isp.com) en levert de email af. Vanaf dit moment wordt de email bewaard op mailhost.immense-isp.com tot het moment waarop gebruiker tmh inlogt om zijn mail te lezen; op dat ogenblik levert de mailserver alle wachtende emails af, in ons voorbeeld dus ook de boodschap van rth.
Tijdens dit proces worden er 3 headers aan de email toegevoegd: eentje op het moment van intypen door het emailprogramma van rth, eentje op het moment waarop de email overgedragen wordt naar mail.bieberdorf.edu, en eentje bij de transfer van Bieberdorf naar Immense ISP (normaal gesproken voegt de verbinding die de email ontvangt geen eigen headers toe). Laten we nu de evolutie van deze headers in detail bekijken. Wanneer rth de email verstuurt en aflevert bij
mail.bieberdorf.edu:
Wanneer mail.bieberdorf.edu de email transfereert naar
mailhost.immense-isp.com:
Wanneer mailhost.immense-isp.com de email verwerkt heeft
en bewaart voor tmh voor wanneer tmh zijn nieuwe emails opvraagt:
Deze laatste reeks headers zijn degene die bij tmh toekomen wanneer hij zijn nieuwe mails binnenhaalt. Hieronder wordt regel per regel overlopen wat elke header precies betekent.
Deze email werd ontvangen door een machine die zichzelf
mail.bieberdorf.edu noemt...
...maar die eigenlijk mail.bieberdorf.edu heet (dus, dit
betekent dat deze machine zichzelf correct had geïdentificeerd) en
het IP-adres 124.211.3.78 heeft.
De machine die de email toekreeg, was
mailhost.immense-isp.com; en gebruikt een email programma genaamd
sendmail, versie 8.8.5/8.7.2 (het speelt niet echt een rol wat deze
versienummers betekenen behalve als u geïnteresseerd bent in dit
emailprogramma in kwestie).
De machine die de email toekreeg, heeft aan deze email
het ID-nummer LAA20869 toegekend. Dit wordt enkel intern gebruikt door
die machine, en is iets wat de systeembeheerder moet weten als hij de
email wenst op te zoeken in de logboekbestanden, maar heeft verder
geen betekenis voor anderen.
De email is gericht aan tmh@immense-isp.com. Merk op dat
deze header niets te maken heeft met de To: header (zie
verder).
De verwerking van de email gebeurde op dinsdag 18 maart 1997 om 14:39:24 's namiddags in de tijdzone "Pacific Standard Time" (8 uur achter op de standaard Greenwich tijd, vandaar de vermelding "-0800").
Deze regel heeft betrekking op de overdracht van de email van alpha.bieberdorf.edu (rth's computer) naar mail.bieberdorf.edu; deze overdracht vond plaats om 14:36:17 "Pacific Standard Time". De machine die de boodschap verzond, noemde zichzelf alpha.bieberdorf.edu, de echte naam ervan was (ook) alpha.bieberdorf.edu, en het IP-adres van deze machine was 124.211.3.11. De mailserver van Bieberdorf gebruikt sendmail versie 8.8.5, en heeft ID-nummer 004A21 aan deze email toegekend voor zijn interne verwerking.
De email werd verzonden door rth@bieberdorf.edu, die ook zijn echte naam opgeeft als R.T. Hood.
De email is gericht aan tmh@immense-isp.com.
De email werd verzonden om 14:36:14 in de tijdzone "Pacific Standard Time" op dinsdag 18 maart 1997.
De email werd voorzien van dit nummer door mail.bieberdorf.edu om het te kunnen identificeren. Dit ID-nummer is iets anders dan de SMTP en ESMTP ID-nummers in de Received:-headers, omdat het zal verbonden blijven aan de email gedurende heel zijn levenscyclus. De andere ID-nummers zijn enkel van toepassing op specifieke mail transacties op specifieke machines, zodanig dat het ID-nummer van de ene machine geen betekenis heeft op een andere machine. Soms bevat de Message-ID ook het email-adres van de verzender (zoals in ons voorbeeld), maar soms heeft het ook geen enkele op zichzelf staande betekenis.
De email werd verzonden door middel van een programma genaamd Loris, versie 2.32.
Het onderwerp van de email zoals de verzender het ingaf. Email ProtocollenDit gedeelte is wat technischer dan de andere, en behandelt de manier waarop een email van punt A tot punt B geraakt. Het is niet noodzakelijk dat u elk woord begrijpt. Maar als u vertrouwd bent met deze materie, zal u vreemde of ongewone email-constructies gemakkelijker begrijpen. Spammers gebruiken dikwijls met opzet vreemde/ongewone constructies, gedeeltelijk om verwarring te zaaien. Het begrijpen van dergelijke constructies is erg nuttig om te achterhalen wat er precies aan de hand is. Om over een netwerk te communiceren, gebruiken computers dikwijls toegangspunten genaamd poorten; dit kan men vergelijken met een frequentie waarop een computer "luistert" naar communicatie die afkomstig is van het netwerk. Om naar vele boodschappen tegelijkertijd te kunnen luisteren, heeft een computer verschillende poorten (frequenties) nodig, dit om de boodschappen duidelijk van elkaar te kunnen onderscheiden. Om deze reden worden poorten meestal genummerd. Bij systemen die zijn verbonden met het Internet (of systemen die dezelfde protocollen voor email gebruiken), is poort nummer 25 de meest belangrijke voor ons, omdat dit de poort is die gebruikt wordt om email te verzenden en ontvangen. Normaal VerloopLaten we even terugkeren naar het voorbeeld uit het vorige gedeelte, en meer specifiek naar het punt waar mail.bieberdorf.edu communiceert met mailhost.immense-isp.com. Op dat moment wordt door mail.bieberdorf.edu een verbinding op poort 25 geopend met mailhost.immense-isp.com, en doorheen die verbinding wordt de email verzonden, te samen met enkele administratieve gegevens. De commando's die mail.bieberdorf.edu hiervoor gebruikt en de antwoorden van mailhost.immense-isp.com zijn min of meer leesbaar voor mensen. Dit zijn commando's in een elementaire opdrachttaal genaamd SMTP, dit is de afkorting van Simple Mail Transfer Protocol. Iemand die de communicatie tussen beide machines zou volgen, ziet het volgende gebeuren (de commando's van mail.bieberdorf.edu staan in vetjes):
Deze communicatie gebruikt 5 commando's die de kern uitmaken van SMTP, namelijk HELO, MAIL FROM, RCPT TO, DATA, en QUIT. Er zijn ook enkele andere minder gebruikte commando's maar die zijn van minder belang voor de eigenlijke overdracht van emails. HELO identificeert de machine van de verzender. De regel "HELO mail.bieberdorf.edu" kan gelezen worden als "Hallo, ik ben mail.bieberdorf.edu". De machine van de verzender kan echter beweren wat hij wil, in principe kan deze hier ook zeggen "Hallo, ik ben frobozz.xyzzy.gov" (HELO frobozz.xyzzy.gov) of zelfs "Hallo, ik ben een verkeerd geconfigureerde computer" (HELO verkeerd geconfigureerde computer). In de meeste gevallen heeft de machine van de ontvanger echter een aantal middelen ter beschikking om de echte identiteit van de machine van de verzender te achterhalen. MAIL FROM zet de eigenlijke verwerking van email in gang; het betekent "Ik heb email af te leveren" met opgave van de benodigde specificaties. Het opgegeven email-adres bevindt zich in de zogenaamde "envelope From" (zie verder), maar is niet noodzakelijk hetzelfde email-adres als datgene van de verzender! Dit beveiligingslek is onvermijdelijk, want tenslotte kan de machine van de ontvanger niets weten over de gebruikers op de machine van de verzender. In sommige gevallen is dit beveiligingslek zelfs een zeer nuttige eigenschap. RCPT TO is een dubbel van MAIL FROM; het duidt het email-adres aan waarvoor de boodschap bestemd is. Eén enkele email kan verzonden worden aan meerdere ontvangers door meerdere RCPT TO commando's te gebruiken (zie het gedeelte over mail relaying; dit zal ook behandelen hoe dit kan misbruikt worden op onveilige systemen). Het opgegeven email-adres komt terecht in "envelope To" (zie verder) en bepaalt naar wie de email zal gestuurd worden, het speelt geen rol wat de To: regel in de email beweert. DATA start de eigenlijke transmissie van de email. Alles wat na DATA komt, wordt beschouwd als een deel van de boodschap. Er zijn geen beperkingen op de vorm van deze boodschap. Regels in het begin van de boodschap (vóór de eerste blanco regel) die met een enkel woord en puntkomma beginnen, worden door de meeste emailprogramma's beschouwd als headers. Een regel die enkel bestaat uit een punt, beëindigt de boodschap. QUIT beëindigt de verbinding. SMTP wordt volledig gedefinieerd in RFC 821. Er zijn vele kopijen van de RFC's beschikbaar op het Internet, en het loont zeker de moeite om RFC 821 te bestuderen omdat het de ingewikkelde processen van emailverwerking gedetailleerd beschrijft. Ongewone constructiesDe constructie hierboven werd enigszins vereenvoudigd voorgesteld. De voornaamste veronderstelling was daar dat de mailservers van beide organisaties vrije toegang hebben tot elkaar. Dit was bijna altijd het geval in de eerste dagen van het Internet, en het is ook vandaag soms nog zo in sommige configuraties. Na verloop van tijd werd het aspect beveiliging echter meer en meer belangrijk, en doordat organisaties en netwerken alsmaar groter werden (soms met vele afzonderlijke mailservers) worden dergelijke configuraties steeds zeldzamer. FirewallsDe meeste organisaties met computers op het Internet worden beschermd door één of andere vorm van firewall. Een firewall is een computer die optreedt als "toegangswachter" tussen de computers van een organisatie en het Internet, zodanig dat bijvoorbeeld crackers niet gemakkelijk toegang krijgen tot het bedrijfsnetwerk van IBM om vertrouwelijke informatie te bekijken. Vanuit het standpunt van een computer die mail wil afleveren aan een machine achter een firewall, betekent dit dat er eerst gecommuniceerd moet worden met de firewall. Dit stelt echter geen problemen, er komt enkel een extra "hop" in de levenscyclus van de email. De firewall treedt enkel op als een machine waarlangs de email passeert zonder meer. Stel dat immense-isp.com een firewall zou gebruiken, dan zouden de headers van ons voorbeeld er als volgt kunnen uitzien. Let vooral op de eerste regel (ik veronderstel hieronder dat de firewall de naam "firewall.immense-isp.com" heeft - maar eigenlijk is het niet zo'n goed idee om een machine een naam als "firewall" te geven omdat het dan duidelijk is voor iedereen dat deze machine als dusdanig optreedt, dit is belangrijke informatie voor crackers; meestal hebben firewalls daarom gangbare "onschuldige" namen).
Als alle uitgaande mail van bieberdorf.edu ook langs een eigen firewall zou geleid worden, zou er nog een bijkomende (gelijkaardige) Received:-regel verschijnen. Er kunnen ook machines betrokken zijn die strikt genomen geen firewalls zijn, maar eenvoudige passagepunten voor het regelen van de trafiek. Zo zou immense-isp.com bijvoorbeeld machines kunnen plaatsen in verschillende serverparken met meerdere gescheiden mailservers en één centrale machine (vb. met naam mailgate.immense-isp.com) die beslist naar welke mailservers inkomende emails moeten bezorgd worden. Volgende headers zijn bijvoorbeeld best mogelijk:
De historiek van deze email kan gereconstrueerd worden door de Received:-headers uit te lezen van beneden naar boven. Deze email kwam aldus van alpha.bieberdorf.edu naar mail.bieberdorf.edu, vervolgens naar firewall.bieberdorf.edu, dan naar firewall.immense-isp.com, dan naar mailgate.immense-isp.com en tenslotte naar mailhost3.immense-isp.com. Op mailhost3.immense-isp.com blijft de email aldus bewaard tot de gebruiker de email binnenhaalt naar zijn computer. RelayingDit zouden mogelijke headers kunnen zijn voor een email die een totaal verschillende levenscyclus heeft dan alle voorgaande voorbeelden:
Er zijn heel wat factoren die erop wijzen dat dit voorbeeld spam is, maar laten we even focussen op de Received:-regels. Deze email kwam oorspronkelijk van turmeric.com, ging vervolgens naar unwilling.intermediary.com, en van daar naar de uiteindelijke bestemming mail.bieberdorf.edu. Hoe is het mogelijk dat unwilling.intermediary.com betrokken is in de levenscyclus, ondanks het feit dat deze machine niets te maken heeft met verzender noch ontvanger ? Om het antwoord te begrijpen, is het noodzakelijk om de elementaire werking van SMTP onder de loep te nemen. In essentie heeft turmeric.com hier gewoon een verbinding gemaakt op de SMTP-poort van unwilling.intermediary.com met de opdracht "stuur dit bericht naar rth@bieberdorf.edu". Deze opdracht werd waarschijnlijk uitgevoerd op de meest directe manier die denkbaar is, namelijk door middel van een RCPT TO: rth@bieberdorf.edu commando. Op dat moment heeft unwilling.intermediary.com de volledige verwerking van de email overgenomen, omdat het de opdracht gekregen heeft om de boodschap te bezorgen aan een gebruiker van een andere domeinnaam (bieberdorf.edu). De machine unwilling.intermediary.com ging aldus op zoek naar de mailserver voor bieberdorf.edu en passeerde de email op de normale wijze. Dit proces heeft de naam mail relaying. In historisch opzicht waren er goede redenen om dergelijke relaying toe te laten. Op het grootste deel van het Internet werd eind jaren 1980 nooit mail verstuurd door machines rechtstreeks met elkaar te laten communiceren. In de plaats daarvan werd een route uitgestippeld die elke boodschap moest afleggen, en de boodschap werd aldus stap per stap verzonden langsheen deze route. Dit was een erg omslachtige manier van werken, vooral omdat de verzender de route vaak manueel moest afleggen! Vergelijk het met het posten van een brief van San Francisco naar New York, die als volgt zou moeten geadresseerd worden:
Het is duidelijk dat dit wel een nuttige werkwijze zou zijn voor het personeel van de post. Het postkantoor in Gary moet dan enkel weten hoe het de kantoren in Chicago en Elkhart moet contacteren, voor de rest moet dit kantoor niets doen (het is ook duidelijk dat dergelijke adressering niet efficient zou zijn voor de briefschrijver, net daarom wordt email ook niet langer afgehandeld op deze manier). Dit voorbeeld is precies hetzelfde hoedat email oorspronkelijk werd verzonden; het was aldus belangrijk dat de ene machine de andere een instructie kon geven in de vorm van "ik heb een email voor rth@bieberdorf.edu, deze dient verzonden te worden vanuit uw locatie naar turmeric.com, dan naar galangal.org, dan naar asafoetida.com, en tenslotte naar bieberdorf.edu". Vandaar dus relaying. Tegenwoordig wordt relaying vooral gebruikt door spammers om de oorsprong van hun boodschap te maskeren, en voor het afleiden van spam-klachten naar de (onschuldige) machine die de relaying voorziet in plaats van naar de eigenlijke oorspronkelijke machine. Een bijkomend voordeel voor de spammer is dat zijn machine niet belast wordt met het verwerken van adressen en het contacteren van ontvangers die zijn doorgegeven vanuit de machine van de spammer. Om die reden wordt relaying (in het bijzonder wanneer dit op grote schaal gebeurt) beschouwd als diefstal van de systeembronnen van een andere machine. Het essentiële punt bestaat erin dat de inhoud van de boodschap wordt voorzien op het punt van verzending (in ons voorbeeld dus bij turmeric.com), maar dat de machine unwilling.intermediary.com wordt gebruikt als een "tussen"-machine die enkel de verzending voor zijn rekening neemt. Er is vanuit unwilling.intermediary.com geen enkele controle over de verzender, net hetzelfde zoals het postkantoor in Gary geen controle heeft over de briefschrijver in San Francisco. Nochtans heeft het postkantoor in Gary wél de mogelijkheid om de eigen relaying uit te schakelen! Een bijkomende opmerking in de headers hierboven is dat de Message-Id:-regel wel werd ingevuld, maar niet door de oorspronkelijke machine (turmeric.com). Het is unwilling.intermediary.com die de Message-Id:-regel voorzag, dit duidt gewoon aan dat de oorspronkelijke machine (turmeric.com) zelf geen eigen Message-Id had opgegeven. Envelope HeadersIn het gedeelte over SMTP hierboven werd reeds kort het onderscheid aangehaald tussen "message" en "envelope" headers. Dit onderscheid en een aantal gevolgen ervan worden hieronder verder beschreven. In het algemeen kan men stellen dat de "envelope" headers worden gegenereerd door de machine die een boodschap ontvangt, en niet door de machine die ze verzendt. Volgens deze stelregel zijn Received:-headers eigenlijk "envelope" headers. Maar meestal hebben "envelope" headers enkel betrekking op de "envelope From" en "envelope To" aanduidingen in de email. De "envelope From" header wordt afgeleid van de informatie uit een MAIL FROM commando. Als een machine bijvoorbeeld de opdracht MAIL FROM: ginger@turmeric.com geeft, dan zal de machine die de opdracht ontvangt een "envelope From" header aanmaken die er als volgt uitziet:
Merk op dat er hier geen dubbelpunt gebruikt wordt, er wordt "From" toegevoegd, niet "From:". Meestal hebben "envelope" headers geen dubbelpunt op het einde; dit is echter geen universele stelregel maar is meestal wel gebruikelijk. Op dezelfde wijze wordt "envelope To" afgeleid van een RCPT TO commando. Als de verzender de opdracht RCPT TO: tmh@bieberdorf.edu geeft, dan krijgt de "envelope To" header de waarde tmh@bieberdorf.edu. Er is ook dikwijls geen header aanwezig die deze informatie bevat, soms is deze al aanwezig in de Received:-headers. Een belangrijk gevolg van de "envelope" informatie is dat de From:- en To:-headers geen enkele betekenis hebben. De inhoud van de From:-header wordt voorzien door de verzender en is bijgevolg ook de inhoud van de To: header. Email routes worden echter enkel aangestuurd door "envelope To" en nooit door de To:-header. Het voorbeeld hieronder illustreert een SMTP transactie volgens dit principe:
Dit zijn de betreffende headers:
Merk op dat From, From:, en To: alle worden opgegeven door de verzender, en deze hoeven niet noodzakelijk overeen te stemmen met de waarheid! Dit voorbeeld toont aan waarom men nooit kan afgaan op From, From:, en To: om de oorsprong van een email te achterhalen; deze headers zijn immers zeer gemakkelijk te vervalsen. Het belang van de Received:-headersWe hebben in de voorgaande voorbeelden gezien dat de Received:-headers gedetailleerde informatie bevatten over de historiek van een boodschap, en ons aldus in staat kunnen stellen om sommige conclusies te trekken over de oorsprong ervan, zelfs al werden er andere headers vervalst. In dit gedeelte verkennen we een aantal details die te maken hebben met deze belangrijke headers, en in het bijzonder hoe we kunnen afrekenen met een aantal bekende vervalsingstechnieken. Het eerste waardevolle element uit de Received:-headers bevindt zich op de plaats waar de ontvanger de gegevens van de verzender bewaart. We zagen reeds eerder dat de verzender kan liegen over zijn ware identiteit door valse informatie op te geven in zijn HELO-commando aan de ontvanger. Moderne mailprogramma's kunnen dergelijke foute informatie echter detecteren en corrigeren. Als de machine turmeric.com (IP 104.128.23.115) bijvoorbeeld een boodschap verzendt naar mail.bieberdorf.edu, maar daarbij beweert HELO galangal.org te zijn, dan zou de Received:-regel er als volgt uitzien:
(De rest van deze regel is weggelaten voor de duidelijkheid). Alhoewel bieberdorf.edu niet expliciet vermeldt dat galangal.org niet de echte verzender is, bewaart deze toch het correcte IP-adres van de eigenlijke verzender. Als de persoon die de email uiteindelijk leest denkt dat galangal.org niet de originele verzender was, dan kan hij altijd het IP-adres 104.128.23.115 opzoeken, bijvoorbeeld met een programma zoals nslookup op UNIX. Op deze wijze kan hij dan achterhalen dat het IP-adres 104.128.23.115 eigenlijk toebehoort aan turmeric.com en niet aan galangal.org. Met andere woorden, het bewaren van het IP-adres van de originele verzender bevat genoeg informatie om een mogelijk verdachte oorsprong van een email te kunnen bevestigen. Veel moderne emailprogramma's automatiseren dit proces door de naam op te zoeken van de machine die de verzending doet. (Dit opzoekingsproces noemt omgekeerde DNS (afkorting van Domain Name Service), "omgekeerd" omdat het normale proces van het vertalen van een naam naar IP-adres wordt omgekeerd). Stel dat mail.bieberdorf.edu dergelijke omgekeerde DNS zou gebruiken, dan zou de Received:-regel er ongeveer als volgt uitzien:
In dit geval is het overduidelijk dat deze informatie vervalst is. Deze regel beweert namelijk "turmeric.com heeft IP-adres 104.128.23.115 en identificeerde zichzelf met de naam galangal.org". Dergelijke informatie is uiteraard zeer nuttig om spam te identificeren en de oorsprong ervan te achterhalen. Net om deze reden proberen spammers machines te vermijden die deze omgekeerde DNS informatie rapporteren. Soms kunnen spammers zelfs machines vinden die zelfs geen IP-logs vermelden zoals beschreven in de vorige paragraaf. Gelukkig zijn er tegenwoordig bijna geen dergelijke machines meer op het Internet. Een andere techniek die gebruikt wordt door spammers, is het toevoegen van onbestaande Received: -headers vooraleer de spam uit te zenden. Dit betekent dat een email verzonden vanaf turmeric.com bijvoorbeeld de volgende headers zou kunnen hebben:
Natuurlijk zijn de twee laatste lijnen zonder betekenis; ze werden toegevoegd aan de email door de spammer. Omdat de verzender geen controle meer heeft over zijn boodschap vanaf dat het turmeric.com verlaten heeft, en omdat de Received:-headers altijd bovenaan worden toegevoegd, zullen de vervalste Received:-headers altijd onderaan verschijnen. Als iemand de historiek van een boodschap wil nagaan, kan hij dus zonder probleem alles ná de eerste valse Received:-header negeren. Zelfs al zouden deze headers er op het eerste zicht normaal uitzien, is het 100% zeker dat dit vervalsingen zijn. Soms zal een spammer geen duidelijke aanwijzingen geven welke headers echt en vals zijn; volgende headers zouden bijvoorbeeld kunnen voorkomen:
De enige"verdachte regel lijkt hier het onjuiste IP-adres van galangal.org. Deze constructie zou nog moeilijker te begrijpen zijn indien de spammer ook foute IP-adressen zou hebben opgegeven voor lemongrass.org en graprao.com, maar desondanks zou toch steeds te achterhalen zijn dat de email vervalst werd op de computer met IP-adres 104.128.23.115 (dus, turmeric.com), omdat dit de eerste vervalsing is. Nochtans zijn de meeste headervervalsingen minder complex, en meestal zijn extra Received:-regels duidelijk te onderscheiden van de rest. Lijst met gebruikelijke headers
|
.