Το προφίλ μας στο Google Plus
5

Ο δικός σας mailserver: Το γιατί και το πώς

Κάθε φορά που σχεδιάζουμε ένα νέο πρότζεκτ, η αλήθεια είναι ότι δεν χρειαζόμαστε πολλές δικαιολογίες για να βάλουμε μπρος: μας αρκεί να ξέρουμε ότι το πρότζεκτ θα αποδειχθεί ενδιαφέρουσα πρόκληση ή έστω ευχάριστη ενασχόληση. Εντάξει, σίγουρα μαθαίνουμε αρκετά στην πορεία, ενώ καθόλου δεν αποκλείεται να φτάσουμε και σε αποτελέσματα που είναι χρήσιμα στην πράξη. Αλλά ας μη γελιόμαστε: Αυτό που πραγματικά θέλουμε είναι να περνάμε καλά, αφού στην πλειονότητα των περιπτώσεων δεν υφίσταται καμία διάκριση μεταξύ πρότζεκτ και παιχνιδιού ;)

Μέρος 1: Ο δικός σας mailserver: Το γιατί και το πώς
Μέρος 2: Υποδομή για τον mailserver μας
Μέρος 3: Εγκατάσταση και βασική ρύθμιση Mail-in-a-Box
Μέρος 4: Πρακτική χρήση του Mail-in-a-Box και κόλπα

Σε μια πρώτη εξέταση, η δημιουργία ενός mailserver φαντάζει απλά ως άλλο ένα πρότζεκτ με το οποίο κάλλιστα θα μπορούσαμε ν’ ασχοληθούμε — και είναι περίεργο που μέχρι τώρα δεν είχαμε ασχοληθεί. Θα το εντάσσαμε μάλιστα στην ίδια κατηγορία με πρότζεκτ όπως, π.χ., συγκρότηση του δικού μας router/firewall με το pfSense, στήσιμο του δικού μας OpenVPN server, δημιουργία webserver από το μηδέν κ.ά. Αναρωτιέστε τι κοινό έχουν τα παραδείγματα που μόλις αναφέραμε; Μα, το ότι όλα τους αφορούν σε προβλήματα που είναι ήδη λυμένα — και μάλιστα καλά λυμένα. Πράγματι:

  • Αν για οποιονδήποτε λόγο επιθυμούμε ν’ αναβαθμίσουμε την προστασία που παρέχει το modem/router μας στο τοπικό δίκτυο, τότε αντί να ψάχνουμε για νέο hardware που θα μπορέσει να δεχθεί το pfSense μπορούμε απλά να αντικαταστήσουμε τη συσκευή με μια καλύτερη. Εναλλακτικά, αν (σοφά) ζητάμε κάποια λύση Open Source, τότε το υπάρχον modem/router ίσως να δέχεται κάποιο εκ των OpenWrt/DD-WRT firmware.
  • Αν θέλουμε παρουσία στο web δεν υπάρχει λόγος να ξεκινήσουμε με αγορά VPS, εγκατάσταση λειτουργικού συστήματος και ρύθμιση κάποιου webserver όπως, π.χ., είναι ο Apache ή ο nginx. Αντί για όλα αυτά, αρκεί να επιλέξουμε μια υπηρεσία web hosting και το νέο site απλά θα περιμένει από εμάς ν’ αρχίσουμε ν’ ανεβάζουμε περιεχόμενο.
  • Αν πάλι χρειαζόμαστε πρόσβαση σε υπηρεσία VPN, τότε αντί να ψάξουμε για VPS και μετά να μπλέξουμε με το OpenVPN και τις ρυθμίσεις και τα κλειδιά και τους clients, αρκεί να στραφούμε σε κάποια από τις πάμπολλες υπηρεσίες VPN. Το μόνο που θα χρειαστεί να ελέγξουμε είναι αν η υπηρεσία κρυπτογραφεί ισχυρά και προστατεύει την ανωνυμία των πελατών της.
  • Αν θέλουμε email και (ορθά) δεν μας κάνει αυτό που μάς έχει δώσει ο ISP, τότε αντί να στήσουμε τον δικό μας mailserver (είμαστε στο 2015, χελό-όου!) αρκεί ν’ ανοίξουμε δωρεάν λογαριασμό σε κάποιο από τα Gmail, Yahoo!, Outlook κ.ά. Στοιχηματίζουμε μάλιστα ότι δεν υπάρχει αναγνώστης χωρίς *τουλάχιστον* μία διεύθυνση email σε Gmail, Yahoo!, Outlook, Live, Hotmail και τα ρέστα.

