Aliases, ανακατεύθυνση και catch-all: χρήσιμα, αλλά με κινδύνους

Ενότητα 3: Διαχείριση του mailbox σας · Χρόνος ανάγνωσης: 11 λεπτά

Στόχος μαθήματος: Μετά από αυτό το μάθημα θα μπορείτε να επιλέγετε ανάμεσα σε mailbox, alias, forwarder (ανακατεύθυνση) και catch-all, και να εξηγείτε γιατί η ανακατεύθυνση προς εξωτερική διεύθυνση και το catch-all μπορούν να βλάψουν την παράδοση της αλληλογραφίας σας.

Κεντρικές έννοιες: mailbox, alias, forwarder (ανακατεύθυνση), εσωτερική και εξωτερική ανακατεύθυνση, το SPF «σπάει» με την ανακατεύθυνση, SRS (Sender Rewriting Scheme), DKIM σε περίπτωση ανακατεύθυνσης, ARC (RFC 8617), catch-all, dictionary attack, backscatter, αποστολή εκ μέρους άλλης διεύθυνσης

Τέσσερις τρόποι για να λειτουργήσει μια διεύθυνση

Αν θέλετε να λειτουργήσει η διεύθυνση offerte@example.com, έχετε τέσσερις επιλογές:

Σε ορισμένα πάνελ, ένα alias είναι τεχνικά το ίδιο με έναν forwarder προς διεύθυνση στον ίδιο server. Η διαφορά που έχει σημασία είναι η εξής: παραμένει η αλληλογραφία στον ίδιο server, ή φεύγει προς τα έξω;

Ανακατεύθυνση εντός του δικού σας domain: κανένα πρόβλημα

Αν ανακατευθύνετε το offerte@example.com προς το info@example.com, και τα δύο βρίσκονται στον ίδιο server, τότε ο server απλώς παραδίδει την αλληλογραφία στο mailbox του info@. Τίποτα δεν περνά μέσα από το internet, τίποτα δεν ελέγχεται εκ νέου. Αυτό είναι ασφαλές και αξιόπιστο.

Ανακατεύθυνση προς τα έξω: εκεί που τα πράγματα πάνε στραβά

Διαφορετικά είναι τα πράγματα όταν ανακατευθύνετε προς διεύθυνση σε άλλον πάροχο, για παράδειγμα μια προσωπική διεύθυνση στο Gmail ή στο Outlook.com. Τότε ο server σας στέλνει ξανά την αλληλογραφία, τώρα προς το Gmail. Και το Gmail ελέγχει την αλληλογραφία σαν να προέρχεται από τον δικό σας server.

Ας υποθέσουμε ότι ο klant@example.net στέλνει μήνυμα στο info@example.com. Ο server σας το ανακατευθύνει προς το Gmail. Τι βλέπει το Gmail;

• Αποστολέας (From): klant@example.net.
• Envelope-αποστολέας: ακόμα klant@example.net, εκτός αν ο server σας τον ξαναγράψει.
• Server αποστολής: ο δικός σας server, για παράδειγμα 192.0.2.25.

Το Gmail κοιτάζει στην εγγραφή SPF του example.net. Εκεί, φυσικά, ο server σας δεν αναφέρεται. Το SPF αποτυγχάνει. Αν το example.net έχει πολιτική DMARC p=reject, και η αλληλογραφία δεν φέρει έγκυρη υπογραφή DKIM, τότε το Gmail απορρίπτει το μήνυμα. Ο server σας λαμβάνει μια bounce, η οποία πηγαίνει στον... αρχικό αποστολέα, ο οποίος τώρα λαμβάνει μήνυμα σφάλματος από τον δικό σας server.

Υπάρχουν τρεις μηχανισμοί που μετριάζουν αυτό το πρόβλημα:

1. Το DKIM επιβιώνει (συνήθως)

