Root » Servers » Mail servers » SMTP sessie
Servers onder elkaar:
het verloop van een SMTP sessie
SMTP
Hoe ziet een smtp sessie er uit? Als we de weg dat een email bericht aflegt bekijken, zien we dat SMTP (Simple Mail Transfer Protocol) overwegend is. Uit de figuur die we hier herhalen zien we dat er 3 soorten SMTP transakties mogelijk zijn:
  1. Onze server die een uitgaand bericht stuurt naar het internet
  2. Onze server die een inkomend bericht ontvangt van het internet
  3. Onze server die een bericht ontvangt van een gebruiker.
Waarom lokale berichten speciaal behandeld moeten wordt later wel duidelijk.

Het binnenhalen van de mail door de gebruiker (POP of IMAP) wordt hier niet besproken.

Uitgaande SMTP sessie

Bij een uitgaande SMTP sessie wordt een bericht van de server naar een externe gebruiker gestuurd. Onze mail server heeft eerst bepaald naar welke server het bericht afgeleverd moet worden: met DNS wordt de MX van de ontvanger bepaald. Er wordt een verbinding met de server gelegd en dit is wat er in de transaktielog verschijnt:

SYSTEM          [05D8] 01:34:08 Client session DNS query 'pandora.be' 0 (1) [OK - 2]
SYSTEM          [05D8] 01:34:08 Client session Connecting to 'smtp-pandora.telenet-ops.be'
195.130.132.51  [05D8] 01:34:08 Client session Connected
195.130.132.51  [05D8] 01:34:08 Client session <<< 220 circe.telenet-ops.be ESMTP Postfix
195.130.132.51  [05D8] 01:34:08 Client session >>> EHLO mail.verfaillie.com
195.130.132.51  [05D8] 01:34:08 Client session <<< 250 8BITMIME
195.130.132.51  [05D8] 01:34:08 Client session >>> MAIL From:<postmaster@idemdito.org> SIZE=1006
195.130.132.51  [05D8] 01:34:08 Client session <<< 250 Ok
195.130.132.51  [05D8] 01:34:08 Client session >>> RCPT To:<xxxx@pandora.be>;
195.130.132.51  [05D8] 01:34:08 Client session <<< 250 Ok
195.130.132.51  [05D8] 01:34:08 Client session >>> DATA
195.130.132.51  [05D8] 01:34:08 Client session <<< 354 End data with <CR><LF>.<CR><LF>
195.130.132.51  [05D8] 01:34:08 Client session <<< 250 Ok: queued as E630133E93
195.130.132.51  [05D8] 01:34:08 Client session *** <postmaster@idemdito.org> <xxxx@pandora.be> 1 1006 00:00:00 OK ZHC87404
195.130.132.51  [05D8] 01:34:08 Client session >>> QUIT
195.130.132.51  [05D8] 01:34:08 Client session <<< 221 Bye
SYSTEM          [05D8] 01:34:08 Client session Disconnected
Onze server heeft een bericht dat verzonden moet worden naar xxxx@pandora.be. De server doet een DNS MX query voor pandora.be. De MX is smtp-pandora.telenet-ops.be. Er wordt een verbinding met deze mailserver gelegd. "<<<" geeft aan dat het inkomende berichten zijn, ">>>" geeft aan dat het uitgaande opdrachten of berichten zijn.

Hier zien we heel goed de basisstruktuur van een smtp transaktie:


EHLO mail.verfaillie.com
250...
MAIL FROM: ...
250...
RCPT TO: ...
250...
DATA
354...
250...

Eerst geven we aan wie we zijn met een HELO of EHLO (extended HELO, want onze mailserver kan de extended SMTP gebruiken). We proberen eerst met EHLO, als de ontvanger extended SMTP niet ondersteunt (en dus EHLO niet "begrijpt"), dan proberen we opnieuw met HELO.
De HELO-naam moet de naam van de mailserver zijn, zoals in DNS aangegeven is. De ontvanger kan dit controleren door een reverse DNS te doen van het IP adres. Correspondeert de naam niet met de aangegeven naam, of is er geen PTR record aanwezig, dan kan de ontvanger de mail weigeren.

