גלה כיצד DSN מכוון להציג את מצב המשלוח לדוא"ל SMTP.
תהית אי פעם מה קרה דוא"ל שנשלח?
אפילו רק מבט קצר על פרוטוקול SMTP יהיה לך לשים לב כי מלבד HELO הרגיל, יש גם EHLO, מה שהופך את שרת ה- SMTP מורחבת לפרסם את היכולות שלה מעבר לתקן המקורי. אחד מהם הוא DSN. DSN? האם DNA ו- DDT אינם מספיקים?
כדי לטעון כי הדוא"ל הוא אמין, כי מישהו צריך " להאכיל את השרת שלהם טוב יותר, הוא אכל את הדואר שלי ... " זה לא נדיר. אני עושה את זה בעצמי. עם זאת, אין הרבה סיבה לתמוך חשדות אלה.
משלוח S tatus n otification כבר בסביבה מאז RFC 821 (משנת 1982). ברגע שחלק DATA של פרוטוקול SMTP הוא סיים את השרת קיבל את הדוא"ל למסירה הוא אחראי על זה. אם, מכל סיבה שהיא, הוא לא יכול להעביר אותו אל הנמען עליו לשלוח אותו בחזרה עם ההודעה על השגיאה לשולח המקורי. זה הביא כמה דוא"ל מעורפל.
חוץ מזה, האמנה הישנה הזאת פירושה שקיבלת הודעת שגיאה או שאין לך כלום ובמקרה זה לא ידעת דבר : ייתכן שהאימייל הגיע או שלא. הודעות השגיאה במקרים רבים היו מועילות באותה מידה כמו הודעות שגיאה. עם הדוא"ל להיות יותר ויותר חשוב זה כבר לא משביע רצון (כאילו זה היה לפני).
הרחבות DSN ל- SMTP
RFC 1891 מציע כמה הרחבות פרוטוקול SMTP כי צריך לגרום למערכת אמין יותר שמיש יותר DSN. זוהי קבוצה של הרחבות לפקודות MAIL ו RCPT (אם זה אומר לך כלום, לקרוא איך SMTP עובד ואז לחזור לכאן.).
לא EHLO, לא כיף
ראשית, עלינו לוודא שהשרת תומך ב- DSN. לכן, אנחנו צריכים לומר EHLO אליו להקשיב היטב. אם הוא מגיב עם DSN someewher ברשימה תכונה אנו יכולים להניח כי הוא יוכל לשרת את הבקשות שלנו. אם לא, אז לא: אנחנו יכולים לנסות שרת אחר או פשוט לחזור אימייל ללא DSN. לדוגמה (הקלט שלי הוא כחול, הפלט של השרת שחור):
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Aug 1997 18:23:22 +0200
EHLO
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 עזרה
למרבה המזל, בין היתר אנו מוצאים DSN.
הרחבות שולח DSN
הפקודה הבאה בדרך כלל היא MAIL FROM :. עם DSN, זה לא שונה. אבל יש שתי אפשרויות נוספות שאתה יכול להנפיק: RET ו ENVID.
האפשרות RET הונחה באופן שרירותי למדי בפקודה MAIL, אבל זה מתאים כאן, כמו גם בכל מקום אחר. המטרה היא לציין כמה ההודעה המקורית שלך צריכה להיות מוחזרת במקרה של כשל משלוח. הארגומנטים החוקיים הם מלאים ו- HDRS. הראשון אומר כי ההודעה המלאה צריכה להיכלל הודעת השגיאה, HDRS מורה לשרת רק להחזיר את הכותרות של הדואר נכשל. אם RET לא צוין, זה תלוי בשרת מה לעשות. ברוב המקרים HDRS יהיה ערך ברירת המחדל.
ENVID באמת שייך השולח כפי שהיא (או) לקוח הדוא"ל שלה יהיה רק אחד שעושה אותנו זה מזהה המעטפה . מטרתו היא לספר את השולח אשר דוא"ל שאולי הוציא הודעת שגיאה מתאימה. הפורמט של תעודת הזהות נשאר בעיקרו לדמיונו של השולח. לא נשתמש ב- ENVID בדוגמה שלנו (דמיון!):
MAIL מאת: sender@example.com RET = HDRS
250 sender@example.com ... אישור השולח
כנראה, אנחנו רק רוצים לקבל את הכותרות בחזרה DSN שלנו.
הרחבות נמען DSN
RCPT TO: מקבל את חלקה ההוגן של הרחבות גם: Notify ו ORCPT.
Notify הוא הלב האמיתי של DSN. הוא יודיע לשרת בעת שליחת הודעת מצב משלוח. הערך הראשון האפשרי הוא לעולם לא אומר שבשום אופן אין להחזיר DSN לשולח. זה לא היה אפשרי ללא DSN. אז יש הצלחה, אשר יודיע לך כאשר הדואר שלך arraved ליעדו. כשל הוא עמיתו של SUCCESS (!): DSN יגיע אם ארור התרחשה במהלך הלידה. האפשרות האחרונה היא DELAY: תקבל הודעה אם יש עיכוב יוצא דופן במשלוח, אך עדיין לא הוחלט על תוצאות המסירה בפועל (הצלחה או כישלון). אף פעם לא צריך להיות הטיעון היחיד אם צוין, שלושת האחרים עשויים להופיע ברשימה, תחומה על ידי פסיק. הצלחה ו כישלון לפצות על צוות חזק למדי ביחד (!), אומר לך (כמעט) בכל מקרה מה קרה לדואר שלך.
מטרת ORCPT היא לשמר את הנמען המקורי של הודעת דואר אלקטרוני, לדוגמה אם היא מועברת לכתובת אחרת. הוויכוח לאפשרות זו הוא כתובת האימייל של הנמען המקורי יחד עם סוג הכתובת. סוג הכתובת מגיע ראשון, ואחריו נקודה פסיק ולבסוף הכתובת. לדוגמה:
RCPT אל: support@example.com NotIFY = כשל, עיכוב ORCPT = rfc822; support@example.com
250 support@example.com ... מקבל אישור (יהיה תור)
זה ואחריו הנתונים כפי שאנו מכירים אותו, ובסופו של דבר, אני מקווה, הודעת מצב המשלוח להודיע לך על הצלחה.
האם עובד DSN?
כמובן, כל היופי הזה שנינות יעבוד רק אם סוכני הובלה בדואר משולח לתמיכה הנמען DSN. יום אחד הם יעשו זאת.