استاندارد RFC 822

استاندارد RFC 822: تبیین قالب یک نامه ساده الکترونیکی

در این استاندارد یک نامۀ الکترونیکی به‌صورت زیر سازماندهی می‌شود:

• • تعدادی فیلد مشخص و تعریف شده که برای عملیات انتقال‌نامه لازم است. این قسمت سرآیند نامه را تشکیل می‌دهد. (این فیلدها متنی هستند)
  • یک سطر خالی (به‌عنوان مرز قسمت سرآیند و بدنۀ نامه)
  • بدنه پیام (شامل متن اصلی نامه)

  فیلدهایی که در سرآیند نامه قرار می‌گیرند (و بعضی الزامی و برخی دیگر اختیاری هستند) دقت کنید که ترتیب کوچک و بزرگ‌بودن حروف هر فیلد برای سرویس‌دهنده‌های پست الکترونیکی مهم است و باید دقیقاً به‌گونه‌ای باشد که در جدول درج شده است؛ هر گونه تغییر در آن ممکن است منجر به بروز خطا شود.

  فیلدهای جدول (1-9) را جداگانه توضیح توضیح می دهیم. ذکر این نکته ضروری است که هر فیلد باید در یک سطر مجزا قرار بگیرد و نباید بین آنها سطر خالی وجود داشته باشند.

  فیلد To در جلوی این فیلد (البته پس از یک فاصلۀ خالی) آدرس شخص گیرندۀ نامه قرار می‌گیرد؛ مثلاً

جدول (1-9)    فیلدهای سرآیند در استاندارد RFC 822

همان‌گونه که در مبحث سیستم DNS اشاره شد، قسمت سمت راست آدرس پست الکترونیکی (یعنی پس از علامت @) نام ماشین سرویس‌دهنده پست الکترونیکی است که باید به آدرس IP ترجمه شود و سمت چپ آن نام فردی قرار می‌گیرد که به‌عنوان یک مشترک بر روی آن ماشین تعریف شده و باید نامه دریافت نماید.

• فیلد Cc : در جلوی این فیلد آدرس پست الکترونیکی شخص دیگری درج می‌شود که باید رونوشتی از این نامه را دریافت نماید.
• فیلد Bcc : این فیلد دقیقاً همانند قبلی است با این قدرت که گیرندگان نامه از این موضوع که شخص دیگری این نامه را دریافت کرده مطلع نخواهند شد چرا که در مقصد محتوای این فیلد نشان داده نمی‌شود. دقت کنید که هیچ تفاوتی بین نامه‌ای که هر یک از گیرندگان دریافت می‌کنند وجود نخواهد داشت؛ یعنی اگر جای آدرس‌ها در فیلد To و فیلد  Bcc (یا CC) عوض شوند اتفاق خاصی نخواهد افتاد.
• فیلد From : در جلوی این فیلد آدرس پست الکترونیکی نویسنده و صاحب اصلی نامه درج می‌شود.
• فیلد Sender : جلوی این فیلد آدرس پست الکترونیکی کسی که حقیقتاً نامه را ارسال کرده استقرار می‌گیرد. به‌عنوان‌مثال فرض کنید رئیس یک شرکت به منشی خود دستور می‌دهد نامه‌ای را برای یک مؤسسه نوشته و ارسال نماید؛ بنابراین باید در فیلد From   آدرس رئیس شرکت و در جلوی فیلد: Sender آدرس پست الکترونیکی منشی شرکت قرار بگیرد اگر نویسنده اصلی نامه و ارسال‌کننده آن هر دو یکی باشند نیازی به فیلد Sender نخواهد بود.
• فیلد Received : گاهی بین سیستم پست الکترونیکی فرستندۀ نامه و سیستم گیرندۀ نامه، سرویس‌دهنده‌های دیگری به‌عنوان واسطه‌های انتقال وجود دارد. این نمایندگی‌ها پس دریافت نامه، سطری حاوی فیلد Received هویّت و آدرس خود، ساعت و تاریخ دریافت پیام و هر گونه اطلاعاتی که می‌تواند برای ردیابی مسیر مفید باشد به آن اضافه می‌نمایند. برای مثال فرض کنید یک دانشگاه دارای سیستم پست الکترونیکی است که تمام نامه‌ها را دریافت و بین سرویس‌دهنده‌های پست الکترونیکی در هر دانشکده توزیع می‌کند، سرویس‌دهنده کل دانشگاه که با دنیای خارج در ارتباط است به‌عنوان واسطه انتقال شناخته می‌شود.
• فیلد Return-path : آخرین واسطۀ انتقال این فیلد را به نامه اضافه می‌نماید و مشخص می‌کند که پاسخ‌نامه چگونه باید به فرستندۀ آن برگردد از لحاظ تئوری این اطلاعات را می‌توان از فیلد: Received  استخراج کرد.

به‌غیراز فیلدهایی که توضیح داده شد فیلدهای اضافی دیگری هم وجود دارد که توسط سیستم انتقال استفاده و پردازش نمی‌شود؛ بلکه فقط برای اطلاع شخص خوانندۀ نامه یا برنامه‌ای که کاربر برای خواندن نامه‌اش از آن استفاده می‌کند مفید خواهد بود و وجود و عدم وجود آنها مهم نیست. این فیلدها در جدول (2-9) معرفی   شده اندکه در ادامه انها را معرفی می کنیم.