MAIL FROM: hier geven we het email van de afzender. Dit hoeft niet noodzakelijk dezelfde email adres te zijn als wat in de headers van het bericht zelf voorkomt. Bij een mailing kan dit namelijk verschillen: bij MAIL FROM wordt de naam van de mailer gegeven, in het bericht zelf wordt bijvoorbeeld de naam van de afzender gegeven (of omgekeerd, naargelang men wilt dat de antwoorden op het bericht naar de afzender van het bericht gaan of naar de mailing list).

RCPT TO: is de effektieve bestemmeling, dat hier ook niet noodzakelijk moet overeenkomen met het adres in de headers van het bericht. Bij een mailing list of distributielijst zal hier het adres van de lijst voorkomen. De mail server waarop de distributielijst zit zal het bericht dan versturen naar alle adressen op de lijst. Bij het verdelen naar de aangesloten adressen zal de server een nieuwe RCPT TO: maken voor ieder adres, zonder echter de headers te wijzigen.

Dan volgt het bericht zelf (eerst de headers en dan de tekst van het bericht). Het bericht wordt afgesloten met een punt op een lege regel. Dit is eigenlijk het commando "einde van het bericht". De zender kan nu een nieuwe transactie starten (MAIL FROM:) of vragen dat de verbinding verbroken wordt (QUIT).

Bij iedere regel geeft de server een statuscode terug: 220-identificatie, 250-ok, enz.

Inkomende SMTP sessie

Hier ontvangen we een bericht van het internet voor één van de lokale gebruikers.

195.238.6.53    [0744] 02:15:06 Connected
195.238.6.53    [0744] 02:15:06 >>> 220 mail.verfaillie.com ESMTP Merak 9.0.0-5; Sat, 20 Oct 2007 02:15:06 +0200
195.238.6.53    [0744] 02:15:06 <<< EHLO mailrelay003.isp.belgacom.be
195.238.6.53    [0744] 02:15:06 >>> 250-mail.verfaillie.com Hello mailrelay003.isp.belgacom.be [195.238.6.53], pleased to meet you.
195.238.6.53    [0744] 02:15:06 <<< MAIL FROM:<xxxx@skynet.be> SIZE=23529
195.238.6.53    [0744] 02:15:06 >>> 250 2.1.0 <xxxx@skynet.be>... Sender ok
195.238.6.53    [0744] 02:15:06 <<< RCPT TO:<marc@verfaillie.be>
195.238.6.53    [0744] 02:15:06 >>> 250 2.1.5 <marc@verfaillie.be>... Recipient ok
195.238.6.53    [0744] 02:15:06 <<< DATA
195.238.6.53    [0744] 02:15:06 >>> 354 Enter mail, end with "." on a line by itself
195.238.6.53    [0744] 02:15:10 *** <xxxx@skynet.be> <marc@verfaillie.be> 1 27095 00:00:04 OK ZKJ31306
195.238.6.53    [0744] 02:15:10 >>> 250 2.6.0 27095 bytes received in 00:00:04; Message id ZKJ31306 accepted for delivery
195.238.6.53    [0744] 02:15:15 <<< QUIT
195.238.6.53    [0744] 02:15:15 >>> 221 2.0.0 mail.verfaillie.com closing connection
195.238.6.53    [0744] 02:15:15 Disconnected
We hebben mail ontvangen van iemand die klant bij Skynet is. De uitgaande mailserver van Skynet is mailrelay003.isp.belgacom.be. Belgacom, of Skynet gebruiken een hele cluster servers, je kan mails ontvangen van meerdere servers. Dit is een heel normale transaktie. Nu gaan we een spam-bericht bekijken:

