عميل البريد الإلكتروني

برنامج عميل البريد الإلكتروني ، أو قارئ البريد الإلكتروني ، أو وكيل مستخدم الرسائل ( MUA )، أو وكيل مستخدم البريد هو برنامج كمبيوتر يستخدم للوصول إلى بريد المستخدم وإدارته .

قد يعمل تطبيق الويب الذي يوفر وظائف إدارة الرسائل وكتابتها واستقبالها كعميل بريد إلكتروني ، وقد يستخدم هذا المصطلح أيضًا جهاز كمبيوتر أو برنامج يكون دوره الأساسي أو الأكثر وضوحًا هو العمل كعميل بريد إلكتروني.

استرجاع الرسائل من صندوق البريد

كغيره من برامج البريد الإلكتروني، لا يكون برنامج البريد الإلكتروني نشطًا إلا عند تشغيله من قِبل المستخدم. ويتمثل الترتيب الشائع في أن يقوم مستخدم البريد الإلكتروني (العميل) بالتنسيق مع خادم وكيل نقل البريد (MTA) عن بُعد لاستلام رسائل البريد الإلكتروني وتخزينها. ويقوم خادم وكيل نقل البريد، باستخدام وكيل تسليم بريد مناسب (MDA)، بإضافة رسائل البريد الإلكتروني إلى مساحة تخزين العميل فور وصولها. وتُعرف مساحة تخزين البريد البعيدة باسم صندوق بريد المستخدم . وفي العديد من أنظمة يونكس، يكون الإعداد الافتراضي هو أن يقوم خادم البريد بتخزين الرسائل المنسقة في مجلد mbox ، ضمن مجلد المستخدم الرئيسي . وبالطبع، يمكن لمستخدمي النظام تسجيل الدخول وتشغيل برنامج البريد الإلكتروني على نفس الحاسوب الذي يستضيف صناديق بريدهم؛ وفي هذه الحالة، لا يُعتبر الخادم بعيدًا فعليًا ، إلا بالمعنى العام.

تُخزَّن رسائل البريد الإلكتروني في صندوق بريد المستخدم على الخادم البعيد إلى أن يطلب برنامج البريد الإلكتروني الخاص بالمستخدم تنزيلها إلى جهاز الكمبيوتر الخاص به، أو إلى أن يتمكن من الوصول إلى صندوق بريد المستخدم على الخادم البعيد. ويمكن إعداد برنامج البريد الإلكتروني للاتصال بصناديق بريد متعددة في الوقت نفسه، وطلب تنزيل الرسائل إما تلقائيًا، على سبيل المثال، على فترات زمنية محددة مسبقًا، أو يدويًا من قِبل المستخدم.

يمكن الوصول إلى صندوق بريد المستخدم بطريقتين مخصصتين. يسمح بروتوكول مكتب البريد (POP) للمستخدم بتنزيل الرسائل واحدة تلو الأخرى، ولا يحذفها من الخادم إلا بعد حفظها بنجاح على وحدة التخزين المحلية. من الممكن ترك الرسائل على الخادم للسماح لعميل آخر بالوصول إليها. مع ذلك، لا توجد إمكانية لتمييز رسالة معينة على أنها مقروءة أو مُجاب عنها أو مُعاد توجيهها ، لذا فإن بروتوكول POP غير مناسب للمستخدمين الذين يصلون إلى نفس البريد من أجهزة مختلفة.

بدلاً من ذلك، يسمح بروتوكول الوصول إلى رسائل الإنترنت (IMAP) للمستخدمين بالاحتفاظ بالرسائل على الخادم، مع تصنيفها حسب الحاجة. يوفر IMAP مجلدات ومجلدات فرعية، يمكن مشاركتها بين مستخدمين مختلفين بصلاحيات وصول متفاوتة. عادةً، يتم إنشاء مجلدات "المرسلة " و "المسودات" و "المحذوفات" افتراضيًا. يتميز IMAP بامتداد "الخمول" للتحديثات الفورية، مما يوفر إشعارات أسرع من الاستقصاء، حيثما يكون الاتصال طويل الأمد ممكنًا. انظر أيضًا قسم الرسائل عن بُعد أدناه.

