Μάθετε πώς ο DSN είχε ως στόχο να εισαγάγει την κατάσταση παράδοσης σε ηλεκτρονικό ταχυδρομείο SMTP.
Έχετε ποτέ αναρωτηθεί τι συνέβη σε ένα μήνυμα ηλεκτρονικού ταχυδρομείου που στείλατε;
Ακόμη και μόνο μια σύντομη ματιά στο πρωτόκολλο SMTP θα σας προσέξει ότι εκτός από το συνηθισμένο HELO, υπάρχει και το EHLO, το οποίο καθιστά το Extended SMTP server να διαφημίζει τις δυνατότητές του πέρα από το αρχικό πρότυπο. Ένα από αυτά είναι το DSN. DSN; Δεν επαρκούν το DNA και το DDT;
Για να υποστηρίξω ότι το ηλεκτρονικό ταχυδρομείο είναι αναξιόπιστο, κάποιος πρέπει να " τροφοδοτεί καλύτερα τον εξυπηρετητή μου, έτρωγε το ταχυδρομείο μου ... " δεν είναι ασυνήθιστο. Το κάνω μόνος μου. Ωστόσο, δεν υπάρχει λόγος να στηρίξουμε αυτές τις υποψίες.
Έλεγχος παράδοσης Η ενημέρωση είναι από το RFC 821 (από το 1982). Μόλις ολοκληρωθεί το τμήμα DATA του πρωτοκόλλου SMTP και ο διακομιστής αποδέχεται το μήνυμα ηλεκτρονικού ταχυδρομείου για την παράδοση, είναι υπεύθυνο γι 'αυτό. Εάν, για οποιονδήποτε λόγο, δεν μπορεί να περάσει στον παραλήπτη, πρέπει να το στείλει πίσω με ειδοποίηση για το σφάλμα στον αρχικό αποστολέα. Αυτό είχε ως αποτέλεσμα κάποια σκοτεινά μηνύματα ηλεκτρονικού ταχυδρομείου .
Εκτός από αυτό, αυτή η παλιά συνέλευση σήμαινε ότι είτε λάβατε ένα μήνυμα σφάλματος είτε δεν πήρατε τίποτα , οπότε δεν γνωρίζατε τίποτα : το μήνυμα ηλεκτρονικού ταχυδρομείου μπορεί να έχει φθάσει ή δεν μπορεί. Τα μηνύματα σφάλματος σε πολλές περιπτώσεις ήταν εξίσου χρήσιμα με τα μηνύματα σφάλματος. Με το ηλεκτρονικό ταχυδρομείο όλο και πιο σημαντικό αυτό δεν είναι πλέον ικανοποιητικό (σαν να ήταν πριν).
DSN επεκτάσεις σε SMTP
Το RFC 1891 προτείνει ορισμένες επεκτάσεις στο πρωτόκολλο SMTP που θα πρέπει να οδηγήσουν σε ένα πιο αξιόπιστο και πιο χρήσιμο σύστημα DSN. Πρόκειται για ένα σύνολο επεκτάσεων στις εντολές MAIL και RCPT (αν αυτό δεν σημαίνει τίποτα για εσάς, διαβάστε πώς λειτουργεί το SMTP και στη συνέχεια επιστρέψτε εδώ).
Δεν EHLO, δεν είναι διασκεδαστικό
Πρώτον, πρέπει να βεβαιωθούμε ότι ο διακομιστής υποστηρίζει το DSN. Έτσι, πρέπει να του πούμε το EHLO και να ακούσουμε προσεκτικά. Αν απαντήσει με το DSN κάπως στη λίστα χαρακτηριστικών, μπορούμε να υποθέσουμε ότι θα είναι σε θέση να εξυπηρετήσει τα αιτήματά μας. Αν όχι, τότε όχι: μπορούμε να δοκιμάσουμε έναν άλλο διακομιστή ή απλά να επιστρέψουμε στο ηλεκτρονικό ταχυδρομείο χωρίς DSN. Για παράδειγμα (η είσοδος μου είναι μπλε, η έξοδος του διακομιστή είναι μαύρη):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Κυρ, 24 Αυγ 1997 18:23:22 +0200
EHLO localhost
250-larose.magnet.at Γεια σας localhost [127.0.0.1], χαρά να σας γνωρίσω
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
Ευτυχώς, μεταξύ άλλων, βρίσκουμε DSN.
Επεκτάσεις αποστολέα DSN
Η επόμενη εντολή είναι συνήθως MAIL FROM :. Με το DSN, αυτό δεν είναι διαφορετικό. Υπάρχουν όμως δύο επιπλέον επιλογές που μπορείτε να εκδώσετε: RET και ENVID.
Η επιλογή RET τοποθετήθηκε μάλλον αυθαίρετα στην εντολή MAIL, αλλά ταιριάζει εδώ καθώς και οπουδήποτε αλλού. Ο σκοπός είναι να καθορίσετε πόσο από το αρχικό σας μήνυμα πρέπει να επιστραφεί σε περίπτωση αποτυχίας παράδοσης. Τα έγκυρα επιχειρήματα είναι FULL και HDRS. Ο πρώτος σημαίνει ότι το πλήρες μήνυμα πρέπει να συμπεριληφθεί στο μήνυμα σφάλματος, το HDRS δίνει εντολή στον διακομιστή να επιστρέψει μόνο τις κεφαλίδες του αποτυχημένου μηνύματος. Εάν δεν έχει οριστεί η RET, εξαρτάται από το διακομιστή τι πρέπει να κάνει. Στις περισσότερες περιπτώσεις, η τιμή HDRS θα είναι η προεπιλεγμένη τιμή.
Το ENVID ανήκει πραγματικά στον αποστολέα όπως αυτή ή (μάλλον) ο πελάτης ηλεκτρονικού ταχυδρομείου της θα είναι ο μόνος που μας κάνει αυτό το αναγνωριστικό φακέλου . Σκοπός του είναι να ενημερώσει τον αποστολέα σχετικά με το ποια ηλεκτρονική αλληλογραφία αντιστοιχεί σε πιθανό μήνυμα σφάλματος. Η μορφή αυτού του αναγνωριστικού βασικά παραμένει στη φαντασία του αποστολέα. Δεν θα χρησιμοποιήσουμε το ENVID στο παράδειγμά μας (φαντασία!):
MAIL FROM: sender@example.com RET = HDRS
250 αποστολέας@example.com ... Ο αποστολέας είναι εντάξει
Προφανώς, θέλουμε μόνο να ανακτήσουμε τις κεφαλίδες στο DSN μας.
Επεκτάσεις παραλήπτη DSN
Το RCPT TO: παίρνει το δίκαιο μερίδιο των επεκτάσεων του: NOTIFY και ORCPT.
Το NOTIFY είναι η πραγματική καρδιά του DSN. Ενημερώνει τον διακομιστή πότε πρέπει να στείλει μια ειδοποίηση κατάστασης παράδοσης. Η πρώτη δυνατή τιμή ΔΕΝ σημαίνει ότι σε καμία περίπτωση δεν θα πρέπει να επιστραφεί ένα DSN στον αποστολέα. Αυτό δεν ήταν εφικτό χωρίς DSN. Στη συνέχεια, υπάρχει το SUCCESS, το οποίο θα σας ειδοποιήσει όταν το ταχυδρομείο σας έχει συμφωνηθεί στον προορισμό του. Το FAILURE είναι το αντίστοιχο του SUCCESS (!): Ένα DSN θα φτάσει αν εμφανιστεί ένας τόνος κατά την παράδοση. Η τελευταία επιλογή είναι DELAY: θα ειδοποιηθείτε εάν υπάρχει μια ασυνήθιστη καθυστέρηση στην παράδοση, αλλά το αποτέλεσμα της πραγματικής παράδοσης (επιτυχία ή αποτυχία) δεν έχει ακόμη αποφασιστεί. ΠΟΤΕ δεν πρέπει να είναι το μόνο επιχείρημα, αν αυτό καθορίζεται, τα άλλα τρία μπορεί να εμφανίζονται σε μια λίστα, που οριοθετείται με κόμμα. Η επιτυχία και η αδυναμία κάνουν μια πολύ δυνατή ομάδα μαζί (!), Που σας λέει σχεδόν (σχεδόν) σε κάθε περίπτωση τι συνέβη με την αλληλογραφία σας.
Ο σκοπός του ORCPT είναι να διατηρήσει τον αρχικό παραλήπτη ενός μηνύματος ηλεκτρονικού ταχυδρομείου, για παράδειγμα αν προωθείται σε άλλη διεύθυνση. Το επιχείρημα αυτής της επιλογής είναι η διεύθυνση ηλεκτρονικού ταχυδρομείου του αρχικού παραλήπτη μαζί με τον τύπο διεύθυνσης. Ο τύπος διεύθυνσης έρχεται πρώτα, ακολουθούμενος από ένα ερωτηματικό και τέλος από τη διεύθυνση. Για παράδειγμα:
RCPT ΣΤΗΝ: support@example.com NOTIFY = FAILURE, DELAY ORCPT = rfc822, support@example.com
250 support@example.com ... Ο παραλήπτης ok (θα βρίσκεται στην ουρά)
Ακολουθούν τα DATA όπως το γνωρίζουμε και τελικά, ελπίζουμε, μια ειδοποίηση σχετικά με την κατάσταση των παραδόσεων που σας ενημερώνει για επιτυχία.
Το DSN λειτουργεί;
Φυσικά, όλη αυτή η ομορφιά και ευφυία θα λειτουργήσει μόνο εάν οι πράκτορες μεταφοράς ταχυδρομείου από τον αποστολέα στον παραλήπτη υποστηρίζουν DSN. Κάποια μέρα θα το κάνουν.