Προβλήματα σαν τα προαναφερθέντα είναι προ πολλού λυμένα, λοιπόν, αλλά ως αναγνώστες του deltaHacker ξέρετε πολύ καλά ότι, στην πράξη, συχνά γυρίζουμε την πλάτη στις έτοιμες λύσεις κι εφευρίσκουμε ξανά τον τροχό. Δεν είναι επειδή είμαστε (κρυφο)μαζοχιστές ή κάτι τέτοιο. Έχουμε όμως συνειδητοποιήσει ότι, αν θέλεις να μάθεις πραγματικά, τότε οφείλεις ν’ ασχοληθείς, να πειραματιστείς, να φέρεις τα πάνω κάτω — ακόμη κι όταν εκ των προτέρων ξέρεις ότι η δική σου λύση δεν θα είναι καλύτερη από εκείνες που ήδη διατίθενται Εκεί Έξω (TM). Τώρα, εκτός από την εκπαιδευτική αξία της προσωπικής ενασχόλησης, σας ρωτάμε: Είναι το ίδιο διασκεδαστικό να φτιάχνεις κάτι μόνος σου, από το να το βρίσκεις έτοιμο; (Hint: Η σωστή απάντηση είναι “όχι, δεν είναι το ίδιο διασκεδαστικό” :P)

Ζήτημα εμπιστοσύνης
Πιστεύουμε θα συμφωνήσετε πως το να υλοποιεί κανείς τις δικές του λύσεις είναι εκπαιδευτικό αλλά κι εξόχως διασκεδαστικό. Σας θέτουμε κι άλλο ένα ερώτημα: Εμπιστεύεστε εξίσου κάτι που σας προσφέρεται έτοιμο και λίγο-πολύ λειτουργεί ως μαύρο κουτί, όπως όσο εμπιστεύεστε κάτι παρόμοιο που έχετε φτιάξει μόνοι σας; Αναμφισβήτητα, αναλόγως για τι πράγμα μιλάμε η απάντηση διαφέρει…

Ειδικά στην περίπτωση του mailserver, το πρόβλημα της διακίνησης της ηλεκτρονικής αλληλογραφίας είναι εδώ και πολλές δεκαετίες λυμένo — και τη λύση αυτή υλοποιούν όμορφα και σωστά όλοι όσοι προσφέρουν υπηρεσίες email. Όμως το αρχικό ερώτημά μας δεν αφορά τόσο στην τεχνική αρτιότητα, όσο στον έλεγχο των δεδομένων που μας αφορούν και συχνά είναι εξαιρετικά ευαίσθητα. Αναδιατυπώνουμε, λοιπόν: Εμπιστεύεστε τα emails σας στους mailservers τρίτων; Ίσως ναι, ίσως όχι, ίσως δεν σας νοιάζει καν. Αν σας νοιάζει –έστω και λίγο– τι κάνετε γι’ αυτό;

Μία λύση είναι η κρυπτογράφηση του email “από άκρο σε άκρο”, π.χ. με χρήση του συνδυασμού Thunderbird & Enigmail. Όπως ενδεχομένως θα παρακολουθήσατε στα deltaCast s02e05 και s02e06, κάθε φορά που επιλέγουμε να κρυπτογραφούμε το email μας τότε ο μόνος που μπορεί να το διαβάσει είναι ο παραλήπτης και κανείς άλλος. Ας μένουν τα email μας αποθηκευμένα στους σκληρούς δίσκους των mailservers όσον καιρό (κάποιοι) θέλουν: Από τη στιγμή που είναι κρυπτογραφημένα, το μόνο που μπορεί να βλέπει κάποιος τρίτος είναι σωροί τυχαίων χαρακτήρων χωρίς κανένα νόημα απολύτως.

Κάπως έτσι είναι τα πράγματα με την κρυπτογράφηση δημοσίου κλειδιού, υπάρχει όμως κι ένα “αλλά”: Ακόμη και στην ακραία περίπτωση που κρυπτογραφούμε κάθε email που στέλνουμε –μάλλον απίθανο, αλλά ας υποθέσουμε ότι συμβαίνει–, εξακολουθούμε να μην έχουμε τον έλεγχο του mailserver. Κι από τη στιγμή που δεν έχουμε τον έλεγχο του mailserver, 100% ήσυχοι δεν δικαιούμαστε να είμαστε. Για να μην κινδυνολογούμε, ας πούμε ότι είμαστε κατά 99,99% βέβαιοι ότι κανείς δεν πρόκειται να βγάλει νόημα από τα κρυπτογραφημένα μας emails. Όμως η NSA και άλλες υπηρεσίες ανά τον κόσμο αγωνίζονται γι’ αυτό το 0,01%. Σύμφωνα με διαρροές που έχουν συμβεί κατά το παρελθόν, η NSA δείχνει ιδιαίτερο ενδιαφέρον ειδικά στις κρυπτογραφημένες επικοινωνίες. Ίσως σήμερα να μην είναι σε θέση να αποκρυπτογραφεί κρυπτογραφημένα μηνύματα όταν δεν έχει τα ιδιωτικά κλειδιά των παραληπτών, όμως συχνά φροντίζει να τα αποθηκεύει διότι…

  • δεν αποκλείεται να αποκτήσει τα κλειδιά που χρειάζεται, π.χ., δια της πλαγίας ή/και της νομικής οδού
  • ίσως μπορέσει να εκμεταλλευτεί κάποιο (άγνωστο) software bug, το οποίο επιτρέπει την κατάλυση του αντίστοιχου συστήματος κρυπτογράφησης.