يتم تنفيذ بروتوكول JSON Meta Application Protocol (JMAP) باستخدام واجهات برمجة تطبيقات JSON عبر HTTP وقد تم تطويره كبديل لبروتوكول IMAP/SMTP.

بالإضافة إلى ذلك، يمكن الوصول إلى مساحة تخزين البريد الإلكتروني مباشرةً بواسطة البرامج التي تعمل على الخادم أو عبر الأقراص المشتركة . قد يكون الوصول المباشر أكثر كفاءة، ولكنه أقل قابلية للنقل لأنه يعتمد على تنسيق صندوق البريد؛ ويستخدمه بعض عملاء البريد الإلكتروني، بما في ذلك بعض تطبيقات البريد الإلكتروني عبر الويب .

تكوين الرسالة

تحتوي برامج البريد الإلكتروني عادةً على واجهات مستخدم لعرض النصوص وتحريرها. وتسمح بعض التطبيقات باستخدام محرر نصوص خارجي.

ستُجري برامج البريد الإلكتروني تنسيقًا وفقًا لمعيار RFC 5322 للرؤوس والنص ، و MIME للمحتوى غير النصي والمرفقات. تشمل الرؤوس حقول الوجهة، وTo ، و Cc ( نسخة كربونية )، و Bcc ( نسخة كربونية مخفية )، وحقول المُرسِل، والتي تشمل: From (مؤلف/مؤلفو الرسالة)، و Sender ( في حال وجود أكثر من مؤلف)، و Reply-To ( في حال توجيه الردود إلى صندوق بريد مختلف). ولتسهيل استخدام حقول الوجهة، تحتفظ العديد من البرامج بدفتر عناوين واحد أو أكثر، أو بإمكانها الاتصال بخادم دليل LDAP . أما بالنسبة لحقول المُرسِل، فقد تدعم البرامج هويات مختلفة.

تتطلب إعدادات العميل الاسم الحقيقي للمستخدم وعنوان البريد الإلكتروني لكل هوية مستخدم، وربما قائمة بخوادم LDAP.

إرسال الرسائل إلى الخادم

عندما يرغب المستخدم في إنشاء بريد إلكتروني وإرساله، يتولى برنامج البريد الإلكتروني هذه المهمة. عادةً ما يتم إعداد برنامج البريد الإلكتروني تلقائيًا للاتصال بخادم البريد الخاص بالمستخدم، والذي يكون عادةً إما خادم خدمة البريد (MSA) أو خادم نقل البريد (MTA) ، وهما نوعان من بروتوكول SMTP . يقوم برنامج البريد الإلكتروني الذي يستخدم بروتوكول SMTP بإنشاء امتداد مصادقة، يستخدمه خادم البريد للتحقق من هوية المرسل. تُسهّل هذه الطريقة عملية الحوسبة المعيارية والمتنقلة. أما الطريقة القديمة فكانت تعتمد على أن يتعرف خادم البريد على عنوان IP الخاص بالعميل، على سبيل المثال، لأن العميل موجود على نفس الجهاز ويستخدم العنوان الداخلي 127.0.0.1، أو لأن عنوان IP الخاص بالعميل يخضع لسيطرة نفس مزود خدمة الإنترنت الذي يوفر كلاً من الوصول إلى الإنترنت وخدمات البريد.

تتطلب إعدادات العميل اسم أو عنوان IP لخادم البريد الصادر المفضل ، ورقم المنفذ ، واسم المستخدم وكلمة المرور للمصادقة، إن وجدت. تُستخدم المنافذ التالية لإرسال البريد الإلكتروني:

- المنفذ 465 – المنفذ المخصص رسميًا لإرسال البريد باستخدام بروتوكول TLS منذ بداية الاتصال (بروتوكول TLS الضمني)، وفقًا للمعيار RFC 8314. وبما أن التشفير مُفعّل منذ البداية، فإنه يُزيل خطر هجمات خفض مستوى الأمان أو هجمات الوسيط (Man-in-the-Middle) التي قد تُزيل التشفير.

- المنفذ 587 – يُستخدم عادةً لإرسال البريد الإلكتروني مع دعم بروتوكول STARTTLS ، مما يسمح بترقية الاتصال اختيارياً إلى بروتوكول TLS. مع ذلك، إذا تدخل مهاجم من نوع MITM في أمر STARTTLS، فقد يظل الاتصال غير مشفر، مما يجعله أقل أماناً من بروتوكول TLS الضمني على المنفذ 465.

