ببینید که چگونه DSN با هدف ارائه وضعیت تحویل به ایمیل SMTP.
همیشه می دانستید چه اتفاقی برای ایمیل فرستاده شده است؟
حتی فقط یک نگاه مختصر در پروتکل SMTP خواهد شد که شما متوجه است که علاوه بر HELO معمول است، نیز وجود دارد EHLO، که باعث می شود سرور SMTP تمدید تبلیغ توانایی های خود را فراتر از استاندارد اصلی است. یکی از این ها DSN است. DSN؟ آیا DNA و DDT کافی نیست؟
استدلال می کند که ایمیل غیر قابل اعتماد است، و آن این است که کسی باید " ... سرور خود را بهتر کند؛ من ایمیلم را خوردم ... " غیر معمول نیست. خودم انجامش می دهم. با این وجود، دلیل زیادی برای حمایت از این سوء ظنها وجود ندارد.
تحویل S tatus N otification شده است در حدود از RFC 821 (از سال 1982). به محض اینکه بخش DATA پروتکل SMTP به پایان رسید و سرور ایمیل را برای تحویل پذیرفته است، مسئول آن است. اگر، به هر دلیلی، آن را نمی توان آن را از طریق به گیرنده، آن را باید با اخطار خطا به فرستنده اصلی ارسال کنید. این باعث شد تا برخی از ایمیل های مبهم
به غیر از این، این کنوانسیون قدیمی به این معنی است که یا پیام خطایی را دریافت کردید یا چیزی نداشتید که در آن صورت شما هیچ چیز را نمی دانستید: ایمیل ممکن است وارد شود یا ممکن است. پیام های خطا در بسیاری از موارد به همان اندازه پیام های خطا مفید بود. با ایمیل بیشتر و بیشتر مهم است این دیگر رضایت بخش نیست (همانطور که قبلا بود).
DSN Extensions به SMTP
RFC 1891 برخی از فرمت ها را به پروتکل SMTP پیشنهاد می کند که باید یک سیستم DSN قابل اعتماد تر و قابل استفاده تر باشد. این مجموعه ای از پسوند به ایمیل است و دستورات 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 Hello localhost [127.0.0.1]، خوشحالم که با شما ملاقات می کنم
250 تا EXPN
250 VERB
250-8BITMIME
250 سایز
250-DSN
250 اونکس
250-ETRN
250 XUSR
250 کمک
خوشبختانه، در میان چیزهای دیگر ما DSN را پیدا کنید.
Extensions فرستنده DSN
دستور زیر معمولا از MAIL FROM :. با DSN، این متفاوت نیست اما دو گزینه اضافی وجود دارد که شما می توانید انجام دهید: RET و ENVID.
گزینه RET به صورت خودسرانه در دستور MAIL قرار گرفت، اما در اینجا و همچنین در جای دیگری جای دارد. هدف این است که مشخص کنید که چه مقدار از پیام اصلی شما باید در صورت خرابی تحویل داده شود. استدلال معتبر FULL و HDRS است. اولی بدین معنی است که پیام کامل باید در پیام خطا گنجانده شود، HDRS دستور می دهد که سرور فقط هدر ایمیل ناموفق را بازگرداند. اگر RET مشخص نشده باشد، سرور باید چه کاری انجام دهد. در اغلب موارد HDRS مقدار پیش فرض خواهد بود.
ENVID واقعا به فرستنده تعلق دارد به عنوان او (یا نه) مشتری ایمیل او تنها کسی است که ما را از این شناسه پاکت می سازد. هدف آن این است که به فرستنده بگویید که ایمیل یک پیام خطا احتمالا منتشر شده مربوط به آن است. فرمت این شناسه اساسا به تصور فرستنده منتهی میشود. ما ENVID را در مثال ما (تخیل!) استفاده نمی کنیم:
نامه از: sender@example.com RET = HDRS
250 sender@example.com ... فرستنده خوب است
ظاهرا، ما فقط می خواهیم هدر ها را در DSN خودمان دریافت کنیم.
افزونههای گیرنده DSN
RCPT TO: سهم عادلانه خود را از پسوندها نیز به دست می دهد: NOTIFY و ORCPT.
اطلاع رسانی قلب واقعی DSN است. هنگامی که یک آگاه شدن از وضعیت تحویل ارسال می شود سرور به سرور می گوید. اولین مقدار ممکن است هیچ وقت نیست که بدان معنی است که هیچ یک از DSN ها باید به فرستنده ارسال شود. این بدون DSN ممکن نبود پس از آن، SUCCESS وجود دارد، که هنگام ارسال نامه شما در مقصد مقصد شما را مطلع خواهد کرد. FAILURE SUCCESS counterpart (!): یک DSN در صورت وقوع زلزله در هنگام تحویل، وارد می شود. آخرین گزینه DELAY است: شما اطلاع داده خواهد شد در صورتی که تاخیر غیر معمول در تحویل وجود دارد، اما نتیجه تحویل واقعی است (موفقیت یا شکست) هنوز تصمیم نگرفته است. هرگز نباید تنها استدلال باشد اگر آن مشخص شده باشد، سه نفر دیگر ممکن است در یک لیست نمایش داده شوند که توسط کاما مشخص شده اند. SUCCESS و FAILURE برای یک تیم بسیار قوی با هم (!)، تقریبا هر موردی را که به ایمیل شما اتفاق افتاده است را تشکیل می دهد.
هدف ORCPT این است که گیرنده اصلی یک پیام ایمیل را حفظ کند، مثلا اگر آن را به آدرس دیگری ارسال کنید. استدلال این گزینه، آدرس ایمیل گیرنده اصلی همراه با نوع آدرس است. نوع آدرس می آید ابتدا، به دنبال یک نقطه عطفی و در نهایت آدرس. مثلا:
RCPT TO: support@example.com NOTIFY = FAILURE، DELAY ORCPT = rfc822؛ support@example.com
250 support@example.com ... گیرنده خوب (خواهد شد صف)
این به دنبال DATA همانطور که ما آن را می دانیم و در نهایت، امیدواریم، اعلامیه وضعیت تحویل به شما اطلاع از موفقیت.
آیا DSN کار می کند؟
البته، تمام این زیبایی و شوخطبک تنها در صورتی کار خواهد کرد که عوامل حمل و نقل ایمیل از فرستنده به گیرنده پشتیبانی DSN. یک روز آنها خواهند شد.