Για να μη φτάνουμε σε υπερβολές, ας υποθέσουμε ότι τίποτε από τα προηγούμενα δεν συμβαίνει ή, ότι, ακόμη κι αν κάποια στιγμή συμβεί κάτι παρόμοιο, σιγά να μην είμαστε εμείς οι στόχοι :D Όμως το αρχικό ερώτημα επιμένει: Να εμπιστευόμαστε mailservers που δεν είναι υπό τον έλεγχό μας ή μήπως αξίζει να πάρουμε την κατάσταση στα χέρια μας;

To email είναι το πιο σημαντικό στοιχείο της δραστηριότητάς μας στο Internet κι αν είστε από εκείνους που προτιμούν να έχουν τον έλεγχο, τότε συνεχίστε το διάβασμα. Σας ευχόμαστε από τώρα καλή διασκέδαση!

Τι ακριβώς είναι ένας mailserver;
Σε πρώτη προσέγγιση μπορούμε να υποθέσουμε –και δεν θα έχουμε άδικο– ότι πρόκειται για ένα εικονικό ή φυσικό μηχάνημα, το οποίο είναι εξοπλισμένο με το κατάλληλο λογισμικό ώστε να δέχεται και να διακινεί ηλεκτρονική αλληλογραφία. Κάπως έτσι έχουν τα πράγματα, μόνο που είναι αρκετά πιο περίπλοκα όσον αφορά στο λογισμικό. Επίσης, γι’ αυτή τη διακίνηση της αλληλογραφίας χρησιμοποιούνται περισσότερα από ένα πρωτόκολλα. Αν λοιπόν θέλουμε μια καλύτερη εικόνα για το τι ακριβώς είναι ένας mailserver, τότε οφείλουμε να έχουμε κατά νου ότι στη συνολική υποδομή του email συναντάμε τις ακόλουθες κατηγορίες εφαρμογών.

MUA, Mail User Agent. Ονομάζεται και mail client και είναι ένα πρόγραμμα για τη λήψη και την αποστολή email. Παραδείγματα mail clients είναι τα Mozilla Thunderbird, Apple Mail, Microsoft Outlook κ.ά. Οι εφαρμογές web που παρέχουν πρόσβαση στο email μας, όπως αυτές των Gmail, Microsoft, Yahoo! κ.ά., αν και επίσης ανήκουν στην κατηγορία των MUA συνήθως αναφέρονται ως webmail applications.

MSA, Mail Submission Agent. Η δουλειά ενός MSA είναι να λαμβάνει τα emails που αποστέλλουν οι MUA και να τα δίνει σε κάποιον MTA για αποστολή (βλ. συνέχεια). Το επίσημο port για έναν MSA είναι το 587/TCP. Για την επικοινωνία με τους mail clients χρησιμοποιεί το πρωτόκολλο SMTP (Simple Mail Transfer Protocol) και απαιτεί authentication. Να σημειώσουμε εδώ ότι πολλοί MTA αναλαμβάνουν και υπηρεσίες MSA (από το port 25/TCP και χωρίς να απαιτούν authentication).

MTA, Mail Transfer Agent. Η ευθύνη ενός MTA είναι να διακινεί την ηλεκτρονική αλληλογραφία από υπολογιστή σε υπολογιστή, λειτουργώντας είτε ως client είτε ως server και πάντα ακολουθώντας το πρωτόκολλο SMTP. Το επίσημο port για την επικοινωνία μεταξύ των MTA είναι το 25/TCP. Το ίδιο port χρησιμοποιεί κι ένας MSA, όταν παραδίδει email σε κάποιον MTA (αλλά όταν παραλαμβάνει email από κάποιον MUA, ο MSA χρησιμοποιεί το port 587/TCP). Οι ΜΤΑ ονομάζονται και mail relays και χωρίς αυτούς τα εξερχόμενα emails μας θα έφταναν το πολύ έως κάποιον MSA, αλλά όχι κατ’ ανάγκη στους υπολογιστές των παραληπτών. Ένας υπολογιστής που τρέχει λογισμικό MTA αναφέρεται κι ως mailserver, mail exchanger ή MX host. Για την ηλεκτρονική αλληλογραφία, ο MTA αποτελεί ό,τι ένα ταχυδρομικό γραφείο αποτελεί για τη συνηθισμένη αλληλογραφία. Σε κάθε domain (π.χ., deltahacker.gr, parabing.com) είναι δυνατόν να αντιστοιχίζεται ένας mailserver, ο οποίος είναι υπεύθυνος για τη λήψη email που προορίζεται για το domain. Μπορούμε να φανταζόμαστε το domain ως μια περιοχή και τον MTA ως το ταχυδρομικό γραφείο που καλύπτει την περιοχή. Η αντιστοίχιση domain <--> mailserver γίνεται στο επίπεδο του DNS με χρήση των λεγόμενων mail exchanger resource records ή απλά MX records. Μερικά παραδείγματα δημοφιλών MTA για Unixοειδή συστήματα είναι τα sendmail, qmail, Postfix, Exim και OpenSMTPD.