216.234.107.186 [0744] 00:00:25 Connected
216.234.107.186 [0744] 00:00:25 >>> 220 mail.verfaillie.com ESMTP Merak 9.0.0-5; Sat, 20 Oct 2007 00:00:25 +0200
216.234.107.186 [0744] 00:00:25 <<< EHLO mail.electricalsalesco.com
216.234.107.186 [0744] 00:00:25 >>> 250-mail.verfaillie.com Hello mail.electricalsalesco.com [216.234.107.186], pleased to meet you.
216.234.107.186 [0744] 00:00:25 <<< MAIL FROM:<aw-confirm@eBay.com> SIZE=8776
216.234.107.186 [0744] 00:00:25 >>> 250 2.1.0 <aw-confirm@eBay.com>... Sender ok
216.234.107.186 [0744] 00:00:25 <<< RCPT TO:<marc@idemdito.org>
216.234.107.186 [0744] 00:00:26 >>> 250 2.1.5 <marc@idemdito.org>... Recipient ok
216.234.107.186 [0744] 00:00:26 <<< DATA
216.234.107.186 [0744] 00:00:26 >>> 354 Enter mail, end with "." on a line by itself
216.234.107.186 [0744] 00:00:26 *** <aw-confirm@eBay.com> <marc@idemdito.org> 1 8774 00:00:00 OK YGT12526
216.234.107.186 [0744] 00:00:26 >>> 250 2.6.0 8774 bytes received in 00:00:00; Message id YGT12526 accepted for delivery
216.234.107.186 [0744] 00:00:26 <<< QUIT
216.234.107.186 [0744] 00:00:26 >>> 221 2.0.0 mail.verfaillie.com closing connection
216.234.107.186 [0744] 00:00:26 Disconnected
Op het eerste gezicht lijkt alles normaal: EHLO, MAIL FROM, RCPT TO, DATA ... Maar mail.electricalsalesco.com heeft niets te maken met ebay.com. Dit is een server dat door spammers gehackt werd, zodat het spamberichten kan versturen. Het bericht hierboven, dat aanvaard werd, werd als spam gemarkeerd wegens elementen die op spam wijzen (mail.electricalsalesco.com heeft niets te maken met ebay, de inhoud van het bericht is spam-achtig, er zijn kleine fouten in het bericht, enz). Er zijn instellingen die controleren welke servers open relays zijn (ze laten spamberichten door) of gekraakt zijn zodat ze spam beginnen uit te spuwen. Deze instellingen (RBL of Real Time Blocking Lists) leggen lijsten aan van gekraakte servers. Als mijn mail server een bericht ontvangt van een server dat op zo'n lijst voorkomt, dan wordt het bericht geweigerd nog voor het de server kan bereiken (zo wordt bandbreedte bespaard).

Dit is een geweigerd bericht:


74.75.87.244    [0744] 02:40:29 Connected
74.75.87.244    [0744] 02:40:29 >>> 220 mail.verfaillie.com ESMTP Merak 9.0.0-5; Sat, 20 Oct 2007 02:40:29 +0200
74.75.87.244    [0744] 02:40:29 <<< EHLO cpe-74-75-87-244.maine.res.rr.com
74.75.87.244    [0744] 02:40:29 >>> 250-mail.verfaillie.com Hello cpe-74-75-87-244.maine.res.rr.com [74.75.87.244], pleased to meet you.
74.75.87.244    [0744] 02:40:29 <<< MAIL From:<spud@0hamilton.freeserve.co.uk>
74.75.87.244    [0744] 02:40:29 >>> 501 5.7.1 <spud@0hamilton.freeserve.co.uk>... Sender refused by the DNSBL sbl-xbl.spamhaus.org
74.75.87.244    [0744] 02:40:29 *** <spud@0hamilton.freeserve.co.uk> <> 0 0 00:00:00 INCOMPLETE-SESSION
74.75.87.244    [0744] 02:40:29 Disconnected
Dit is een server dat door spamhaus aangeduid werd als zijnde een gecompromiteerde server. Bij het aangaan van de verbinding met mijn server werd in de achtergrond aan spamhaus gevraagd of de server in kwestie wel te vertrouwen was. Let op de foutcode 501 in plaats van 250. De verbinding wordt direkt verbroken.

Inkomende SMTP sessie van eigen gebruikers