المنفذ 25، الذي كان مخصصًا في الأصل لإعادة توجيه الرسائل بين خوادم نقل البريد، ليس مخصصًا لإرسال رسائل العملاء وغالبًا ما يتم حظره بواسطة مزودي خدمة الإنترنت لمنع البريد العشوائي.

التشفير

بدون تشفير، كما هو الحال مع البطاقات البريدية، يصبح نشاط البريد الإلكتروني مكشوفًا لأي متطفل. يُمكّن تشفير البريد الإلكتروني من حماية الخصوصية عن طريق تشفير جلسات البريد، أو نص الرسالة، أو كليهما. بدونه، يستطيع أي شخص لديه إمكانية الوصول إلى الشبكة والأدوات المناسبة مراقبة البريد الإلكتروني والحصول على كلمات مرور تسجيل الدخول. ومن الأمثلة على ذلك الرقابة والمراقبة الحكومية، بالإضافة إلى مستخدمي الشبكات اللاسلكية الآخرين، كما هو الحال في مقاهي الإنترنت .

تتيح جميع بروتوكولات البريد الإلكتروني ذات الصلة خيار تشفير الجلسة بالكامل، لمنع التجسس على اسم المستخدم وكلمة المرور . يُنصح بشدة باستخدامها للمستخدمين كثيري التنقل، وعندما لا يكون مزود خدمة الإنترنت موثوقًا به. ^[¹^] عند إرسال البريد، لا يمكن للمستخدمين التحكم في التشفير إلا في المرحلة الأولى من اتصال العميل بخادم البريد الصادر المُهيأ . في أي مرحلة لاحقة، يمكن إرسال الرسائل مشفرة أو غير مشفرة، وذلك اعتمادًا فقط على الإعدادات العامة لخادم الإرسال وقدرات خادم الاستقبال.

تُرسل جلسات البريد الإلكتروني المشفرة الرسائل بتنسيقها الأصلي، أي كنص عادي أو مشفر، إلى صندوق بريد المستخدم المحلي وإلى خادم الوجهة. ويُشغّل هذا الخادم الأخير مزود خدمة استضافة بريد إلكتروني ، قد يكون جهة مختلفة عن مزود خدمة الإنترنت الحالي.

يمكن لتشفير جلسة استرجاع البريد الإلكتروني، باستخدام بروتوكول مثل SSL، حماية جزئي الجلسة (المصادقة ونقل الرسائل). ^{[ 2 ]}^{[ 3 ]}

بدلاً من ذلك، إذا كان لدى المستخدم إمكانية الوصول إلى خادم البريد الخاص به عبر SSH ، فيمكنه استخدام إعادة توجيه منفذ SSH لإنشاء نفق مشفر لاسترداد رسائل البريد الإلكتروني الخاصة به. ^{[ 4 ]}

تشفير محتوى الرسالة

يوجد نموذجان رئيسيان لإدارة مفاتيح التشفير. يستخدم S/MIME نموذجًا قائمًا على هيئة إصدار شهادات موثوقة (CA) تُوقّع المفاتيح العامة للمستخدمين. أما OpenPGP فيستخدم آلية شبكة ثقة أكثر مرونة، تسمح للمستخدمين بتوقيع مفاتيح بعضهم البعض العامة. كما يتميز OpenPGP بمرونة أكبر في تنسيق الرسائل، إذ لا يزال يدعم تشفير الرسائل العادية وتوقيعها كما كانا يعملان قبل توحيد معيار MIME .

في كلتا الحالتين، يتم تشفير نص الرسالة فقط. أما حقول الترويسة، بما في ذلك المرسل والمستلمين والموضوع في كثير من الأحيان، فتبقى كنص عادي.

البريد الإلكتروني

إضافةً إلى برامج البريد الإلكتروني التي تعمل على أجهزة الكمبيوتر المكتبية، توجد برامج أخرى مُستضافة عن بُعد، إما كجزء من نظام يونكس مُثبّت عن بُعد يُمكن الوصول إليه عبر بروتوكول تيلنت (أي حساب طرفية )، أو مُستضافة على الإنترنت . لكلتا الطريقتين مزايا عديدة: فهي تُتيح إمكانية إرسال واستقبال البريد الإلكتروني من خارج بيئة المستخدم المعتادة باستخدام متصفح ويب أو برنامج تيلنت، مما يُغني عن تثبيت برنامج بريد إلكتروني مُخصّص على جهاز المستخدم.