MDA, Mail Delivery Agent. Αποστολή ενός MDA ή διαφορετικά LDA (Local Delivery Agent) είναι να παραδίδει την αλληλογραφία στους τοπικούς χρήστες ενός υπολογιστή, αποθηκεύοντάς την στα αντίστοιχα mailboxes. Οι MDA λαμβάνουν την αλληλογραφία από τους MTA. Δημοφιλείς MDA για συστήματα Unix είναι τα procmail και maildrop.

MRA, Mail Retrieval Agent. Ο MRA είναι το λογισμικό που φέρνει την αλληλογραφία στους υπολογιστές των χρηστών. Συνεργάζεται με κάποιον MDA και αποτελεί είτε μεμονωμένη εφαρμογή (π.χ., fetchmail, getmail) είτε μέρος ενός MUA.

Σχηματικά, μια διευθέτηση όλων των προαναφερθέντων κατηγοριών λογισμικού θα μπορούσε να είναι η ακόλουθη:

MUA --> MSA --> MTA --> ... --> MTA --> MDA ==> MRA ==> MUA

Τα απλά βελάκια (–>) υποδηλώνουν λειτουργίες αποστολής email, ενώ τα διπλά (==>) λειτουργίες λήψης. Το σχήμα αναπαριστά τη διαδρομή ενός μηνύματος από τον αποστολέα (MUA στ’ αριστερά) έως τον παραλήπτη (MUA στα δεξιά). Σημειώνουμε ότι, κατά περίπτωση, ένας MTA ενδέχεται να εκτελεί και χρέη MSA. Παρατηρήστε επίσης το απλό βελάκι μεταξύ MTA και MDA: Ο τελευταίος στη σειρά MTA δεν είναι δυνατόν να αποθηκεύει τα emails που λαμβάνει. Δεν γνωρίζει πώς να το κάνει, ούτε είναι δική του ευθύνη, γι’ αυτό και τα παραδίδει στον MDA. Εκείνος ξέρει πού και πώς να τα αποθηκεύει, οπότε δεν τα στέλνει κάπου αλλού. Με χαρά όμως δέχεται αιτήματα από τον όποιο MRA (διπλό βελάκι) και πρόθυμα τον εξυπηρετεί. Τέλος, ένας MUA είναι συνηθισμένο να ενσωματώνει και λειτουργίες MRA (αλλά όχι κατ’ ανάγκη: βλ., π.χ., το Mutt).

Κάπως έτσι φαίνεται μέσα από το nmap ο σημερινός μας mailserver (για το colder.xyz). Στο port 25/TCP συνδέονται άλλοι mailservers, μέσω SMTP (1), στο 587/TCP συνδέονται οι mail clients για να στέλνουν email, επίσης μέσω SMTP (2), ενώ στο 993/TCP συνδέονται οι mail clients για να λαμβάνουν email, μέσω IMAP (3).

Μήπως τα μπλέξουμε;
Από την προηγούμενη ενότητα ίσως αποκομίσατε την εντύπωση ότι η δημιουργία ενός mailserver, ο οποίος θα λειτουργεί σωστά και αξιόπιστα, δεν είναι ό,τι πιο απλό. Αν πράγματι σας δημιουργήθηκε αυτή η εντύπωση, από τη μεριά μας ένα έχουμε να σας πούμε: Ορθά σας δημιουργήθηκε, οι mailservers είναι εξαιρετικά πολύπλοκες οντότητες :/

Και ξέρετε κάτι; Η κατάσταση είναι περισσότερο περίπλοκη απ’ όσο αρχικά δείχνει. Ακόμη και μετά την επιλογή των κατάλληλων MxA και τη σωστή ρύθμισή τους, μένουν ένα σωρό άλλες δουλειές ώστε…

  • τα credentials των λογαριασμών μας να μη μεταδίδονται σε μη-κρυπτογραφημένη μορφή
  • τα emails μας να ταξιδεύουν μέσω κρυπτογραφημένων καναλιών
  • το domain μας να μην καταλήξει σε blacklist με SPAM domains
  • οι άλλοι mailservers να μη χαρακτηρίζουν τα emails που στέλνουμε ως SPAM (αυτό είναι δυνατόν να συμβαίνει κι ας μην είναι το domain μας σε blacklist).

