אפילו רק מבט קצר על פרוטוקול SMTP יהיה לך לשים לב כי מלבד HEL הרגיל, יש גם EHLO, מה שהופך את מורחב שרת ה- SMTP מפרסם את יכולותיו מעבר לתקן המקורי. אחד מהם הוא DSN. DSN? האם DNA ו- DDT אינם מספיקים?
לטעון כי הדוא"ל הוא אמין, כי מישהו צריך " … להאכיל את השרת שלהם טוב יותר; הוא אכל את הדואר שלי … "אין זה נדיר, אך אין הרבה סיבה לתמוך בחשדות אלה.
משלוח S tatus N otification כבר סביב מאז RFC 821 (משנת 1982). ברגע שחלק DATA של פרוטוקול SMTP הוא סיים את השרת קיבל את הדוא"ל למסירה הוא אחראי על זה. אם מסיבה כלשהי זה לא יכול לקבל את זה דרך הנמען הוא חייב לשלוח אותו בחזרה עם ההודעה על השגיאה לשולח המקורי. זה הביא כמה דוא"ל מעורפל.
חוץ מזה, זה הכנס הישן התכוון כי יש לך הודעת שגיאה או שיש לך שום דבר ובמקרה זה ידעת שום דבר : ייתכן שהאימייל הגיע או לא. הודעות השגיאה במקרים רבים היו מועילות באותה מידה כמו הודעות שגיאה. עם הדוא"ל להיות יותר ויותר חשוב זה כבר לא משביע רצון (כאילו זה היה לפני).
הרחבות DSN ל- SMTP
RFC 1891 מציע כמה הרחבות פרוטוקול SMTP כי צריך לגרום למערכת אמין יותר שמיש יותר DSN. זוהי קבוצה של הרחבות לפקודות MAIL ו RCPT.
לא EHLO, לא כיף
ראשית, עלינו לוודא שהשרת תומך ב- DSN. לכן, אנחנו צריכים לומר EHLO אליו להקשיב היטב. אם הוא מגיב עם DSN איפשהו ברשימה תכונה אנו יכולים להניח כי היא תוכל לשרת את הבקשות שלנו. אם לא, אז לא: אנחנו יכולים לנסות שרת אחר או פשוט לחזור אימייל ללא DSN. לדוגמה:
220 larose.magnet.at ESMTP Sendmail 8.8.6 / 8.8.6; Sun, 24 Aug 1997 18:23:22 +0200EHLO250-larose.magnet.at שלום localhost 127.0.0.1, שמח לפגוש אותך250-EXPN250-VERB250-8BITMIME250-SIZE250-DSN250-ONEX250-ETRN250-XUSR250 עזרה למרבה המזל, בין היתר אנו מוצאים DSN. הפקודה הבאה בדרך כלל היא MAIL FROM. עם DSN, זה לא שונה. אבל יש שתי אפשרויות נוספות שאתה יכול להנפיק: RET ו ENVID. האפשרות RET הונחה באופן שרירותי למדי בפקודה MAIL, אבל זה מתאים כאן, כמו גם בכל מקום אחר. המטרה היא לציין כמה ההודעה המקורית שלך צריכה להיות מוחזרת במקרה של כשל משלוח. הארגומנטים החוקיים הם מלאים ו- HDRS. הראשון אומר כי ההודעה המלאה צריכה להיכלל הודעת השגיאה, HDRS מורה לשרת רק להחזיר את הכותרות של הדואר נכשל. אם RET לא צוין, זה תלוי בשרת מה לעשות. ברוב המקרים, HDRS יהיה ערך ברירת המחדל. ENVID באמת שייך השולח כפי שהיא (או) לקוח הדוא"ל שלה יהיה רק אחד שעושה שימוש זה מזהה המעטפה . מטרתו היא לספר את השולח אשר דוא"ל שאולי הוציא הודעת שגיאה מתאימה. הפורמט של תעודת הזהות נשאר בעיקרו לדמיונו של השולח. לא נשתמש ב- ENVID בדוגמה שלנו: MAIL מאת: [email protected] RET = HDRS250 [email protected] … אישור השולח כנראה, אנחנו רק רוצים לקבל את הכותרות בחזרה DSN שלנו. RCPT TO: מקבל את חלקה ההוגן של הרחבות גם: Notify ו ORCPT. Notify הוא הלב האמיתי של DSN. הוא מספר את השרת מתי כדי לשלוח הודעת מצב משלוח. הערך הראשון האפשרי הוא לעולם לא אומר שבשום אופן אין להחזיר DSN לשולח. זה לא היה אפשרי ללא DSN. אז יש הצלחה, אשר יודיע לך כאשר הדואר שלך הגיע ליעדה. כשל הוא עמיתו של SUCCESS: DSN יגיע אם אירעה שגיאה במהלך המשלוח. האפשרות האחרונה היא DELAY: תקבל הודעה אם יש עיכוב יוצא דופן במשלוח, אך עדיין לא הוחלט על תוצאות המסירה בפועל (הצלחה או כישלון). לעולם לא צריך להיות הטיעון היחיד אם צוין, שלושת האחרים עשויים להופיע ברשימה, תחומה על ידי פסיק. הצלחה כישלון לפצות על צוות חזק למדי ביחד, אומר לך (כמעט) בכל מקרה מה קרה לדואר שלך. מטרת ORCPT היא לשמר את המקורי מקבל הודעת דואר אלקטרוני, לדוגמה, אם היא מועברת לכתובת אחרת. הוויכוח לאפשרות זו הוא כתובת האימייל של הנמען המקורי יחד עם סוג הכתובת. סוג הכתובת מגיע ראשון, ואחריו נקודה פסיק ולבסוף הכתובת. לדוגמה: RCPT אל: [email protected] NotIFY = כשל, עיכוב ORCPT = rfc822; [email protected]250 [email protected] … מקבל אישור (יהיה תור) זה ואחריו הנתונים כפי שאנו מכירים אותו, ובסופו של דבר, אני מקווה, הודעת מצב המשלוח להודיע לך על הצלחה. כמובן, כל היופי הזה וזה יעבוד רק אם סוכני הובלה בדואר משולח לתמיכה הנמען DSN. יום אחד הם יעשו זאת. הרחבות שולח DSN
הרחבות נמען DSN
האם עובד DSN?