تُخصص بعض المواقع الإلكترونية لتقديم خدمات البريد الإلكتروني، كما يُقدم العديد من مزودي خدمة الإنترنت خدمات البريد الإلكتروني عبر الويب كجزء من باقاتهم. وتتمثل أبرز عيوب البريد الإلكتروني عبر الويب في أن تفاعلات المستخدم تعتمد على نظام تشغيل الموقع، وعدم إمكانية تحميل الرسائل الإلكترونية أو كتابتها أو العمل عليها دون اتصال بالإنترنت، على الرغم من وجود برامج تُدمج بعض وظائف البريد الإلكتروني عبر الويب في نظام التشغيل (مثل إنشاء الرسائل مباشرةً من تطبيقات خارجية عبر MAPI ).

على غرار بروتوكولي IMAP وMAPI، يتيح البريد الإلكتروني عبر الويب إمكانية بقاء رسائل البريد الإلكتروني على خادم البريد. انظر القسم التالي .

الرسائل عن بعد

يُتيح بروتوكول POP3 خيار الاحتفاظ بالرسائل على الخادم. في المقابل، يحتفظ كل من بروتوكول IMAP والبريد الإلكتروني عبر الويب بالرسائل على الخادم كجزء من آلية عملهما، مع إمكانية قيام المستخدمين بإنشاء نسخ محلية منها حسب رغبتهم. للاحتفاظ بالرسائل على الخادم مزايا وعيوب. ^{[ 5 ]}

المزايا

يمكن الوصول إلى الرسائل من أجهزة كمبيوتر أو أجهزة محمولة مختلفة في مواقع مختلفة، باستخدام عملاء مختلفين.
عادةً ما يوفر الخادم نوعًا من النسخ الاحتياطي.

العيوب

مع محدودية النطاق الترددي، قد يستغرق الوصول إلى الرسائل الطويلة وقتاً طويلاً، ما لم يقم برنامج البريد الإلكتروني بتخزين نسخة محلية مؤقتاً.
قد تكون هناك مخاوف تتعلق بالخصوصية لأن الرسائل التي تبقى على الخادم طوال الوقت لديها فرص أكبر للوصول إليها بشكل عرضي من قبل موظفي تكنولوجيا المعلومات، ما لم يتم استخدام التشفير من طرف إلى طرف .

البروتوكولات

تشمل البروتوكولات الشائعة لاسترجاع البريد بروتوكولي POP3 و IMAP4 . أما إرسال البريد فيتم عادةً باستخدام بروتوكول SMTP .

يُعدّ معيار MIME معيارًا مهمًا آخر تدعمه معظم برامج البريد الإلكتروني ، ويُستخدم لإرسال مرفقات البريد الإلكتروني من نوع الملفات الثنائية . المرفقات هي ملفات لا تُشكّل جزءًا من البريد الإلكتروني نفسه، ولكنها تُرسل معه.

تستخدم معظم برامج البريد الإلكتروني حقل رأس User-Agent ^{[ 6 ]} لتحديد البرنامج المستخدم لإرسال الرسالة. هذا الحقل مُعرّف لشبكة Netnews، ولكنه غير مُعرّف للبريد الإلكتروني، ولذلك يُعتبر غير قياسي ^[⁷^] في رؤوس رسائل البريد الإلكتروني.

RFC 6409 ، إرسال الرسائل للبريد ، يوضح بالتفصيل دور وكيل إرسال البريد .

تُقدّم وثيقة RFC 5068 ، بعنوان "عمليات إرسال البريد الإلكتروني: متطلبات الوصول والمساءلة "، استعراضًا لمفاهيم MTA وMSA وMDA وMUA. وتشير إلى أنه " يجب على مزودي خدمة الوصول عدم منع المستخدمين من الوصول إلى الإنترنت الخارجي باستخدام منفذ الإرسال 587 "، وأن " يُفضّل أن تستخدم خوادم البريد الإلكتروني منفذ الإرسال لإرسال الرسائل " .