Σκεφτείτε και το άλλο: Ως ο μοναδικός διαχειριστής του mailserver θα είστε κι ο μοναδικός υπεύθυνος για τη συντήρησή του ώστε, αν μη τι άλλο, να εφαρμόζονται έγκαιρα τα πλέον πρόσφατα security patches. Η αμέλεια στην περίπτωση ενός mailserver δεν συγχωρείται εύκολα. Αν λόγω κάποιου bug ή επιπόλαιης ρύθμισης ο mailserver πέσει στα χέρια των spammers ή αρχίσει να λειτουργεί ως open relay, τότε αφενός το μηχάνημά σας θα γίνει μέλος ενός δικτύου που συμβάλλει ώστε το Internet να μην είναι ένα τόσο ευχάριστο μέρος, αφετέρου το ωραιότατο domain σας θα καταλήξει σε ένα σωρό blacklists. Έστω κι αν μιλάμε για μία μόνο blacklist, το να αφαιρέσετε το domain σας απ’ αυτή δεν θα είναι ό,τι πιο εύκολο.

Μια φορά κι έναν καιρό
Παλιότερα, μιλάμε για τουλάχιστον 10 χρόνια πριν, συντηρούσαμε τον δικό μας mailserver σε ένα PC με Gentoo Linux, στο σπίτι. Από το 2003 διαθέταμε ένα domain, το defiant.gr, και το εν λόγω box είχε γίνει ο mailserver για το domain. Στο σπίτι βεβαίως δεν υπήρχε στατική διεύθυνση IP, οπότε χρησιμοποιούσαμε την υπηρεσία custom dynamic DNS της DynDNS (σήμερα ονομάζεται απλά Dyn) ώστε το hostname του box να είναι το homeunix.defiant.gr. Το port 25, εξάλλου, ήταν μπλοκαρισμένο από τον ISP μας. Το ίδιο ισχύει και σήμερα με τους ISP, για λόγους περιορισμού του SPAM. Εξαιτίας αυτής της πολιτικής ο mailserver μας ήταν μη-προσβάσιμος από όλους τους άλλους mailserver. Γι’ αυτό και είχαμε καταφύγει σε μια επί πληρωμή υπηρεσία που προσέφερε η DynDNS, η οποία αναλάμβανε να “μαζεύει” τα εισερχόμενα emails για το domain και να τα αποθηκεύει –για περιορισμένο χρονικό διάστημα– στους servers της εταιρείας. Το PC με το Gentoo δεν ήταν ανοικτό 24/7, αλλά όταν ενεργοποιούταν τότε η υπηρεσία της DynDNS του προωθούσε αυτομάτως τα email — και μάλιστα όχι στο port 25 αλλά σ’ αυτό που είχαμε ορίσει εμείς (μάλλον ήταν το 50025). Ο MTA του box ήταν το postfix και, επιπρόσθετα, χρησιμοποιούσαμε το ClamAV για τον εντοπισμό ιών, καθώς και το SpamAssassin για το φιλτράρισμα της ανεπιθύμητης αλληλογραφίας. Την ίδια την αλληλογραφία κατά κύριο λόγο τη διαχειριζόμασταν μέσω του web interface που προσέφερε το SquirrelMail. Το όλο setup δούλευε μια χαρά και μάλιστα ο ταπεινός μας server είχε αποδείξει την αξία του με πολλούς τρόπους. (Πώς να το κάνουμε, το να είσαι τη μία στη Νέα Υόρκη, την άλλη στο Σαν Φρανσίσκο, την παράλλη στο Μόναχο και, σε κάθε περίπτωση, όταν επιστρέφεις στο ξενοδοχείο να παίρνεις το email σου από ένα PC κάπου στο Νέο Κόσμο, είναι ένα τεστ που μετράει.)

Εννέα χρόνια πριν: Έλεγχος του email μας από ξενοδοχείο στο San Fransisco, με σύνδεση στο web interface του mailserver μας, κάπου στο Νέο Κόσμο. Η επίσκεψη στο San Fransisco είχε γίνει στο πλαίσιο του IDF και τόσα χρόνια μετά δυσκολευόμαστε να θυμηθούμε πώς ακριβώς είχε καινοτομήσει *τότε* η εταιρεία :P

Το μόνο θέμα που είχαμε με τον συγκεκριμένο mailserver αφορούσε στη συντήρησή του. Σκεφτείτε ότι το Gentoo ήταν –και συνεχίζει να είναι– source based distribution, οπότε από ένα σημείο και μετά οι μεταγλωττίσεις παύουν να είναι τόσο διασκεδαστικές και η μόνη τους θετική συνεισφορά είναι στην αύξηση του λογαριασμού της ΔΕΗ. Κάπως έτσι, το καλοκαίρι του 2007, όταν με τον κο Αρχισυντάκτη (TM) του deltaHacker βρισκόμασταν στο Τορόντο, αποφασίσαμε πως καλό θα ήταν, έτσι, για αλλαγή, να μεταφέρουμε το domain στη Google και το email μας να είναι, ουσιαστικά, hosted από τον “κολοσσό της αναζήτησης”. (Έτσι λέγαμε τότε τη Google, κυρίως για να αυτοσαρκαστούμε με τις κλισέ εκφράσεις που χρησιμοποιούσαμε στο περιοδικό που γράφαμε.) Ένα μεσημέρι, λοιπόν, από το ξενοδοχείο που διαμέναμε, μετακομίσαμε το domain στο λεγόμενο “Google Apps for Domain” και με ένα σκριπτάκι μεταφέραμε όλη την αλληλογραφία από το PC στο Νέο Κόσμο, στο cloud της Google. Διακόψαμε βεβαίως την υπηρεσία mail forwarding (ή όπως αλλιώς λεγόταν) της DynDNS και, αφού βεβαιωθήκαμε ότι το email μας είναι πλέον προσβάσιμο μέσα από το γνώριμο web interface του Gmail, κάναμε κι ένα remote shutdown στο PC στο Νέο Κόσμο — ξέρετε, για οικονομία στο ρεύμα. (Ομολογουμένως, η αίσθηση που είχαμε περί οικονομίας την εποχή που η κρίση αποτελούσε, στην καλύτερη περίπτωση, θεωρητική κουβεντούλα μεταξύ τυρού και αχλαδίου, ήταν εντελώς διαφορετική από την αίσθηση που έχουμε σήμερα.)