Μια υπογραφή DKIM (μάθημα 4.3) βρίσκεται μέσα στο ίδιο το μήνυμα. Αν ο server σας ανακατευθύνει την αλληλογραφία αμετάβλητη, η υπογραφή του example.net εξακολουθεί να είναι σωστή. Το DMARC περνά τότε μέσω DKIM, ακόμα κι αν το SPF αποτύχει. Γι' αυτό το DKIM είναι τόσο σημαντικό: είναι το μόνο που επιβιώνει στην ανακατεύθυνση.

Αλλά τα πράγματα πάνε στραβά αν ο server που κάνει την ανακατεύθυνση αλλάξει το μήνυμα: προσθέτοντας κείμενο στο τέλος («ανακατευθύνθηκε από...»), τροποποιώντας το θέμα ([SPAM] μπροστά), ή μετατρέποντας τη μορφοποίηση. Τότε η υπογραφή δεν ταιριάζει πλέον.

2. Το SRS ξαναγράφει τον envelope-αποστολέα

Με το SRS (Sender Rewriting Scheme), ο server που κάνει την ανακατεύθυνση αλλάζει τον envelope-αποστολέα σε διεύθυνση στο δικό του domain, για παράδειγμα:

SRS0=HHH=TT=example.net=klant@example.com

Τώρα το Gmail κοιτάζει στην εγγραφή SPF του example.com, και εκεί ο server σας πράγματι αναφέρεται. Το SPF περνά. Αν προκύψει bounce, ο server σας μπορεί να μεταφράσει ξανά τη διεύθυνση και να στείλει το bounce στον πραγματικό αποστολέα.

Προσοχή: το SRS λύνει το ζήτημα του SPF, αλλά όχι του DMARC. Η ευθυγράμμιση (μάθημα 4.4) συγκρίνει το domain του envelope-αποστολέα με τη διεύθυνση From. Τώρα είναι example.com έναντι example.net: δεν υπάρχει ευθυγράμμιση. Το DMARC πρέπει επομένως να εξακολουθεί να περνάει μέσω DKIM.

3. ARC: μια δήλωση του ενδιάμεσου

Το ARC (Authenticated Received Chain, RFC 8617, πειραματικό) επιτρέπει σε έναν ενδιάμεσο να καταγράφει τι είδε: «όταν αυτό το μήνυμα έφτασε σε εμένα, το SPF, το DKIM και το DMARC πέρασαν». Ο server που κάνει την ανακατεύθυνση υπογράφει αυτή τη δήλωση. Ο τελικός παραλήπτης μπορεί να αποφασίσει να εμπιστευτεί αυτή τη δήλωση αν εμπιστεύεται τον ενδιάμεσο. Μεγάλοι πάροχοι όπως το Gmail και η Microsoft χρησιμοποιούν το ARC, αλλά δεν μπορείτε να βασιστείτε σε αυτό: είναι μια χάρη, όχι ένα δικαίωμα.

Και το spam;

Υπάρχει ακόμα ένα πρόβλημα, και είναι συχνά το μεγαλύτερο. Το φίλτρο spam σας δεν σταματά τα πάντα. Όλο το spam που περνάει, ο server σας τώρα το ανακατευθύνει προς το Gmail. Για το Gmail, φαίνεται σαν να στέλνει spam ο δικός σας server. Αυτό πλήττει τη φήμη του server σας (και σε περίπτωση κοινόχρηστου hosting: τη φήμη όλων των πελατών σε αυτόν τον server). Στη συνέχεια, το Gmail στέλνει πιο εύκολα και την πραγματική σας αλληλογραφία στα spam.

Τι είναι καλύτερο;