RFC 5965 ، وهو تنسيق قابل للتوسيع لتقارير التعليقات على البريد الإلكتروني ، يوفر "تنسيقًا قابلًا للتوسيع ونوع MIME يمكن استخدامه من قبل مشغلي البريد للإبلاغ عن التعليقات حول البريد الإلكتروني المستلم إلى جهات أخرى".

أرقام المنافذ

تستخدم خوادم البريد الإلكتروني وعملاؤها، وفقًا للعرف، أرقام منافذ TCP الموضحة في الجدول التالي. بالنسبة لبروتوكولات MSA وIMAP وPOP3، يُظهر الجدول أيضًا التصنيفات التي يمكن للعميل استخدامها للاستعلام عن سجلات SRV واكتشاف كلٍ من اسم المضيف ورقم المنفذ للخدمة المعنية. ^{[ 8 ]}

بروتوكول	يستخدم	جلسات نصية عادية أو مشفرة	جلسات نصية عادية فقط	تشفير الجلسات فقط
POP3	البريد الوارد	110 _pop3._tcp		995 _pop3s._tcp
IMAP4	البريد الوارد	143 _imap._tcp		993 _imaps._tcp
SMTP	البريد الصادر	25		587
MSA	البريد الصادر	587 _submission._tcp		465 ^{[ 9 ]} _submissions._tcp
HTTP	البريد الإلكتروني عبر الويب		80	443

بينما يلتزم البريد الإلكتروني عبر الويب بنهج HTTP السابق المتمثل في تخصيص منافذ منفصلة لجلسات التشفير والنصوص العادية، تستخدم بروتوكولات البريد تقنية STARTTLS ، مما يسمح ببدء التشفير على اتصال TCP قائم بالفعل. وفي حين كان RFC 2595 يُثني عن استخدام المنفذين 995 و993 المُنشأين مسبقًا، يُشجع RFC 8314 على استخدام TLS الضمني عند توفره.

بروتوكولات العميل الخاصة

تستخدم أنظمة البريد الإلكتروني من مايكروسوفت واجهة برمجة تطبيقات المراسلة الخاصة (MAPI) في تطبيقات العميل، مثل مايكروسوفت أوتلوك ، للوصول إلى خوادم البريد الإلكتروني مايكروسوفت إكستشينج .

انظر أيضاً

مراجع