Ως λύση anti-virus για τον παλιό μας mailserver είχαμε το ClamAV, ο οποίος χρησιμοποιείται ακόμη και σήμερα.

Η μετάβαση στο Google Apps συνέβη ομαλά και το email του Defiant είναι έως σήμερα εκεί. Από το 2010 κι έπειτα φιλοξενούνται και τα emails άλλων domains μας στο Google Apps (deltahacker.gr & parabing.com) και, περιττό να σημειώσουμε, είμαστε απόλυτα ευχαριστημένοι. Μετά όμως από τις αποκαλύψεις Snowden, η αλήθεια είναι ότι το μικρόβιο της (σταδιακής) απεξάρτησης από τους μεγάλους cloud providers μάς έχει μολύνει για τα καλά. Εδώ και μήνες, το μόνο που μας κρατούσε από το να στήσουμε ξανά τον δικό μας mailserver, είχε να κάνει με την κρισιμότητα του email ως εφαρμογή: Δεν θέλουμε το παραμικρό downtime για τα emails μας, ειδικά για εκείνα που αφορούν στο deltahacker.gr. Συνυπολογίστε και το φαινόμενο “σκάει η μία δουλειά μετά την άλλη, ο καιρός περνάει και δεν προλαβαίνω ν’ ασχοληθώ με το πρότζεκτ που τόσον καιρό σκέφτομαι”, οπότε καταλαβαίνετε γιατί έχουμε αναγγείλει το θέμα “ο δικός μου mailserver” από το προηγούμενο φθινόπωρο, αλλά μόλις πρόσφατα στρωθήκαμε κι ασχοληθήκαμε…

Ομαλή κι ασφαλής προσέγγιση
Επειδή το downtime του email για τα domains μας δεν αποτελεί επιλογή και ταυτόχρονα δεν μπορούσαμε να καθυστερούμε άλλο το στήσιμο του δικού μας mailserver, αποφασίσαμε τελικά να διατηρήσουμε στο Google Apps τα defiant.gr, deltahacker.gr και parabing.com, αλλά να αποκτήσουμε ένα νέο (φθηνό) domain και να στήσουμε έναν mailserver γι’ αυτό — βεβαίως από την αρχή. Η ιδέα είναι ότι θα χρησιμοποιούμε για αρκετό καιρό αυτόν τον mailserver, όχι όμως για emails που αφορούν στο περιοδικό. Εφόσον είμαστε αρκετά σίγουροι για τη σταθερότητα και την αξιοπιστία του, τότε εξετάζουμε και το σενάριο απαγκίστρωσης των άλλων domains από το Google Apps.

Μετά τόσα χρόνια από την τελευταία φορά που στήσαμε mailserver, δεν θέλαμε να επανέλθουμε στο θέμα ακολουθώντας την οδό του απόλυτου customization. Αποφασίσαμε έτσι να στραφούμε στο Mail-in-a-Box. Ουσιαστικά, πρόκειται για ένα σύνολο από scripts που μετατρέπουν έναν cloud server (ή VPS) σε πλήρη mailserver. Σ’ αυτόν τον mailserver έχουμε πρόσβαση από web (χάρη στο Roundcube) ή από οποιονδήποτε σύγχρονο MUA (μέσω IMAP). Το Mail-in-a-Box εγκαθιστά και ρυθμίζει έναν πλήρη DNS server, με όλες τις απαραίτητες εγγραφές για την υποστήριξη του email για το domain μας. Επιπρόσθετα, υλοποιεί μοντέρνα πρωτόκολλα (SPF, DKIM, DMARC) και πρακτικές ασφαλείας (opportunistic TLS, HSTS), ενώ προαιρετικά υποστηρίζει και το DNSSEC. Βεβαίως, παρέχει μηχανισμούς anti-spam (με το SpamAssassin) και greylisting (με το Postgrey), καθιστά εύκολη την εγκατάσταση πιστοποιητικών SSL (για τον webserver και τον mailserver), ενώ υποστηρίζει και το hosting στατικών web sites.