Θέλετε να διαβάζετε την επαγγελματική σας αλληλογραφία στην εφαρμογή Gmail ή Outlook; Προσθέστε το mailbox ως λογαριασμό IMAP (ενότητα 2). Η εφαρμογή ανακτά την αλληλογραφία απευθείας από τον server σας. Τίποτα δεν ανακατευθύνεται, τίποτα δεν αποτυγχάνει, και δεν φεύγει spam προς τα έξω. Αν πρέπει οπωσδήποτε να κάνετε ανακατεύθυνση, ρυθμίστε το φίλτρο spam αυστηρά πριν από την ανακατεύθυνση.

Catch-all: γιατί σχεδόν ποτέ

Ένα catch-all πιάνει όλη την αλληλογραφία προς διευθύνσεις που δεν υπάρχουν. Ένα τυπογραφικό λάθος όπως inof@example.com φτάνει τότε ούτως ή άλλως. Αυτό ακούγεται χρήσιμο, αλλά:

• Spam. Οι spammers στέλνουν μαζικά μηνύματα σε επινοημένες διευθύνσεις σε υπαρκτά domains (a.jansen@, sales2@, xkq7@). Αυτό ονομάζεται dictionary attack. Χωρίς catch-all, ο server σας απορρίπτει όλα αυτά αμέσως. Με catch-all, όλα φτάνουν, συχνά εκατοντάδες την ημέρα.
• Καμία ειδοποίηση σφάλματος πλέον. Όποιος κάνει λάθος στη διεύθυνσή σας δεν λαμβάνει bounce και νομίζει ότι το μήνυμά του έφτασε. Χωρίς catch-all, γνωρίζει αμέσως ότι η διεύθυνση είναι λανθασμένη.
• Η ανακατεύθυνση το χειροτερεύει. Ένα catch-all που ανακατευθύνει προς το Gmail στέλνει όλο αυτό το spam στο Gmail.
• Backscatter. Ένας server που αρχικά δέχεται τα πάντα και μόνο αργότερα ανακαλύπτει ότι μια διεύθυνση δεν υπάρχει, στέλνει bounce στον (πλαστογραφημένο) αποστολέα. Αυτό ονομάζεται backscatter: μηνύματα σφάλματος σε αθώους ανθρώπους, και λόγος για να καταλήξετε σε blocklist.

Θέλετε να πιάνετε μερικές επιπλέον διευθύνσεις, όπως ένα συχνό τυπογραφικό λάθος ή μια παλιά διεύθυνση; Δημιουργήστε γι' αυτό ξεχωριστά aliases ή forwarders. Χρησιμοποιείτε ξεχωριστή διεύθυνση ανά ιστότοπο ή κατάστημα (webshop-x@), για να δείτε ποιος μεταπωλεί τη διεύθυνσή σας; Δημιουργήστε αυτή τη διεύθυνση ως alias τη στιγμή που τη χρησιμοποιείτε.

Αποστολή από ένα alias

Ένα alias μπορεί επίσης να λειτουργήσει ως αποστολέας. Θέλετε για παράδειγμα να απαντάτε ως offerte@example.com ενώ είστε συνδεδεμένοι ως info@. Αυτό είναι δυνατό, αλλά:

• Πολλοί mail servers ελέγχουν πλέον ποια διεύθυνση αποστολέα αντιστοιχεί σε ποιον λογαριασμό σύνδεσης. Επιτρέπεται τότε να στέλνετε μόνο από τη δική σας διεύθυνση και τα aliases ή forwarders που δείχνουν προς το mailbox σας. Μια τυχαία άλλη διεύθυνση απορρίπτεται («account can not send emails from ...»). Αυτό προστατεύει από κατάχρηση.
• Στο πρόγραμμα email σας προσθέτετε το alias ως επιπλέον ταυτότητα (Thunderbird: Διαχείριση ταυτοτήτων· Apple Mail: επιπλέον διευθύνσεις στον λογαριασμό, χωρισμένες με κόμματα· Outlook: εμφάνιση του πεδίου Από και πληκτρολόγηση της διεύθυνσης).
• Το SPF, το DKIM και το DMARC λειτουργούν κανονικά, εφόσον το alias βρίσκεται στο ίδιο domain και στέλνετε μέσω του δικού σας server.