↑ سي. هوتزلر؛ دي. كروكر؛ بي. ريسنيك؛ إي. ألمان؛ تي. فينش (نوفمبر 2007). " تقنيات مصادقة/تفويض إرسال الرسائل" . عمليات إرسال البريد الإلكتروني: متطلبات الوصول والمساءلة . IETF . القسم 5. doi : 10.17487/RFC5068 . BCP 134. RFC 5068. تم الاطلاع عليه في 24 أغسطس 2011. لا تقدم هذه الوثيقة توصيات بشأن تطبيقات أمنية محددة. إنما تحذر من ضرورة تجنب إرسال بيانات اعتماد المستخدم كنص عادي عبر الشبكات غير الآمنة في جميع الحالات، لأن ذلك قد يسمح للمهاجمين بالتنصت على هذه البيانات وسرقة بيانات الحساب. في هذه الحالات، يُنصح بشدة باستخدام تقنية أمنية مناسبة.
↑ سيل 2003 ، ص. 353: "مثل SMTP، فإن POP3 غير مشفر. ولكن على عكس SMTP، يتطلب POP3 مصادقة: إذ يتعين على المستخدمين تعريف أنفسهم وإثبات هويتهم. لسوء الحظ، تتكون المصادقة عادةً من تقديم اسم مستخدم وكلمة مرور لا يعرفهما إلا المستخدم وخادم POP3. ولأن حوار POP3 غير مشفر، يمكن للمتطفل الحصول على اسم المستخدم وكلمة المرور وإعادة استخدامهما للوصول إلى صندوق بريد المستخدم. لذا، يكشف POP3 العادي محتويات رسائل البريد التي يسترجعها المستخدم، ويكشف اسم المستخدم وكلمة المرور، والتي يمكن إعادة استخدامها من قبل شخص آخر.إن تغليف حوار POP3 بأمان طبقة النقل مثل SSL يحل هاتين المشكلتين. ولأن جلسات POP3 المغلفة بـ SSL مشفرة من البداية إلى النهاية، فلا يتم كشف أي رسائل أو أسماء مستخدمين أو كلمات مرور كنص واضح.يستبدلأمر POP3الاختياري المصادقة القياسية بآلية مصادقة التحدي والاستجابة. وهذا يحل المشكلة مشكلة الكشف عن كلمات المرور القابلة لإعادة الاستخدام، لكنها لا تفعل شيئًا لمنع المتنصتين من قراءة رسائل البريد الإلكتروني للمستخدمين أثناء استرجاعها.APOPUSER/PASS
↑ إجراء مُحدَّث للتحقق من هوية خادم بروتوكول أمان طبقة النقل (TLS) للبروتوكولات المتعلقة بالبريد الإلكتروني . IETF . doi : 10.17487/RFC7817 . RFC 7817 .
↑ فليكنجر، روب (2003). اختراقات خوادم لينكس: 100 نصيحة وأداة قوية . دار نشر أورايلي ميديا . ص 146. ISBN 978-0596004613بالإضافة إلى توفير الوصول عن بُعد إلى سطر الأوامر وتنفيذ الأوامر، يُمكن لـ OpenSSH إعادة توجيه أي منافذ TCP إلى الطرف الآخر من اتصالك. يُعدّ هذا مفيدًا جدًا لحماية البريد الإلكتروني، أو تصفح الإنترنت، أو أي بيانات أخرى ترغب في الحفاظ على خصوصيتها (على الأقل حتى نهاية النفق). يُنجز ssh إعادة التوجيه المحلي عن طريق الربط بمنفذ محلي، وتشفير البيانات، وإرسالها إلى الطرف البعيد من اتصال ssh ، ثم فك تشفيرها وإرسالها إلى المضيف والمنفذ البعيد الذي تُحدده. لبدء نفق ssh، استخدم الخيار ‎-L (اختصارًا لـ Local): استبدل user باسم المستخدم الخاص بك، و mailhost باسم خادم البريد أو عنوان IP الخاص به. لاحظ أنه يجب أن تكون مستخدمًا بصلاحيات الجذر على الكمبيوتر المحمول في هذا المثال، لأنك ستربط بمنفذ ذي امتيازات (110، منفذ POP). يجب عليك أيضًا تعطيل أي خدمة POP تعمل محليًا (ابحث عنها في /etc/inetd.conf ) وإلا ستُعيق العملية. لتشفير جميع حركة مرور POP الخاصة بك، قم بتكوين عميل البريد الخاص بك للاتصال بالمنفذ 110 على المضيف المحلي. سيتواصل مع مضيف البريد كما لو كان متصلاً مباشرة، باستثناء أن المحادثة بأكملها ستكون مشفرة.root@laptop:~# ssh -f -N -L110:mailhost:110 -l usermailhost
↑ "هل بروتوكول IMAP مناسب لي؟" . خدمات تقنية المعلومات . جامعة ستانفورد . 4 مارس 2010. مؤرشف من الأصل في 30 أبريل 2010. تم الاطلاع عليه في 14 أبريل 2013 .
↑ " User-Agent" . تنسيق مقالات Netnews . IETF . نوفمبر 2009. القسم 3.2.13. doi : 10.17487/RFC5536 . RFC 5536. تم إرسال بعض هذه المعلومات سابقًا في حقول رأس غير قياسية مثل X-Newsreader وX-Mailer وX-Posting-Agent وX-Http-User-Agent وغيرها.
↑ ج. بالم (فبراير 1997). "استخدام رؤوس التوجيه" . رؤوس رسائل الإنترنت الشائعة . IETF . القسم 2. doi : 10.17487/RFC2076 . RFC 2076. تاريخ الاسترجاع: 11 مايو 2015. تظهر أحيانًا رؤوس الرسائل المُعرَّفة فقط في RFC 1036 والمخصصة للاستخدام في أخبار يوزنت في رسائل البريد الإلكتروني، إما لأن الرسائل قد تم توجيهها من أخبار يوزنت إلى البريد الإلكتروني، أو لأن الرسائل كُتبت في برامج عميل مُدمجة تدعم كلاً من البريد الإلكتروني وأخبار يوزنت في نفس البرنامج. هذه الرؤوس غير مُوحَّدة للاستخدام في البريد الإلكتروني عبر الإنترنت، ويجب على وكلاء البريد الإلكتروني التعامل معها بحذر.
↑ سايروس دابو (مارس 2011). استخدام سجلات SRV لتحديد مواقع خدمات إرسال/الوصول إلى البريد الإلكتروني . IETF . doi : 10.17487/RFC6186 . RFC 6186. تاريخ الاسترجاع: 17 أبريل 2013 .
↑ كيث مور؛ كريس نيومان (يناير 2018). النص الواضح يُعتبر قديمًا: استخدام بروتوكول أمان طبقة النقل (TLS) لإرسال البريد الإلكتروني والوصول إليه . IETF . doi : 10.17487/RFC8314 . RFC 8314. تاريخ الاسترجاع: 12 فبراير 2018 .