Είναι περιττό να τονίσουμε ότι η “χειροκίνητη” εγκατάσταση και σωστή ρύθμιση όλων των προαναφερθέντων υπηρεσιών και μηχανισμών ασφαλείας, σημαίνει τρομακτική δουλειά και μεγάλη πιθανότητα να φτάσουμε σε αποτέλεσμα που δεν θα δουλεύει όπως πρέπει. Ευτυχώς, το Mail-in-a-Box διευκολύνει απείρως τη δημιουργία ενός σύγχρονου, ασφαλούς και με πλούσια χαρακτηριστικά mailserver. Αρκετά όμως με τις συζητήσεις — ας πιάσουμε δουλειά!

Στο PC με το Gentoo Linux και τον mailserver μας τρέχαμε το ddclient, το οποίο επικοινωνούσε με την τότε DynDNS προκειμένου να ενημερώνει για αλλαγές στη δημόσια IP που παίρναμε από τον ISP μας. Σήμερα, εξαιτίας του γεγονότος ότι πολλοί οικιακοί υπολογιστές αποστέλλουν SPAM, η λειτουργία mailserver σε PC ή VM στο σπίτι μας είναι, πρακτικά, αδύνατη.

Τι χρειαζόμαστε για τη συνέχεια
Η λίστα με τα απολύτως απαραίτητα για να ξεκινήσουμε, κάθε άλλο παρά μακροσκελής είναι.

  • Χρειαζόμαστε ένα VPS στο cloud. Εξαιτίας του μεγάλου όγκου SPAM που διακινείται από οικιακούς υπολογιστές, είναι πρακτικά αδύνατον να στήσουμε mailserver στο σπίτι. Ακόμη κι αν ο ISP μας δεν μπλοκάρει κάποιο κρίσιμο port, οι οικιακές δημόσιες διευθύνσεις IP θεωρούνται ύποπτες για αποστολή SPAM και συνεπώς ο mailserver μας δεν θ’ αργήσει να καταλήξει σε blacklist. Το VPS λοιπόν είναι μονόδρομος και θα πρέπει να έχει *τουλάχιστον* 768MB RAM. Εμείς φτιάξαμε ένα νέο droplet στη DigitalOcean, συγκεκριμένα το δεύτερο κατά σειρά μεγέθους, με 1GB RAM.

    Σημείωση. Αν δημιουργήσετε το δικό σας droplet στη DigitalOcean ακολουθώντας αυτό το referral URL –> http://bit.ly/digocean10off, τότε κερδίζετε αυτομάτως 10$ σε credit. Πρακτικά, για το droplet με 1GB RAM έχετε τον πρώτο μήνα δωρεάν κι από εκεί και πέρα –αν αποφασίσετε να συνεχίσετε– πληρώνετε 10$ το μήνα.

  • Χρειαζόμαστε βεβαίως ένα domain, το email του οποίου θα εξυπηρετεί το Mail-in-a-Box. Ο registrar θα πρέπει να επιτρέπει τον ορισμό των λεγόμενων glue records ή αλλιώς child nameservers. Πρακτικά, τα glue records υποδηλώνουν ότι o nameserver στο VPS μας γίνεται μέλος του παγκόσμιου domain name system. Ο registrar, εξάλλου, καλό θα ήταν να υποστηρίζει και το DNSSEC. Δεν είναι υποχρεωτικό, αν όμως παρέχεται και ρυθμιστεί τότε η ασφάλεια του box μας αναβαθμίζεται σημαντικά. Ένας registrar που α) υποστηρίζει τον ορισμό glue records, β) υποστηρίζει το DNSSEC, γ) προτείνεται από τον Joshua Tauberer, δημιουργό του Mail-in-a-Box (https://razor.occams.info), είναι το Gandi.net.

    Σημείωση. Προτείνουμε με τη σειρά μας να επιλέξετε ένα οικονομικό domain από το Gandi.net, το οποίο θα υποστηρίζει το DNSSEC (δεν παρέχεται για όλα τα TLDs). Εμείς, π.χ., διαλέξαμε το colder.xyz, το οποίο κοστίζει 2,50 ευρώ ανά έτος. Για το κόστος κάθε TLD που παρέχει το Gandi δείτε το https://www.gandi.net/domain/price/info. Επίσης, στο http://wiki.gandi.net/en/domains/dnssec#who_can_use_dnssec δείτε όλα τα TLDs για τα οποία παρέχεται υποστήριξη DNSSEC από πλευράς Gandi.net.
  • Αν σκοπεύουμε να χρησιμοποιήσουμε στα σοβαρά τον mailserver μας, τότε χρειαζόμαστε κι ένα κανονικό (όχι self-signed) πιστοποιητικό. Μπορούμε να αποκτήσουμε ένα δωρεάν από το http://www.startssl.com ή από το Gandi.net. Σε περίπτωση που πήραμε το domain μας από το Gandi.net, τότε δικαιούμαστε πιστοποιητικό SSL για το domain, δωρεάν για ένα χρόνο. Μετά τον πρώτο χρόνο, το πιστοποιητικό κοστίζει 16$ ανά έτος.

Μπορούμε να ξεκινήσουμε την εργασία μας χωρίς να έχουμε αποκτήσει κάποιο SSL certificate, όμως μετά την εγκατάσταση του Main-in-a-Box προτείνουμε την εγκατάσταση ενός κανονικού, όχι self-signed πιστοποιητικού. Αν δεν το κάνουμε, εκτός από τα warnings περί self-signed certificate (θα τα λαμβάνουμε τόσο από τον browser όσο και από τον όποιο MUA χρησιμοποιούμε), τα email μας ναι μεν θα φτάνουν στον προορισμό τους αλλά κατά πάσα πιθανότητα θα χαρακτηρίζονται ως SPAM.

Ας δούμε τώρα αναλυτικά πώς εγκαθιστούμε και ρυθμίζουμε το Mail-in-a-Box, ξεκινώντας από το VPS. Συνεχίστε με το δεύτερο μέρος του αφιερώματός μας.

5 Responses to “Ο δικός σας mailserver: Το γιατί και το πώς”

  1. ToPnt | 25/05/2015 at 20:07

    Έχουμε κιόλας τα εισαγωγικά; :D :D Τέλεια!! Τα λέτε πάρα πολύ ωραία και αναλυτικά ( όπως πάντα )! :)

    Αν και περιορίζοντας πολύ τις αρχικές ερωτήσεις μου, πιστεύοντας πως είναι νωρίς και ίσος μου λυθούν στην πορεία, έχω τις εξής :

    Το να το στήσει κάποιος στο σπίτι, οι πιθανότητες πλέον να δουλέψει είναι ελάχιστες λόγο της ip ;
    Διότι :

    α) Το ζήτημα με την δυναμική ip ας πούμε πως το λύνουμε με την υπηρεσία no-ip ή αν υπάρχει ακόμη ( υπάρχει ; ) και η υπηρεσία που χρησιμοποιουσατε τότε ( Dyn ).

    β) Ακόμη και αν δεν μπλοκάρετε όπως λέτε κάποια κρίσιμη πόρτα από τον ISP.

    γ) Αλλά λόγο της δυναμικής ip που παίρνουμε από τοn ISP που θεωρούνται ύποπτες ;

    δ) Και αν μπούμε σε blacklists τι γίνεται έπειτα γενικά με το domain μας ( και για web site αν έχουμε, αλλά και για τον mail server ) ;

    ε) Όσο για τον μεγάλο όγκο του SPAM που αναφέρετε πως διακινείται από οικιακούς υπολογιστές και μας περιορίζει τόσο πολύ ( λέγοντας ακόμη και *χάρης αυτού πως είναι αδύνατον να στήσουμε στο σπίτι έναν mailserver* ) τι εννοείται;
    Δεν καταλαβαίνω τον λόγο. :/
    Θα γεμίσει ο σκληρός από spam mails, και γιατί όμως;
    Θα έρχονται ντε και καλά spam emails ;

    β) Πλέων η υπηρεσία που ήταν επί πληρωμή από την DynDNS, η οποία αναλάμβανε να “μαζεύει” τα εισερχόμενα emails για το domain και να τα αποθηκεύει στους servers της εταιρείας υπάρχει;

    Ευχαριστώ πολύ! :)

    Υ.Σ.: Είμαι σίγουρος πως γνωρίζεται ότι περιμένουμε την συνέχεια με πολύ ενθουσιασμό! ;)

  2. panosangel | 26/05/2015 at 12:15

    Πολύ χορταστικό το εισαγωγικό και μπράβο για τον εναλλακτικό τρόπο προσέγγισης του θέματος!

    Εδώ και δύο (2) χρόνια τρέχω τον δικό μου mailserver (Postfix – Dovecot) για καμιά 10αρια domains και ενώ στην αρχή η χαρά της δημιουργίας επισκιάζει το κόπο, σε βάθος χρόνου οι χειροκίνητες ρυθμίσεις, οι ατελείωτες ώρες μελέτης των εγχειριδίων κλπ καταντάει βραχνάς.

    Περιμένουμε την συνέχεια :)

    • subZraw | 26/05/2015 at 12:22

      Α, ναι, είναι major καζίκι η σωστή συντήρηση ενός mailserver — δεν το συζητάμε :) Απόψε ανεβαίνει το 2ο μέρος και μετά βγάζουμε το νέο τεύχος (το 043, σε PDF). Τις επόμενες μέρες ανεβαίνει στο site το 3ο μέρος. Το ίδιο άρθρο θα πάει και στο PDF του επόμενου τεύχους (του 044). Είναι λίγο μεγαλούτσικο για να χωρέσει στο 043.

Leave a Reply

You must be logged in to post a comment.

Σύνδεση

Αρχείο δημοσιεύσεων