Een e-mailbericht bestaat doorgaans uit twee delen:
koptekst(header), met service-informatie die de bezorging en verwerking van het bericht regelt;
lichaam(body), dat rechtstreeks het gebruikersbericht bevat: tekst en bijgevoegde gegevens (afbeeldingen, geluidsbestanden, enz.).
Titel van bericht
Het e-mailbericht is platte tekst in ASCII-indeling. Daarom bestaat de berichtkop uit een reeks tekstregels, zoals:
De mailberichtstandaard voorziet in een groot aantal velden. Sommige daarvan zijn verplicht, d.w.z. Zonder hen is het onmogelijk om de juiste bezorging van berichten uit te voeren, en sommige zijn optioneel. Hieronder vindt u de meest gebruikte velden.
Bericht-ID– unieke bericht-ID. De uniciteit van de waarde van dit veld wordt gegarandeerd door de software van het verzendende knooppunt en wordt dus automatisch gegenereerd.
Datum– Veld “Datum”. Bevat de datum waarop het bericht is verzonden. De veldwaarde wordt automatisch ingesteld door de e-mailclient bij het verzenden van een bericht.
Van– Veld “Van”. Bevat het adres dat de afzender van het bericht opgeeft als het oorspronkelijke adres.
Afzender– Veld “Afzender”. Bevat het adres vanwaar het bericht daadwerkelijk is verzonden. Dit veld staat mogelijk niet in de koptekst als het Van-veld het adres van de daadwerkelijke afzender bevat.
Naar– Veld “Aan”. Bevat het adres van de primaire ontvanger van het bericht.
CC– Veld “Kopiëren”. Bevat de adressen van extra berichtontvangers.
Bcc– Veld “Blinde carbonkopie”. Bevat de adressen van extra berichtontvangers. Ontvangers die in de velden "Aan" en "Cc" staan, weten niet dat de ontvangers in de lijst "Bcc" een kopie van het bericht hebben ontvangen.
Beantwoorden– Veld “Beantwoorden”. Bevat het adres waarnaar de ontvanger een antwoord moet sturen. Dit veld is optioneel: als het ontbreekt, worden de antwoorden verzonden naar het adres dat is opgegeven in het veld 'Van'.
Onderwerp– Veld “Berichtonderwerp”. Dit veld bevat meestal een korte beschrijving (onderwerp) van het bericht.
Berichttekst
Oorspronkelijk was het de bedoeling dat e-mailberichten alleen ASCII-tekst konden bevatten. En omdat niet de mogelijkheid werd geboden om niet-tekstuele informatie te verzenden, verwerken e-mailtransmissieprotocollen dergelijke berichten mogelijk niet correct. In dit opzicht is er ooit een speciale standaard ontwikkeld die de principes definieerde voor het converteren van niet-tekstuele gegevens naar tekstvorm. Deze standaard heet MIME(Multifunctionele internetmailextensie, multifunctionele internetmailextensie).
MIME gaat ervan uit dat de volgende soorten informatie in de hoofdtekst van een bericht kunnen worden opgenomen:
tekst – platte tekst in ASCII-formaat, evenals tekst in RTF- of HTML-formaat;
grafische afbeeldingen – bestanden in JPEG- en GIF-formaat;
audio- en videogegevens;
gegevens in de formaten van verschillende toepassingen, bijvoorbeeld Microsoft Office-documenten, evenals gegevens in elk formaat (inclusief verschillende uitvoerbare bestanden).
Eén e-mailbericht kan verschillende soorten gegevens bevatten. Dergelijke berichten bestaan uit een structuur met een algemene header en verschillende blokken binnen de hoofdtekst, die elk informatie van hun eigen type bevatten.
Dit wordt veel gebruikt bij het verzenden van berichten met investeringen(bijlagen) – extra “bijgevoegde” bestanden die verschillende informatie kunnen bevatten. U kunt bijvoorbeeld een grafisch bestand met een foto van de afzender aan een sms-bericht toevoegen.
Bovendien kan dit handig zijn als de berichttekst in verschillende formaten moet worden verzonden. Een verzonden bericht in HTML-formaat dat een bepaald ontwerp bevat, wordt bijvoorbeeld mogelijk niet correct waargenomen door het clientprogramma van de ontvanger. Om dergelijke problemen te voorkomen, kan de e-mailclient van de afzender een alternatieve weergave van het bericht in platte tekst genereren.
Om een correcte overdracht van berichten met niet-tekstgegevens in MIME te garanderen, zijn er twee transcoderingsalgoritmen beschikbaar die dergelijke gegevens naar een testvorm converteren:
het "Quoted-printable" -algoritme, ontworpen om bytes die geen ASCII-tekens zijn, te vervangen door een groep van drie bytes die alleen standaardtekens vertegenwoordigen;
het "Base64" -algoritme, dat drie willekeurige bytes omzet in vier ASCII-tekens.
Om een correcte interpretatie van gegevens volgens de MIME-standaard te garanderen, worden extra speciale velden in de berichtkop geïntroduceerd.
Inhoudstype– Veld “Inhoudstype”. Verantwoordelijk voor het correct bepalen van het type gegevens in de berichtkop. De veldwaarde geeft een specifiek gegevenstype aan, of geeft aan dat de hoofdtekst verschillende typen blokken bevat.
Content-overdracht-codering– veld "Type inhoudcodering". Definieert de methode voor het converteren (hercoderen) van brongegevens naar tekstvorm.
Volgens de standaarden voor e-mailberichten ondersteunen e-mails bepaalde kopteksten, die elk op een nieuwe regel moeten staan. Standaard bevat de mailer al de benodigde: MIME-versie, inhoudstype, van, antwoord aan, onderwerp, aan. Nieuwe vermeldingen opgenomen in het titelveld RFC-e-mail, zal worden toegevoegd aan de hierboven genoemde bestaande.
Houd er rekening mee dat alle postagenten deze normen anders waarnemen. Ten minste en worden aangegeven in officiële protocollen, kunnen ze worden genegeerd of verkeerd geïnterpreteerd, dus moeten ze worden getest voordat e-mails worden verzonden.
Populaire RFC-briefkoppen
* - betekent bijvoorbeeld. Cc: (Carbonkopie) * Cc: [e-mailadres beveiligd]Deze koptekst is een uitbreiding van het veld 'Aan:' en specificeert extra ontvangers van het bericht. Er is eigenlijk geen verschil tussen "Aan:" en "Cc:", behalve dat sommige e-mailprogramma's ze anders behandelen bij het genereren van een antwoord op een bericht.Bcc: (Blinde carbonkopie) * Bcc: [e-mailadres beveiligd]
Als u deze header in een ontvangen bericht ziet, is er iets mis. Deze header wordt op dezelfde manier gebruikt als "Cc:" (zie hieronder), maar verschijnt niet in de headerlijst. Het belangrijkste idee achter deze header is om kopieën van een e-mail te kunnen sturen naar mensen die geen antwoorden willen ontvangen of in de krantenkoppen willen verschijnen. Blinde kopieën zijn erg populair onder spammers, omdat veel onervaren gebruikers in de war raken als ze een e-mail ontvangen die niet aan hen gericht lijkt te zijn.Lijst-afmelden: * Lijst-afmelden:
Volgens de beschreven functionaliteit zou het veld de gebruiker automatisch moeten afmelden als hij op de knop “SPAM” heeft geklikt, maar vaak wordt onder dit veld een aparte knop “Abonnement opzeggen” weergegeven. De header wordt niet door alle e-mailprogramma's waargenomen, omdat... Dit is een geweldige kans om e-mailadressen te controleren op gebruik.Prioriteit: (X-MSMail-Prioriteit: Belang:)* Prioriteit: 1
Een header die de prioriteit van het bericht specificeert. Soms gespecificeerd als X-Priority:, X-MSMail-Priority:, Importance:, neemt de waarden "Higt", "Normal", "Urgent", "Non-urgent" of voor X-Priority "1", " 3", "5". De meeste programma's negeren het. Vaak gebruikt door spammers om de aandacht op een bericht te vestigen door 1 in te stellen.Opmerkingen: * Opmerkingen: ik hou van boeken
Deze header is niet standaard en kan alle informatie bevatten. Dergelijke headers worden door sommige e-mailprogramma's toegevoegd (met name het populaire Pegasus-programma) om de afzender te identificeren, maar ze worden vaak handmatig toegevoegd door spammers en moeten dus met voorzichtigheid worden behandeld.Organisatie: * Organisatie: OJSC Kostoprav
Een geheel vrije header, meestal met daarin de naam van de organisatie via welke de afzender van het bericht toegang krijgt tot het netwerk. Meestal beheert de afzender deze titel, dus het zou heel goed zoiets kunnen zijn als 'The Royal Society of Putting One Over Another'.Voorrang: * Voorrang: bulk
Waarden: "bulk", "junk", "lijst". Geeft aan of de brief tot een massamailing behoort. Synoniemen X-List:*, X-Mirror:*, X-Auto:*, X-Mailing-List:*.Lijst-eigenaar: *Lijst-eigenaar:
E-mailadres van de organisator van massamailing.X-Mailer: * X-Mailer: ePochta Mailer Dispositie-Melding-Aan: * Beschikkingskennisgeving aan: [e-mailadres beveiligd]
Er wordt een leesbevestiging verzonden naar de opgegeven gegevens. Vaak genegeerd door mailers om spam te bestrijden. Synoniemen: X-Confirm-Reading-To:, Return-Receipt-To:X-*** * X-Lijst:, X-Mailer:, X-...
Zoals de RFC-standaarden zeggen, zijn headers die beginnen met X de eigen headers van individuele e-mailprogramma's die informatief van aard zijn. Maar sommige zijn algemeen aanvaard, zoals X-Mailer. Niets dan aanvullende informatie in de e-mailcode...
De hierboven verstrekte informatie is uitsluitend voor informatieve doeleinden. Dit betekent niet dat het opgeven van een header noodzakelijkerwijs door elk mailprogramma zal worden uitgevoerd. Meer informatie over headers vindt u op
In het meest algemene geval ziet het schema voor het uitwisselen van elektronische berichten (elektronische post, e-mail) er als volgt uit:
Zoals u kunt zien, worden bij het uitwisselen van elektronische berichten niet alleen technische en softwaretools van de afzender en ontvanger gebruikt, maar ook post- servers wiens taak het is om brieven te ontvangen die bedoeld zijn om door de afzender te worden verzonden, en deze af te leveren postbus ontvanger, tijdelijke opslag en overdracht van de mailbox naar de ontvanger.
Als een van de elementen van e-mail is een mailbox een gewone bestandssysteemmap (map), en e-mails zijn gegevensbestanden die zich in deze map bevinden. Uiteraard is alle technologie voor het ontvangen en verzenden van e-mails onderworpen aan bepaalde regels die zijn vastgelegd in protocollen en dataformaten. Aan de clientzijde (afzender en ontvanger) wordt speciale software gebruikt: een e-mailclient, die bijvoorbeeld Microsoft Outlook voor Windows of Mozilla Thunderbird voor Linux kan worden gebruikt. Zelfs als u met uw mailbox werkt via een webinterface (door verbinding te maken met een site, bijvoorbeeld mail.ru), gebruikt u nog steeds e-mailclientsoftware die in een serveromgeving draait. Mailservers en mailclients implementeren, ongeacht op welke hardware en software ze werken, minstens twee applicatieprotocollen, zonder welke mailuitwisseling onmogelijk is. Een daarvan wordt gebruikt voor het verzenden van e-mails - dit is het protocol SMTP(Simple Mail Transfer Protocol, eenvoudig mailoverdrachtprotocol), de tweede wordt gebruikt om te ontvangen POP3(Postkantoorprotocol versie 3, postkantoorprotocol). Beide protocollen op applicatieniveau worden geïmplementeerd in de vorm van de uitwisseling van tekstberichten in ASCII-codering, d.w.z. zijn telnet-achtige protocollen. Historisch gezien is dit al het geval sinds de eerste pogingen tot elektronisch berichtenverkeer in de jaren zestig. Dienovereenkomstig kunnen de e-mails zelf geen servicetekens (niet-weergeefbare) bevatten. Zelfs een binair bestand dat bij een e-mail is gevoegd, wordt vóór verzending omgezet in een reeks standaard weergavetekens en bij ontvangst opnieuw gecodeerd naar de oorspronkelijke vorm. Zowel het gegevensuitwisselingsproces als de structuur van e-mails zijn onderworpen aan strikt gedefinieerde regels, die hieronder worden besproken.
De afzender van het e-mailbericht maakt verbinding met zijn mailserver via een applicatielaagprotocol SMTP en hem de gegevens doorgeeft die nodig zijn om de zending bij de eindontvanger te bezorgen, en in feite het bericht zelf. Daarna eindigt de uitwisselingssessie. In de volgende fase van de e-mailbezorging (Mail Delivery-proces) vindt de mailserver van de afzender, met behulp van de e-mailadresgegevens van de ontvanger, zijn mailserver, maakt er op dezelfde manier verbinding mee en verzendt de brief, die in de mailbox van de ontvanger wordt geplaatst. Adresstructuur in het formulier [e-mailadres beveiligd] definiëren:
gebruiker- gebruikersnaam, wat tevens de naam is van de map die als mailbox wordt gebruikt.
domein.ru- domeinnaam "domain.ru", die de mailserver bepaalt waarop deze mailbox zich bevindt. De DNS-naamomzettingsservice wordt gebruikt om te bepalen welke mailservers specifieke domeinen bedienen.
[e-mailadres beveiligd]– mailbox van de gebruiker “test” in het mail.ru-domein
Dienovereenkomstig, wanneer de afzender het eerste deel van het adres onjuist opgeeft of als er geen dergelijke mailbox bestaat, kan de brief niet worden afgeleverd en wordt er een bericht over dit feit naar de afzender verzonden met de tekst "Mailbox bestaat niet" (de mailbox bestaat niet ):
SMTP-fout van externe mailserver na RCPT TO::
^nbsp host mx01.mail.ru: 550 Postbus [e-mailadres beveiligd] bestaat niet.
Foutmeldingen bij e-mailbezorging worden doorgaans verzonden met het onderwerp:
E-mailbezorging mislukt: bericht teruggestuurd naar afzender
In het geval dat het gedeelte van het adres na het bord onjuist is aangegeven @ , dan gaat de foutmelding vergezeld van de tekst dat het domein niet gevonden is (Domein... niet gevonden). Afhankelijk van het type servers en hun instellingen kan de tekst van foutmeldingen bij aflevering enigszins variëren.
Als er geen fouten optreden, kan de ontvanger alleen verbinding maken met de server via zijn e-mailclient en via het applicatielaagprotocol POP3“haal” een bericht op dat zich daar uit de mailbox bevindt.
Het SMTP-protocol is begin jaren 80 van de vorige eeuw ontwikkeld (de belangrijkste specificaties zijn RFC 821 RFC 822), maar wordt, met enkele wijzigingen en toevoegingen, nog steeds veel gebruikt en zal uiteraard in de komende jaren worden gebruikt als het belangrijkste transmissieprotocol voor elektronische berichten. Voor het laatst bijgewerkt in 2008, heeft RFC 5321 een schaalbare protocoluitbreiding toegevoegd - ESMTP(Uitgebreide SMTP). In de dagelijkse terminologie wordt de naam echter nog steeds gebruikt SMTP
Bij de standaardopstelling luistert de mailserver naar inkomende verbindingen op TCP-poort 25 (luistert op TCP-poort 25). Het clientmailprogramma maakt verbinding met deze poort, waarna de mailserver zijn begroeting verzendt, bijvoorbeeld:
220 fcgp03.nicmail.ru ESMTP CommuniGate Pro 5.2.3.
Informatie- en controleberichten uitgegeven door de server bestaan uit een nummer (numerieke identificatie), in dit geval - 220 (de server is klaar voor gebruik) en verklarende tekst. De door de client verzonden gegevens hebben geen nummer en worden verzonden als een set weergavetekens (platte tekst).
Om een sessie te starten, moet de client, volgens de SMTP-protocolspecificatie, zijn lokale hostnaam opgeven met behulp van de HELO-richtlijn. In plaats van HELO kan de richtlijn worden gebruikt (en wordt gebruikt in de meeste e-mailprogramma's) EHLO, als reactie hierop verzendt de server een lijst met SMTP-protocolopdrachten die hij ondersteunt
EHLO MijnComp.Mijndomein
De computernaam wordt als argument doorgegeven aan de EHLO-richtlijn.
Het serverantwoord (ID 250 - OK, succesvol) vermeldt de SMTP-protocolopdrachten die het ondersteunt:
De domeinnaam 250-fcgp03.nicmail.ru moet de kwalificatie MyComp.Mydomain hebben
250-MAAT 31457280
250-AUTH AANMELDEN PLAIN CRAM-MD5 DIGEST-MD5 MSN
250-ETRN
250-BEURT
250-ATRNA
250-8BITMIME
250-HULP
250 EHLO
De lijst met SMTP-opdrachten is afhankelijk van het type en de specifieke serverinstellingen. Vanwege het SPAM-probleem is de overgrote meerderheid van de mailservers alleen geconfigureerd om te werken met toestemming om verbinding te maken vanaf eerder bekende IP-adressen of met toestemming van de gebruiker. Daarom geeft het mailclientprogramma een AUTH-instructie uit die aangeeft welke het zal gebruiken:
AUTH INLOGGEN
In dit geval wordt gebruikersauthenticatie met gebruikersnaam en wachtwoord gebruikt. Hierna geeft de server een bericht met nummer 334 (authenticatieprocedure in uitvoering):
334 VXNlcm5hbWU6
In het beschouwde voorbeeld van een SMTP-sessie wordt in dit stadium de gegevensuitwisseling tussen de client en de server ook in tekstvorm uitgevoerd, maar in codering Basis64. Deze codering wordt veel gebruikt in e-mailtoepassingen voor het coderen van binaire gegevens - programma's, foto's, video's, enz. Het gehele bereik van gecodeerde data-elementen kan worden weergegeven door een reeks Engelse alfabettekens, cijfers en enkele symbolen. Om gegevens te transcoderen, is de eenvoudigste manier om de online transcoder base64.ru te gebruiken. Om te converteren kopieert u de Base64-reeks naar het bovenste venster en onderaan krijgen we de tekst Gebruikersnaam:
De tekenreeks VXNlcm5hbWU6 is Gebruikersnaam: in ASCII-codering, d.w.z. gebruikersnaam verzoek. Het clientprogramma verzendt het ook in Base64-codering:
QmlsbEdhdGVzQG1pY3Jvc29mdC5jb20=
Op dezelfde manier wordt bepaald dat de lijn
334UGFzc3dvcmQ6
Betekent wachtwoordverzoek - Wachtwoord:
Waarheen het clientprogramma het wachtwoord stuurt, ook in Base64-codering:
YXNkYXRh
Als het wachtwoord wordt geaccepteerd, antwoordt de server met berichtnummer 235:
235 [e-mailadres beveiligd] geauthenticeerd
Als de gebruikersnaam of het wachtwoord niet wordt herkend, reageert de server met een foutcode uit een reeks berichten met cijfers 4ХХ, 5ХХ
MAIL VAN: [e-mailadres beveiligd]
Een van de ernstige nadelen van het SMTP-protocol is de zwakke bescherming tegen manipulatie van e-mail. Volgens richtlijn HELOO u kunt elk hostadres opgeven, of in de richtlijn MAIL VAN U kunt elk afzenderadres opgeven, bijvoorbeeld
Lettertypekleur = "blauw">MAIL VAN: [e-mailadres beveiligd]
Als het postadres overeenkomt met het formaat gebruiker@domein, geeft de server een bericht met nummer 250 (OK, alles is in orde):
250 [e-mailadres beveiligd] afzender geaccepteerd
(En het client-mailprogramma van de ontvanger zal precies dit adres weergeven in de ontvangen brief, dat wil zeggen van Bill Gates van het microsoft.com-domein)
Na bevestiging van de server te hebben ontvangen dat het adres is geaccepteerd, verzendt het clientprogramma het adres van de ontvanger met behulp van de richtlijn RCPT AAN:
RCPT AAN: [e-mailadres beveiligd]
Als het adres van de ontvanger overeenkomt met het formaat gebruiker@domein, zal de server reageren met een bericht dat aangeeft dat hij klaar is om het e-mailbericht te accepteren voor bezorging 250:
250 [e-mailadres beveiligd] stuurt e-mail door voor een geverifieerde gebruiker
GEGEVENS
Waarop de server reageert met een bericht met nummer 354 (“begin met het invoeren van de tekst van de brief”)
354 Voer e-mailadres in, eindig met "." op een lijn zelf
In het eenvoudigste geval kan een letter een reeks ASCII-tekens zijn die bijvoorbeeld via het toetsenbord worden ingevoerd en weergegeven
Hallo, Wereld!!!
Het einde van een bericht wordt aangegeven door een aparte regel met daarin het puntteken.
Waarop de server een bericht afgeeft waarin wordt aangegeven dat het ingevoerde bericht is geaccepteerd voor bezorging:
250 bericht geaccepteerd voor bezorging
Waarna het mailclientprogramma de sessie beëindigt:
Als reactie meldt de mailserver dat de verbinding is verbroken:
221 fcgp03.nicmail.ru CommuniGate Pro SMTP sluit verbinding
In de beginfase van het gebruik van het SMTP-protocol, toen alleen eenvoudige tekst werd verzonden, werd deze methode voor het verzenden van brieven gebruikt, maar na verloop van tijd ontstond de behoefte om een mooi ontwerp voor berichten te maken, bestanden van willekeurig formaat bij te voegen en nationale alfabetten te gebruiken enz. Dus naast het document RFC821 document werd ontwikkeld RFC822, dat de basisinhoud van e-mailberichten en documenten standaardiseert RFC2045 En RFC2046, waarin het formaat van extensies wordt beschreven MIME(Multipurpose Internet Mail Extensions - multifunctionele e-mailextensie), ontworpen voor het verwerken van samengestelde en niet-standaard berichten.
E-mailformaat.
Volgens moderne normen bestaat een e-mailbericht uit 2 delen: koptekst En lichaam. De kop van de brief wordt gegenereerd door de mailsoftware en bestaat uit meerdere regels in ASCII-codering. De header bevat dienstinformatie die nodig is voor de bezorging en verwerking van een elektronisch bericht. Elk koptekstveld bestaat uit een titel, een dubbele punt en de veldgegevens. Sommige headervelden hebben een vaste structuur, b.v. Van:(adres van de afzender), en sommige - willekeurig, zoals het veld Onderwerp:(onderwerp van de brief).
Belangrijkste berichtvelden:
Van:- adres van de afzender
Naar:- adres van de ontvanger
Datum:- datum van verzending
CC:- een kopie van het bericht wordt naar het opgegeven adres verzonden
v.Chr- verborgen kopie
Onderwerp:- berichtonderwerp
Bericht-ID:- berichtidentificatie toegewezen door de mailsoftware.
Antwoord aan:- adres voor het beantwoorden van het bericht.
Prioriteit- Prioriteit (belang) van het bericht
X-mailer:- het mailprogramma waarmee het bericht is verzonden.
Ontvangen:- een veld met adressen en verwerkingstijd van het bericht door tussenliggende servers bij het afleveren van het bericht bij de ontvanger.
De minimale berichtkop moet velden bevatten Van:, Naar:(of CC:) En Datum:. Wanneer een bericht wordt afgeleverd bij de eindontvanger, kunnen velden die zijn gegenereerd door tussenliggende mailservers worden toegevoegd aan de initiële berichtkop. Dus bijvoorbeeld bij het versturen van een bericht van een gebruiker [e-mailadres beveiligd] gebruiker [e-mailadres beveiligd], wordt de brief door de client-mailsoftware naar de mailserver gestuurd die het mail.ru-domein bedient, en vervolgens doorgestuurd naar de mailserver die het rambler.ru-domein bedient, vanwaar hij door de mailboxgebruiker zal worden ontvangen [e-mailadres beveiligd]. Het doorsturen kan uit meerdere stappen bestaan en gaat gepaard met het toevoegen van tussenliggende servervelden aan de berichtkop.
De volgende velden geven het formaat van de briefinhoud aan:
MIME-versie:- MIME-extensieversie. Geeft aan dat dit bericht een MIME-extensie gebruikt en geeft de versie ervan aan.
Inhoudstype:- inhoudstype. Definieert de inhoud van het bericht en het algoritme voor de verwerking ervan door mailsoftware (mailsoftware). Dus bijvoorbeeld
Inhoudstype: bericht/RFC-822- geeft aan dat wat volgt een bericht is in RFC-822-formaat, d.w.z. een eenvoudig sms-bericht zonder enige extensie in ASCII-codering.
Inhoudstype: tekst/gewoon; tekenset = "windows-1251"- een bericht uit een reeks tekens in de codering die wordt bepaald door de parameterwaarde tekenset:(in dit geval in Windows-codering met codetabel 1251)
Inhoudstype: tekst/html- Er wordt gebruik gemaakt van tekst die is opgemaakt met HTML-taaltags.
Inhoudstype: meerdelig/gemengd;
grens = "----=_NextPart_000_008D_01CC0FEF.CCB47280"- het bericht bestaat uit verschillende delen met verschillende inhoud. Parameter grens specificeert een string als scheidingsteken tussen afzonderlijke onderdelen.
Het veld dus Inhoudstype: kan bepalen welk type inhoud (audio, video, afbeelding) moet worden getranscodeerd bij het verwerken van een e-mailbericht. Het coderingstype wordt aangegeven door het veld Content-overdracht-codering:. Als typen zijn opgegeven 7bit, 8 bit of binair, dan wordt hercodering niet gebruikt. Type Basis64 geeft aan dat de gegevens zijn gecodeerd met de hierboven genoemde Base64-codering. Een vrij algemeen type geciteerd-afdrukbaar, ontworpen, net als Base64, om tekens te verzenden die geen deel uitmaken van het weergegeven deel van ASCII (het Engelse alfabet, cijfers en enkele tekens). Elk teken wordt omgezet in een reeks gelijktekens = en twee tekens die de hexadecimale codewaarde specificeren van het teken dat wordt geconverteerd. Dus bijvoorbeeld de Russische hoofdletter I, wat overeenkomt met de hexadecimale waarde 0xDF in het hoge deel van de symbolentabel, wordt weergegeven als =DF, uitroepteken - =21 enz. Regels voor het coderen van gegevens worden beschreven in het document RFC-1341
Hoe een valse e-mail te herkennen.
Er is waarschijnlijk geen enkele e-mailgebruiker die geen e-mails ontvangt van verschillende soorten oplichters die zich voordoen als organisatoren van verschillende (win-win) loterijen, websitebeheer, elektronische betalingssysteemdiensten, enz. Veel gebruikerspagina's van sociale netwerken, e-mailgebruikersaccounts, e-wallets, enz. werden gehackt met behulp van valse e-mails. Maar het gebeurt andersom: geldige brieven die ongegronde vermoedens wekten, werden genegeerd en naar de prullenbak gestuurd. Maar de authenticiteit van een e-mailbericht is vrij eenvoudig vast te stellen met behulp van gewone logica en de informatie die uit de koptekstvelden van de brief kan worden gehaald.
De ontvangen brief wordt door de e-mailclientsoftware weergegeven in een vorm die gemakkelijk te bekijken is zonder onnodige details. Indien nodig kunt u echter de presentatie van de berichtgegevens wijzigen en de koptekstvelden bekijken. Voor de e-mailclient van Microsoft Outlook Express (evenals de e-mailclient van Windows Mail en andere) moet u bijvoorbeeld een specifieke letter selecteren, het contextmenu oproepen met de rechtermuisknop en selecteren Eigenschappen of druk op de toetsencombinatie Alt+BINNENKOMEN. Het venster met berichteigenschappen wordt geopend met de tabbladen “Algemeen” en “Details” (bij sommige clients - “Algemeen” en “Details”)
Wanneer u de weergavemodus "Details" selecteert, worden de kopteksten van het bericht weergegeven in het venster met berichteigenschappen en bovendien kunt u het bekijken in de vorm waarin het is ontvangen van de mailserver wanneer u op klikt de knop Origineel bericht
De eerste weergave is een berichtkop, een lege regel en een berichttekst.
In andere mailprogramma's of in de webinterface van maildiensten is het ook mogelijk om de header te bekijken, bij het lezen van een brief via de webinterface van de mail.ru mailservice kan de header bijvoorbeeld worden bekeken door op de knop te klikken pictogram met de inscriptie RFC, gelegen in de rij knoppen boven de letter. In de Yandex mail-webinterface moet u op het pictogram in de rechterbovenhoek van het scherm klikken Letter eigenschappen. De knopnamen kunnen variëren, maar er is bijna altijd een optie om de koptekst of de volledige originele weergave van de e-mail te bekijken.
Om de koptekst van een e-mail in de e-mailclient van Microsoft Outlook 2010 te bekijken, dubbelklikt u op de e-mail en selecteert u de knop "Bestand" - "Informatie" - "Eigenschappen" in het menu. Koptekstvelden verschijnen in het venster Internetkopteksten
Beschouw bijvoorbeeld de kopteksten van een brief met “Microsoft Corporation” als afzender en met het onderwerp “Je hebt gewonnen (bijlage bekijken)”, waarin werd gerapporteerd over een grote overwinning in een elektronische loterij en werd aangeboden een formulier in te vullen. formulier in het bijgevoegde bestand om het te ontvangen. Het lijkt erop dat we het hebben over het winnen van een loterij van Microsoft Corporation. Eigenlijk is de inhoud duidelijk verdacht, maar in dit geval doet dat er niet toe. Het doel is om maximale betrouwbare informatie te verkrijgen over de afzender van een bepaalde e-mail.
Tijdens de bezorging van een e-mail, wanneer deze van knooppunt naar knooppunt wordt verzonden, voegt software langs de route service-informatie toe aan de header, en de afzender heeft op geen enkele manier de mogelijkheid om deze gegevens te wijzigen. De vroegste kopvelden qua vormingstijd bevinden zich in het onderste gedeelte, de latere in het bovenste gedeelte. Velden die beginnen met tekens X-, verwijst meestal naar de software die wordt gebruikt om een e-mail te verzenden, deze te controleren op spam, virussen, enz. Deze velden bevatten geen bijzonder nuttige informatie om de betrouwbaarheid van de afzender van het bericht te bepalen, hoewel ze wel als aanvullende informatiebron kunnen worden gebruikt. De afzender blijkt bijvoorbeeld Microsoft Corporation te zijn, maar voor het verzenden wordt de webmail van de Yahoo-zoekmachine gebruikt, wat uiteraard niet het geval kan zijn.
X-Mailer: YahooMailRC/420.4 YahooMailWebService/0.8.105.279950
De velden Van:, Aan: en Antwoord-aan: geven ook aan dat het bericht nep is.
Van: Microsoft Corporation
De weergavenaam van de afzender is "Microsoft Corporation" en het postadres is " [e-mailadres beveiligd]"(Ik heb de adressen gewijzigd die daadwerkelijk in het bericht aanwezig zijn, waarbij de structuur behouden blijft). E-mailadressen gebruiken het formaat
gebruiker@domein- Naam gebruiker teken @ Naam domein. De gebruikersnaam (mailboxnaam) is in dit geval microsoft491, en de domeinnaam is gmail.com, d.w.z. is een gratis mailbox op het Google-domein. Is het niet vreemd als een grote organisatie openbare gratis post gebruikt voor officiële correspondentie? U kunt elke gebruikersnaam aanmaken, zolang deze gratis is en voldoet aan de regels van de e-mailservice, en de weergegeven naam geen verband houdt met het echte postadres. Heel vaak gebruiken oplichters het e-mailadresformaat als de weergavenaam van de afzender, en in plaats van 'Microsoft Corporation' kan er bijvoorbeeld ' [e-mailadres beveiligd]"wat overeenkomt met het echte adres" [e-mailadres beveiligd]", wat duidelijk niets te maken heeft met Microsoft Corporation.
Of het domein van het adres van de afzender iets te maken heeft met Microsoft of een andere organisatie, kunt u controleren met speciale software, zoals een gratis hulpprogramma, of met behulp van online Whois-services (bijvoorbeeld op de website 2ip.ru), waarmee u om echte informatie over de domeinnaam te krijgen.
Domeininformatie biedt vaak aanvullende aanwijzingen die kunnen helpen bij het vaststellen van de authenticiteit van een e-mail. Dit geldt met name in gevallen waarin een adres wordt gebruikt met een domeinnaam die zeer dicht bij de naam van officiële organisaties ligt. Onlangs ging er een frauduleuze mailing via het Russische deel van het internet namens zogenaamd Roskomnadzor, roskomnadzor.org. In dergelijke gevallen is het de moeite waard om op de ouderdom van het domein te letten. Domeinnamen die voor internetoplichting worden gebruikt, zijn doorgaans tussen een paar dagen en een paar weken oud. Daarnaast kunnen informatie over de registrar, gegevens van technische en administratieve contacten informatie opleveren op basis waarvan conclusies kunnen worden getrokken over de betrouwbaarheid van de afzender. In werkelijkheid blijkt meestal dat de domeinnaamregistreerder van een overheidsinstantie een privépersoon is en dat de opgegeven contacten niets met deze organisatie of zelfs met dit land te maken hebben.
Volgende veld om op te letten
Bericht-ID: 306099.58326.qm @ web83802.mail.sp1.yahoo.com
Dit is een interne berichtidentificatie die wordt toegewezen door het mailsysteem waarvan de naam na het symbool verschijnt @ . Als u een brief heeft ontvangen die lijkt op een brief van Microsoft of de Yandex-administratie, maar de naam van het e-mailsysteem bevat Yahoo.com, dan kunnen we duidelijk concluderen dat zo’n brief nep is. Maar dat is niet alles. Volgende (van onder naar boven) veld, Ontvangen: wordt gegenereerd door de eerste mailserver in de bezorgketen en geeft ons het adres (het adres is door mij gewijzigd) vanwaar de brief is verzonden
Ontvangen: van web83802.mail.sp1.yahoo.com via HTTP;
Met een hoge mate van waarschijnlijkheid kunnen we aannemen dat dit in ieder geval een adres is uit de adrespool van de internetprovider van de afzender of de gateway van het postnetwerk. Ik zal hieraan toevoegen dat in de netwerken van providers in de meeste gevallen aan clients dynamische IP-adressen en zogenaamde “grijze” IP’s worden toegewezen, wanneer toegang tot internet wordt uitgevoerd met behulp van NAT-technologie (Network Address Translation) en het gateway-adres het IP-adres zal zijn. in het veld Ontvangen, waarmee toegang tot internet wordt verkregen vanuit het interne netwerk van de provider. Om informatie over het IP-adres te verkrijgen, kunt u dezelfde Win32Whois gebruiken. In plaats van de domeinnaam voert u deze in het veld in DOMEIN het IP-adres waarin we geïnteresseerd zijn
Analyse van het adres kan bijvoorbeeld informatie opleveren dat een brief zogenaamd van Microsoft is verzonden vanuit het netwerk van een Poolse of Nieuw-Zeelandse provider, en een officiële brief van de Russische Federale Dienst is verzonden vanuit Canada.
Zoals je kunt zien, niets ingewikkelds. Het is voldoende om zelfs maar algemene informatie te hebben over de principes van e-mailuitwisseling en inzicht in briefformaten om een nepbericht te kunnen identificeren en niet in de val van internetoplichters te trappen.
Elke e-mail heeft in principe dezelfde structuur. Het internetmailberichtformaat is gedefinieerd in RFC-822 (standaard voor ARPA internettekstbericht, gepubliceerd in 1982). Een e-mailbericht bestaat uit drie delen: een envelop, headers en een berichttekst. Alleen de koptekst en de hoofdtekst van het bericht zijn beschikbaar voor de gebruiker. De envelop wordt gebruikt door bezorgprogramma's (om berichten van server naar server over te brengen). RFC-822 regelt de inhoud van de berichtkop. De koptekst verschijnt altijd vóór de hoofdtekst van het bericht, wordt ervan gescheiden door een lege regel en bestaat uit velden (naam en inhoud). De veldnaam wordt van de inhoud gescheiden door het symbool teken.De volgende velden zijn minimaal vereist " Datum:«, » Van:«, » CC:" en/of " Naar:", Bijvoorbeeld:
Naar: [e-mailadres beveiligd]
Naar: [e-mailadres beveiligd]
Waar " Datum:«, » Van:«, » CC:" En " Naar:" zijn de headernamen, en elke headernaam wordt gescheiden door een spatie en de bijbehorende inhoud wordt aangegeven. Laten we de betekenis van elke gespecificeerde headernaam bepalen:
Het veld "Datum:" wordt ingesteld door de computer van de afzender, waarop de datum en tijd mogelijk verkeerd zijn ingesteld
Datum:— het doel van deze header is duidelijk: het geeft de datum en het tijdstip aan waarop de brief is verzonden (uit de voorbeelden “Fri, 6 Dec 2002 23:26:50 +0300 (MSK/MSD)” is het duidelijk dat de brief is verzonden op 6 december 2002 om 23:26: 50 Moskouse tijd). Als deze header niet op de computer van de afzender is aangemaakt, wordt deze wellicht toegevoegd door de mailserver of een andere computer waar de brief doorheen gaat. In geen geval mag het als een onveranderlijke waarheid worden opgevat, en het punt is niet eens de mogelijkheid van namaak - er zijn een monsterlijk groot aantal computers in de wereld met onjuiste klokken;Van:— geeft het adres van de afzender aan (in het voorbeeld zien we dat de brief vanaf dat adres is verzonden [e-mailadres beveiligd]);
Naar:— adres(sen) van de ontvanger(s) (de ontvanger in ons voorbeeld is [e-mailadres beveiligd]). Houd er rekening mee dat het veld " Naar:" hoeft niet het adres van de ontvanger te bevatten, maar mag ook de adressen van meerdere ontvangers bevatten;
CC:(Carbon Copy) - adressering van kopieën, deze kop is een uitbreiding van het veld "Aan", het geeft extra ontvangers van de brief aan (de ontvanger "Aan" ziet een lijst met alle "Cc's"). Er is in wezen geen verschil tussen de kopteksten 'Aan' en 'Cc', behalve dat sommige e-mailprogramma's deze anders behandelen bij het genereren van een antwoord op een bericht. In voorbeeld nr. 1 is er geen Cc-veld, dat wil zeggen dat de brief naar één ontvanger is verzonden [e-mailadres beveiligd]. Uit voorbeeld nr. 2 wordt duidelijk dat deze header bij de geadresseerde hoort [e-mailadres beveiligd], aan wie een kopie van de brief is gestuurd (hij ziet het veld Aan niet). Voorbeeld #3 laat zien dat de brief naar de ontvanger van de brief is verzonden [e-mailadres beveiligd], en er werd ook een kopie van de brief naar de brievenbus gestuurd [e-mailadres beveiligd].
Maar dit zijn slechts de meest elementaire koptekstvelden. Normaal gesproken bevat de koptekst aanzienlijk meer velden dan hierboven vermeld. Laten we ze leren kennen...
Veld "Ontvangen:" - stempel van de brief die door de mailserver gaat
Ontvangen:— een “stempel” van de brief die door de mailserver gaat. De headers "Ontvangen:" bieden gedetailleerde informatie over de levensduur van het bericht en voorkomen dat de ontvanger van het bericht voor de gek wordt gehouden over waar het bericht precies vandaan komt. Als bijvoorbeeld de machine turmeric.com, waarvan het IP-adres 104.128.23.115 is, een bericht stuurt naar de machine mail.bieberdorf.edu, maar deze probeert te misleiden door HELO galangal.org te zeggen, zal de header "Received:" be: Ontvangen: van manaraga.org (turmeric.com) via mail.bieberdorf.edu...(rest van de regel weggelaten voor de duidelijkheid). Hier wordt de nep onmiddellijk blootgelegd. Deze regel zegt: "de machine turmeric.com, waarvan het adres 104.128.23.115 is, heet galangal.org." We hebben slechts één voorbeeld bekeken dat duidelijk de noodzaak en het nut van deze briefkop aantoont, vanwege het feit dat het doel van dit artikel niet een gedetailleerde studie van elke kop is, maar alleen om uzelf vertrouwd te maken met de meest voorkomende in het dagelijks leven. leven. Bovendien kan over de header “Ontvangen:” een apart artikel worden geschreven.Bericht-ID:- een unieke letteridentificatie die aan elk bericht wordt toegewezen, meestal door de eerste mailserver die het onderweg tegenkomt, of door een mailclient. Het heeft meestal de vorm " [e-mailadres beveiligd], waarbij “abrakadabra” een reeks willekeurige tekens is, en het tweede deel “domain.ru” de naam is van de machine die de ID heeft toegewezen. Soms, maar zelden, bevat 'abrakadabra' de naam van de afzender. Message-Id wordt door e-mailbezorgprogramma's gebruikt om het herhalen van brieven te voorkomen;
Veld "Bcc" - verborgen kopie
Bcc:(Blind Carbon Copy) - blinde/verborgen kopie (ontvangers zijn zich niet bewust van andere ontvangers in het veld “Bcc”). BCC is erg populair onder spammers, omdat veel onervaren gebruikers in de war raken als ze een e-mail ontvangen die niet aan hen gericht lijkt te zijn;Onderwerp:— onderwerp van de brief (aanwezigheid van Re: betekent antwoord; Fwd: — doorsturen). De poststandaard staat alleen Latijnse tekens (US-ASCII) toe in het veld 'Onderwerp'. Daarom wordt dit niet aanbevolen, ondanks het feit dat veel gebruikers dit veld in het Russisch invullen. De normale situatie is wanneer het onderwerp van een in het Russisch geschreven brief, wanneer deze wordt verzonden, door het mailprogramma van de afzender wordt gehercodeerd in 7-bit base64, wat de taalcodering aangeeft waarin dit onderwerp is geschreven (zoals de Pine- en Pegasus Mail-programma's doen), en het mailprogramma van de ontvanger decodeert het onderwerp van de brief in een leesbare weergave. Dit is echter een kenmerk van de MIME-mailstandaard, die UUPC niet ondersteunt;
Antwoord aan:— adres voor antwoorden. Hoewel deze header veel beschaafde toepassingen heeft, wordt hij ook door spammers gebruikt om aanvallen af te weren. Misschien wil een naïeve spammer antwoorden op zijn brieven verzamelen en de juiste header 'Reply-to:' aangeven, maar de meeste geven daar een niet-bestaand adres aan of het adres van een onschuldig slachtoffer;
In antwoord op:— geeft aan dat het bericht van het type “antwoord op antwoord” is;
Opmerkingen:- betekent commentaar. Deze header is niet standaard en kan daarom alle informatie bevatten. Deze headers worden door sommige e-mailprogramma's toegevoegd (met name het populaire Pegasus-programma) om de afzender te identificeren, maar worden vaak handmatig geschreven door spammers en moeten dus met voorzichtigheid worden gebruikt;
Status:— berichtstatus (nieuw, gelezen);
Blijkbaar-aan:— deze headers zijn niet typisch voor normale berichten; ze zijn meestal een teken van massamailing. De laatste tijd worden massamailings uitgevoerd met behulp van software die slim genoeg is om geen gigantische lijsten met deze rubrieken te produceren;
Organisatie:- een geheel vrije header, meestal met daarin de naam van de organisatie via welke de afzender van het bericht toegang krijgt tot het netwerk. De afzender beheert in de regel deze header, dus er kan heel goed zoiets zijn als ZAO "Horns and Hooves";
Prioriteit:- een uitsluitend vrije header die de prioriteit van het bericht bepaalt. De meeste programma's negeren het. Vaak gebruikt door spammers in de vorm van "Prioriteit: dringend" (of iets dergelijks) om de aandacht op het bericht te vestigen;
Fouten naar:- specificeert het adres waarnaar automatisch gegenereerde foutmeldingen moeten worden verzonden, zoals "geen gebruiker". Dit is een zelden gebruikte header omdat de meeste afzenders doorgaans foutmeldingen willen ontvangen op het uitgaande adres, het standaardadres dat door mailservers wordt gebruikt.
De RFC-822-specificatie is zeer verouderd
De headers die we hierboven hebben besproken, worden gereguleerd door RFC-822, zoals hierboven vermeld. Sinds het gebruik van de RFC-822-standaard zijn er een aantal beperkingen ontdekt die de gebruikersbehoeften aanzienlijk verminderen. In het bijzonder werd de mogelijkheid om niet-tekstuele gegevens te verzenden, zoals audio en afbeeldingen, eenvoudigweg niet vermeld in RFC-822, waarin alleen het tekstberichtformaat wordt beschreven. En zelfs in het geval van een sms-bericht omzeilde de RFC-822-standaard de behoeften van gebruikers met behulp van de uitgebreide tekenset, die typisch is voor Aziatische en de meeste Europese talen. De belangrijkste beperking van RFC-822 zijn de relatief korte tekenreeksen en de 7-bits tekentabel. Om niet-tekstuele gegevens te verzenden, moesten gebruikers de hoofdtekst van hun bericht converteren naar een 7-bits vorm met behulp van UUENCODE, BINHEX en analogen. Het werd duidelijk dat er een nieuwe, aanvullende specificatie nodig was, en deze werd ontwikkeld: MIME - Multipurpose Internet Mail Extension (RFC-1314). We zullen over deze specificatie praten in een apart artikel.
De koptekst van het internet-e-mailbericht biedt een lijst met technische informatie over het bericht, zoals wie het heeft verzonden, gemaakt en welke e-mailservers het heeft gepasseerd op weg naar de software van de ontvanger. In de meeste gevallen hoeft alleen de beheerder de internetkoppen van het bericht te bekijken. Als u een onderwerpregel aan uw e-mailbericht wilt toevoegen, raadpleegt u Een thema, achtergrondkleur of briefhoofdkleur toepassen op uw e-mailberichten.
Kopteksten van internetberichten bekijken
In Outlook voor Office 365, 2016, 2013 of 2010 op pc
Dubbelklik op een e-mailbericht om het buiten het leesvenster te openen.
Selecteer bestand> eigenschappen.
De headerinformatie wordt in het veld weergegeven Internetkoppen.
Advies: informatie in dit veld markeren, toetsen indrukken Ctrl+C om te kopiëren en in Kladblok of Word te plakken om de hele bovenste in één keer te zien.
Inhoud van de kopteksten van e-mailberichten
Laten we eens kijken naar e-mailcorrespondentie tussen twee gebruikers: Sergey Zaitsev en Olga Zueva. Sergey's e-mailadres - [e-mailadres beveiligd], Olga's adres - [e-mailadres beveiligd]. Olga gebruikt Microsoft Office Outlook 2007. De internetkop van Olga's brief aan Sergey ziet er als volgt uit:
Microsoft Mail Internet Headers versie 2.0Ontvangen: van mail.litwareinc.com () door mail.proseware.com met Microsoft SMTPSVC(6.0.3790.0);wo, 12 december 2007 13:39:22 -0800Ontvangen: van mail (RDNS mislukt) via mail.litware.com met Microsoft SMTPSVC(6.0.3790.0);wo 12 december 2007 13:38:49 -0800Van: "Kelly J. Weadock"
Wanneer Olga een bericht naar het adres stuurt [e-mailadres beveiligd], maakt ze het op haar computer, die wordt geïdentificeerd als (i101-177.nv.litwareinc.com). De tekst van het bericht wordt van haar computer naar de e-mailserver mail.litwareinc.com verzonden. Olga zal haar bericht niet meer zien - verdere verwerking wordt uitgevoerd door mailservers zonder haar deelname. Wanneer Olga's mailserver een bericht ontvangt dat is verzonden naar [e-mailadres beveiligd], zal het contact opnemen met de mailserver van Proseware en het bericht daar bezorgen. Het wordt opgeslagen op de proseware.com-server totdat Sergey zijn zakelijke e-mail controleert.
Kopteksten van e-mailberichten interpreteren
Hieronder vindt u een beschrijving van de standaard e-mailkopvelden.
Microsoft Mail Internet Headers Versie 2.0
Deze header wordt toegevoegd door Outlook.
Ontvangen: van mail.litwareinc.com () via mail.proseware.com met Microsoft SMTPSVC(6.0.3790.0); Di, 12 december 2017 13:39:22 -0800
Deze informatie geeft aan dat het bericht is verzonden op dinsdag 12 december 2017 om 13:39:22 (1: US) Pacific Standard Time (dit is 8 uur later dan Greenwich Mean Time (GMT); dus "- 0800").
Ontvangen: via e-mail (RDNS mislukt) via mail.litware.com met Microsoft SMTPSVC (6.0.3790.0); Di, 12 december 2017 13:38:49 -0800
Deze uitzending vond plaats op dinsdag 12 december 2017 om 13:38:49 (1:00) Pacific Standard Time (dit is 8 uur later dan Greenwich Mean Time (UTC); dus “–0800”).
Van: "Kelly J. Weadock"
Het bericht is verzonden door Olga Zueva vanaf het e-mailadres [e-mailadres beveiligd].
Naar:
Ontvanger van het bericht.
CC:
Ontvangers van kopieën van het bericht.
Opmerking: Bcc-ontvangers worden niet aangegeven in de header.
Betreft: Beoordeling van personeelsopdrachten
Onderwerp van het e-mailbericht.
De datum en tijd waarop het e-mailbericht is verzonden, gebaseerd op de computerklok van de afzender.
MIME-versie: 1.0
De MIME-protocolversie die door de afzender wordt gebruikt.
Inhoudstype: meerdelig/gemengd;
Extra MIME-header. Het is bedoeld voor MIME-compatibele e-mailprogramma's en specificeert welk type inhoud u in het bericht kunt verwachten.
X-Mailer: Microsoft Office Outlook, build 12.0.4210
Het bericht is verzonden met Microsoft Office Outlook, buildversie 12.0.4210.
X-MimeOLE: Geproduceerd door Microsoft MimeOLE V6.00.2800.1165
Het mailprogramma (MIME OLE-software) dat door de afzender wordt gebruikt.
Thread-index: AcON3CInEwkfLOQsQGeK8VCv3M+ipA==
Deze header wordt gebruikt om meerdere berichten in één stream te combineren. In Microsoft Outlook kan deze informatie bijvoorbeeld in de gespreksweergave worden gebruikt om naar berichten binnen één gespreksthread te zoeken.
Terugweg: [e-mailadres beveiligd]
Adres afzender van bericht.
Bericht-ID:
Een nummer dat door de mail.litware.com-server aan een bericht wordt toegewezen voor identificatiedoeleinden. Dit ID zal altijd bij het bericht aanwezig zijn.
Een tijdstempel die aan een bericht wordt toegevoegd wanneer het voor de eerste keer een Microsoft Exchange-server passeert.