فهرس

سيل، ديف (2003). دليل qmail . دار نشر Apress . رقم ISBN 9781430211341.
بارتردج، كريج (أبريل - يونيو 2008). "التطور التقني للبريد الإلكتروني عبر الإنترنت" (ملف PDF) . حوليات IEEE لتاريخ الحوسبة . 30 (2): 3-29 . رمز Bibcode : 2008IAHC...30b...3P . doi : 10.1109/mahc.2008.32 . ISSN 1934-1547 . S2CID 206442868. مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 12 مايو 2011.

[1] سي. هوتزلر؛ دي. كروكر؛ بي. ريسنيك؛ إي. ألمان؛ تي. فينش (نوفمبر 2007). " تقنيات مصادقة/تفويض إرسال الرسائل" . عمليات إرسال البريد الإلكتروني: متطلبات الوصول والمساءلة . IETF . القسم 5. doi : 10.17487/RFC5068 . BCP 134. RFC 5068. تم الاطلاع عليه في 24 أغسطس 2011. لا تقدم هذه الوثيقة توصيات بشأن تطبيقات أمنية محددة. إنما تحذر من ضرورة تجنب إرسال بيانات اعتماد المستخدم كنص عادي عبر الشبكات غير الآمنة في جميع الحالات، لأن ذلك قد يسمح للمهاجمين بالتنصت على هذه البيانات وسرقة بيانات الحساب. في هذه الحالات، يُنصح بشدة باستخدام تقنية أمنية مناسبة.

[sill-security-2] سيل 2003 ، ص. 353: "مثل SMTP، فإن POP3 غير مشفر. ولكن على عكس SMTP، يتطلب POP3 مصادقة: إذ يتعين على المستخدمين تعريف أنفسهم وإثبات هويتهم. لسوء الحظ، تتكون المصادقة عادةً من تقديم اسم مستخدم وكلمة مرور لا يعرفهما إلا المستخدم وخادم POP3. ولأن حوار POP3 غير مشفر، يمكن للمتطفل الحصول على اسم المستخدم وكلمة المرور وإعادة استخدامهما للوصول إلى صندوق بريد المستخدم. لذا، يكشف POP3 العادي محتويات رسائل البريد التي يسترجعها المستخدم، ويكشف اسم المستخدم وكلمة المرور، والتي يمكن إعادة استخدامها من قبل شخص آخر.إن تغليف حوار POP3 بأمان طبقة النقل مثل SSL يحل هاتين المشكلتين. ولأن جلسات POP3 المغلفة بـ SSL مشفرة من البداية إلى النهاية، فلا يتم كشف أي رسائل أو أسماء مستخدمين أو كلمات مرور كنص واضح.يستبدلأمر POP3الاختياري المصادقة القياسية بآلية مصادقة التحدي والاستجابة. وهذا يحل المشكلة مشكلة الكشف عن كلمات المرور القابلة لإعادة الاستخدام، لكنها لا تفعل شيئًا لمنع المتنصتين من قراءة رسائل البريد الإلكتروني للمستخدمين أثناء استرجاعها.APOPUSER/PASS

[3] إجراء مُحدَّث للتحقق من هوية خادم بروتوكول أمان طبقة النقل (TLS) للبروتوكولات المتعلقة بالبريد الإلكتروني . IETF . doi : 10.17487/RFC7817 . RFC 7817 .