Στην πράξη: έτσι φαίνεται σε ένα πάνελ

Στο DirectAdmin δημιουργείτε ανακατευθύνσεις στο E-mail Manager, Forwarders. Το catch-all βρίσκεται στο Advanced Features, Catch-All E-mail· εκεί η επιλογή «απενεργοποίηση catch-all» είναι η συνιστώμενη ρύθμιση (η αλληλογραφία προς μη υπαρκτές διευθύνσεις απορρίπτεται). Αν έχετε μόνο ένα domain name χωρίς πακέτο, οι ανακατευθύνσεις βρίσκονται στο Το WebOké μου, στο Τα domains μου, Ανακατευθύνσεις. Άλλα πάνελ (cPanel, Plesk, Microsoft 365, Google Workspace) έχουν παρόμοια τμήματα, μερικές φορές με ονόματα όπως «aliases», «ανακατεύθυνση» ή «ομάδες».

Σύνοψη

• Ένα alias ή μια ανακατεύθυνση εντός του ίδιου server είναι ασφαλές.
• Η ανακατεύθυνση προς τα έξω «σπάει» το SPF. Το SRS αποκαθιστά το SPF, αλλά όχι την ευθυγράμμιση DMARC· μόνο μια ανέπαφη υπογραφή DKIM σώζει το μήνυμα, και το ARC μπορεί να βοηθήσει.
• Το ανακατευθυνόμενο spam βλάπτει τη φήμη του server σας. Διαβάζετε την εξωτερική αλληλογραφία καλύτερα μέσω IMAP στην εφαρμογή.
• Ένα catch-all προσελκύει spam, κρύβει τυπογραφικά λάθη και μπορεί να προκαλέσει backscatter. Χρησιμοποιήστε ξεχωριστά aliases.
• Η αποστολή από alias είναι δυνατή, εντός των κανόνων του server σας.

Κουίζ

Άσκηση

Άσκηση O3.3: Απογραφή των διευθύνσεών σας. Φτιάξτε μια λίστα με όλες τις διευθύνσεις στο domain σας: mailboxes, aliases, ανακατευθύνσεις και αν είναι ενεργοποιημένο κάποιο catch-all. Σημειώστε για κάθε ανακατεύθυνση αν παραμένει εντός του δικού σας domain ή πηγαίνει προς τα έξω (Gmail, Outlook.com, άλλη εταιρεία). Απαντήστε στη συνέχεια: ποια εξωτερική ανακατεύθυνση μπορείτε να αντικαταστήσετε με λογαριασμό IMAP στην εφαρμογή, και υπάρχει ενεργό catch-all που μπορεί να απενεργοποιηθεί; Συμπληρώστε τη λίστα ελέγχου.

Για περαιτέρω μελέτη

Τα βήματα σε αυτά τα άρθρα ισχύουν για τα πάνελ του WebOké· σε άλλους παρόχους λειτουργεί με παρόμοιο τρόπο.

• Εγχειρίδιο DirectAdmin 7.5: Forwarders: προώθηση αλληλογραφίας σε άλλη διεύθυνση
• Εγχειρίδιο DirectAdmin 7.6: Catch-All E-mail: mail σε ανύπαρκτες διευθύνσεις
• Προώθηση email σε άλλη διεύθυνση (forwarders, το catch-all δεν συνιστάται)
• Αποστολή email από πολλά aliases, σφάλμα: Account xxx can not send emails from
• Εγχειρίδιο WebOké 5.9: Προωθήσεις email και domain
• Δωρεάν μάθημα DNS 4.3: SPF: ποιος επιτρέπεται να στέλνει email εκ μέρους του domain σας;
• RFC 8617 (ARC), RFC 7208 παράρτημα D (SPF και ενδιάμεσοι όπως οι ανακατευθυντές)