Gebruikers van het mailsysteem moeten zich kunnen aanmelden om van de faciliteiten van de server gebruik te kunnen maken: verzenden van berichten (relay), mailing lists, enz. Een speciale soort SMTP sessie wordt toegepast:

84.196.169.33   [0454] 08:11:00 Connected
84.196.169.33   [0454] 08:11:00 >>> 220 mail.verfaillie.com ESMTP Merak 9.0.0-5; Sun, 21 Oct 2007 08:11:00 +0200
84.196.169.33   [0454] 08:11:00 <<< EHLO t415492
84.196.169.33   [0454] 08:11:00 >>> 250-mail.verfaillie.com Hello t415492 [84.196.169.33], pleased to meet you.
84.196.169.33   [0454] 08:11:00 <<< AUTH CRAM-MD5
84.196.169.33   [0454] 08:11:00 >>> 334 PDIwMDqSlT1qWzjNtTAwQG1haWwudmVyZmFpbGxpZS5jb20+
84.196.169.33   [0454] 08:11:00 <<< bWFyYyBiNjk3MzU4OWFjZTAej5w7XszK42RenzY7JiqlG9OlZQ==
84.196.169.33   [0454] 08:11:00 >>> 235 2.0.0 Authentication successful
84.196.169.33   [0454] 08:11:00 <<< MAIL FROM:<marc@verfaillie.be> SIZE=4419
84.196.169.33   [0454] 08:11:00 >>> 250 2.1.0 <marc@verfaillie.be>... Sender ok
84.196.169.33   [0454] 08:11:00 <<< RCPT TO:<xxxx@yyyy.be>
84.196.169.33   [0454] 08:11:00 >>> 250 2.1.5 <xxxx@yyyy.be>... Recipient ok
84.196.169.33   [0454] 08:11:00 <<< DATA
84.196.169.33   [0454] 08:11:00 >>> 354 Enter mail, end with "." on a line by itself
84.196.169.33   [0454] 08:11:00 *** <marc@verfaillie.be> <xxxx@yyyy.be> 1 4391 00:00:00 OK AQG46800
84.196.169.33   [0454] 08:11:00 >>> 250 2.6.0 4391 bytes received in 00:00:00; Message id AQG46800 accepted for delivery
84.196.169.33   [0454] 08:11:00 <<< QUIT
84.196.169.33   [0454] 08:11:00 >>> 221 2.0.0 mail.verfaillie.com closing connection
84.196.169.33   [0454] 08:11:00 Disconnected
Het is de gebruiker die zich moet aanbieden om zich te identificeren met het commando AUTH. De server zal dan een challenge string versturen en de gebruiker zal antwoorden met een response string. Passwoords worden nooit over het internet verstuurd met deze methode (CRAM: challenge-response authentification method). Van zodra ik geauthentificeerd ben kan ik gebruik maken van de faciliteiten van de server, met name het versturen van mails.

Gebruikers van Telenet of Skynet hoeven zich niet te identificeren: van zodra ze gebruik maken van het netwerk van Skynet of Telenet hebben ze toegang tot de uitgaande server. Het probleem met deze configuratie is dat als de gebruiker zijn laptop zowel op het werk als thuis gebruikt, hij geen mails meer kan versturen als hij in het verkeerde netwerk zit (de relay van telenet zal geen mails aanvaarden van iemand die op het skynet netwerk zit en omgekeerd). Aangezien ik met roaming gebruikers werk moet ik wel een dergelijke beveiliging gebruiken: het is niet de bedoeling dat deze server als relay dient voor alle mails van skynet gebruikers.

Als voetnoot moet ik nog vermelden dat de laatste EHLO niet geldig is (t415492 is geen FQDN of fully qualified domain name, de naam van een host dat met het internet verbonden is). Had de gebruiker zich niet geidentificeerd, dan was het bericht geweigerd geweest.

Op de volgende pagina bespreken we de DNS records die van belang zijn bij een mail-transaktie.

Links to relevant pages - Liens vers d'autres pages au contenu similaire - Links naar gelijkaardige pagina's