[4] فليكنجر، روب (2003). اختراقات خوادم لينكس: 100 نصيحة وأداة قوية . دار نشر أورايلي ميديا . ص 146. ISBN 978-0596004613بالإضافة إلى توفير الوصول عن بُعد إلى سطر الأوامر وتنفيذ الأوامر، يُمكن لـ OpenSSH إعادة توجيه أي منافذ TCP إلى الطرف الآخر من اتصالك. يُعدّ هذا مفيدًا جدًا لحماية البريد الإلكتروني، أو تصفح الإنترنت، أو أي بيانات أخرى ترغب في الحفاظ على خصوصيتها (على الأقل حتى نهاية النفق). يُنجز ssh إعادة التوجيه المحلي عن طريق الربط بمنفذ محلي، وتشفير البيانات، وإرسالها إلى الطرف البعيد من اتصال ssh ، ثم فك تشفيرها وإرسالها إلى المضيف والمنفذ البعيد الذي تُحدده. لبدء نفق ssh، استخدم الخيار ‎-L (اختصارًا لـ Local): استبدل user باسم المستخدم الخاص بك، و mailhost باسم خادم البريد أو عنوان IP الخاص به. لاحظ أنه يجب أن تكون مستخدمًا بصلاحيات الجذر على الكمبيوتر المحمول في هذا المثال، لأنك ستربط بمنفذ ذي امتيازات (110، منفذ POP). يجب عليك أيضًا تعطيل أي خدمة POP تعمل محليًا (ابحث عنها في /etc/inetd.conf ) وإلا ستُعيق العملية. لتشفير جميع حركة مرور POP الخاصة بك، قم بتكوين عميل البريد الخاص بك للاتصال بالمنفذ 110 على المضيف المحلي. سيتواصل مع مضيف البريد كما لو كان متصلاً مباشرة، باستثناء أن المحادثة بأكملها ستكون مشفرة.root@laptop:~# ssh -f -N -L110:mailhost:110 -l usermailhost

[5] "هل بروتوكول IMAP مناسب لي؟" . خدمات تقنية المعلومات . جامعة ستانفورد . 4 مارس 2010. مؤرشف من الأصل في 30 أبريل 2010. تم الاطلاع عليه في 14 أبريل 2013 .

[6] " User-Agent" . تنسيق مقالات Netnews . IETF . نوفمبر 2009. القسم 3.2.13. doi : 10.17487/RFC5536 . RFC 5536. تم إرسال بعض هذه المعلومات سابقًا في حقول رأس غير قياسية مثل X-Newsreader وX-Mailer وX-Posting-Agent وX-Http-User-Agent وغيرها.

[7] ج. بالم (فبراير 1997). "استخدام رؤوس التوجيه" . رؤوس رسائل الإنترنت الشائعة . IETF . القسم 2. doi : 10.17487/RFC2076 . RFC 2076. تاريخ الاسترجاع: 11 مايو 2015. تظهر أحيانًا رؤوس الرسائل المُعرَّفة فقط في RFC 1036 والمخصصة للاستخدام في أخبار يوزنت في رسائل البريد الإلكتروني، إما لأن الرسائل قد تم توجيهها من أخبار يوزنت إلى البريد الإلكتروني، أو لأن الرسائل كُتبت في برامج عميل مُدمجة تدعم كلاً من البريد الإلكتروني وأخبار يوزنت في نفس البرنامج. هذه الرؤوس غير مُوحَّدة للاستخدام في البريد الإلكتروني عبر الإنترنت، ويجب على وكلاء البريد الإلكتروني التعامل معها بحذر.

[8] سايروس دابو (مارس 2011). استخدام سجلات SRV لتحديد مواقع خدمات إرسال/الوصول إلى البريد الإلكتروني . IETF . doi : 10.17487/RFC6186 . RFC 6186. تاريخ الاسترجاع: 17 أبريل 2013 .

[9] كيث مور؛ كريس نيومان (يناير 2018). النص الواضح يُعتبر قديمًا: استخدام بروتوكول أمان طبقة النقل (TLS) لإرسال البريد الإلكتروني والوصول إليه . IETF . doi : 10.17487/RFC8314 . RFC 8314. تاريخ الاسترجاع: 12 فبراير 2018 .

[

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[

[ 8 ]

[ 9 ]