جدول (2-9)                 فیلدهای اختیاری در استاندارد RFC 822

• فیلد Date: در جلوی این فیلد تاریخ و زمان ارسال نامه قرار می‌گیرد. معمولاً تاریخ و زمان بر حسب ساعت گرینویچ (GMT) درج می‌شود.
• فیلد Replay-To : این فیلد زمانی بکار می‌رود که نویسنده اصلی نامه تمایلی به دریافت پاسخ آن نامه نداشته باشد بلکه بخواهد پاسخ‌نامه ارسالی توسط شخص ثالثی در یافت شود. عنوان مثال مدیر بازاریابی یک شرکت برای مشتریان خود نامه‌ای را تنظیم کرده و منشی او آن را ارسال می‌نماید. پاسخ‌نامه‌های ارسالی باید به مدیر فروش شرکت ارجاع داده شود؛ بنابراین در جلوی فیلد Replay-To آدرس مدیر فروش درج می‌شود.
• فیلد Massage Id : در جلوی این فیلد یک شمارۀ منحصربه‌فرد و اختیاری قرار می‌گیرد که بتوان برای نامه‌های پیرو که بعداً ارسال می‌شود به آن استناد کرد. (دقیقاً مثل شماره نامه‌های اداری)
• فیلد In-Replay-To : در جلوی این فیلد شماره نامه‌ای قرار می‌گیرد که نامه فعلی در پاسخ به آن ارسال شده است.
• فیلد References : در جلوی این فیلد شماره نامه‌های دیگری قرار می‌گیرد که نامه فعلی به موضوع آن نامه‌ها مرتبط است.
• فیلد Keywords : برخی از کلمات کلیدی که با متن و موضوع نامه مرتبط است و برنامۀ نامه خوان می‌تواند آنها را ملاک دسته‌بندی یا جستجو قرار بدهد.
• فیلد subject: یک کلمه یا جمله کوتاه که مضمون نامه را برای خواننده آن مشخص می‌نماید.

اگر چه فیلدهای فوق اختیاری هستند؛ ولی اگر کمی به آنها دقت کنید متوجه خواهید شد که در یک شرکت که ممکن است روزی صدها نامۀ الکترونیکی دریافت کند این فیلدها چقدر می‌توانند مفید واقع شوند و یک  نرم‌افزار نامه خوان برای دسته‌بندی، جستجو، تصمیم‌گیری برای سرنوشت نامه‌ها یا بایگانی آنها، چگونه     می‌تواند از آنها استفاده کند.

در استاندارد RFC 822 شخص کاربر می‌تواند فیلدهایی را برای استفاده خودش یا نرم‌افزاری که برای خواندن نامه‌هایش استفاده می‌کند تعریف نماید. تمام این فیلدها که همانند بقیۀ فیلدها در قسمت سرآیند نامه درج می‌شوند بایستی حتماً با دو حرف X- شروع شوند. این فیلدها فقط برای یک نرم‌افزار خاص یا شخص کاربر مفید خواهد بود و سرویس‌دهنده‌ای پستی که وظیفه انتقال و ذخیرۀ نامه‌ها را بر عهده دارند آنها را نادیده  می‌گیرند. مثلاً فرض کنید یک مؤسسه خوش‌ذوق بخواهد در یک فیلد از هر نامه‌ای که ارسال می‌کند (به طور خودکار و توسط نرم‌افزار) یک بیت شعر یا ضرب‌المثل قرار بدهد. در این حالت در قسمت سرآیند نامه فیلد زیر قابل‌تعریف است:

X-Proverb:…….             ضرب‌المثل:………….

(البته باید نرم‌افزار نامه خوان شخص گیرنده بتواند این فیلد را تمیز داده و نشان بدهد)

یادآوری این نکته بسیار مهم خواهد بود که هر فیلد و رشته‌ای که جلوی آن نوشته می‌شود باید در یک سطر مجزا قرار بگیرد و بین سطرهای سرآیند سطر خالی نباشد چرا که سطر خالی به منزله به منزله خاتمه قسمت سرآیند نامه و شروع متن (بدنه) نامه تلقی می‌شود و نرم‌افزار نامه خوان درون بدنۀ نامه را پردازش نخواهد کرد.

استاندارد RFC 822 تقریباً کامل و جامع است؛ ولی فقط زمانی بکار می‌آید که هدف ما ارسال نامه‌هایی باشد که مطلقاً متنی و به زبان انگلیسی هستند. حال فرض کنید بخواهید نامه‌ای جهت تبریک سال نو به زبان فارسی به همراه یک فایل تصویر به‌عنوان کارت‌پستال برای یک دوست ارسال نماید یا بخواهید قطعۀ کوتاهی از فیلم جشن تولد فرزندتان به نامه شما ضمیمه شود. در چنین مواردی استاندارد RFC 822 که مربوط به دو دهه قبل است جوابگو نخواهد بود استاندارد جدید MIME ضمن پشتیبانی از RFC 822 این نواقص را برطرف کرده است.