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

الموسوعة الحرة

البريد الإلكتروني HTML هو استخدام مجموعة فرعية من HTML لتوفير إمكانيات التنسيق والترميز الدلالي في البريد الإلكتروني والتي لا تتوفر مع النص العادي : [1] يمكن ربط النص دون عرض عنوان URL أو تقسيم عناوين URL الطويلة إلى أجزاء متعددة. يتم لف النص ليناسب عرض نافذة العرض، بدلاً من تقسيم كل سطر بشكل موحد عند 78 حرفًا (محدد في RFC 5322، وهو أمر ضروري في محطات النص القديمة ). يسمح بإدراج الصور والجداول والرسوم البيانية أو الصيغ الرياضية كصور، والتي يصعب نقلها بخلاف ذلك (عادةً باستخدام فن ASCII ).

التبني

تدعم معظم برامج البريد الإلكتروني الرسومية رسائل البريد الإلكتروني بتنسيق HTML، ويعتمد العديد منها على هذا التنسيق افتراضيًا. ويتضمن العديد من هذه البرامج محرر واجهة مستخدم رسومية لإنشاء رسائل البريد الإلكتروني بتنسيق HTML ومحرك عرض لعرض رسائل البريد الإلكتروني بتنسيق HTML المستلمة.

منذ إنشائه، عارض عدد من الأشخاص بصوت عالٍ جميع رسائل البريد الإلكتروني بتنسيق HTML (وحتى MIME نفسه)، وذلك لعدة أسباب. [2] على سبيل المثال، دعت حملة ASCII Ribbon إلى إرسال جميع رسائل البريد الإلكتروني بتنسيق نص ASCII . لم تنجح الحملة وتم التخلي عنها في عام 2013. [3] [4] في حين لا يزال يُعتبر غير مناسب في العديد من منشورات مجموعات الأخبار وقوائم البريد، إلا أن اعتماده للبريد الشخصي والتجاري زاد بمرور الوقت. يرى بعض أولئك الذين عارضوه بشدة عندما ظهر لأول مرة أنه غير ضار في الغالب. [5]

وفقًا لاستطلاعات أجرتها شركات التسويق عبر الإنترنت ، أصبح تبني عملاء البريد الإلكتروني القادرين على HTML الآن عالميًا تقريبًا، حيث أفاد أقل من 3% أنهم يستخدمون عملاء نصيين فقط. [6] يفضل غالبية المستخدمين تلقي رسائل البريد الإلكتروني بتنسيق HTML على النص العادي. [7] [8]

التوافق

لا يلزم أن يدعم برنامج البريد الإلكتروني المتوافق مع RFC 2822 سوى النص العادي، وليس تنسيق HTML. وبالتالي، قد يؤدي إرسال رسائل بريد إلكتروني بتنسيق HTML إلى حدوث مشكلات إذا كان عميل البريد الإلكتروني الخاص بالمستلم لا يدعم ذلك. وفي أسوأ الأحوال، سيرى المستلم كود HTML بدلاً من الرسالة المقصودة.

من بين عملاء البريد الإلكتروني الذين يدعمون HTML، لا يقوم البعض بعرضه بشكل متسق مع مواصفات W3C ، والعديد من رسائل البريد الإلكتروني بتنسيق HTML غير متوافقة أيضًا، مما قد يتسبب في حدوث مشكلات في العرض أو التسليم.

على وجه الخصوص، <head>العلامة، التي تستخدم لإيواء قواعد نمط CSS لمستند HTML بأكمله، ليست مدعومة جيدًا، وأحيانًا يتم تجريدها بالكامل، مما يتسبب في أن تكون إعلانات النمط المضمنة هي المعيار الفعلي ، على الرغم من أن إعلانات النمط المضمنة غير فعالة وتفشل في الاستفادة الجيدة من قدرة HTML على فصل النمط عن المحتوى. [ بحاجة لمصدر ] على الرغم من تطوير الحلول البديلة، [9] إلا أن هذا لم يتسبب في نقص الإحباط بين مطوري النشرة الإخبارية، مما أدى إلى ظهور مشروع معايير البريد الإلكتروني الشعبي ، والذي يصنف عملاء البريد الإلكتروني على أساس تقديمهم لاختبار الحمض، مستوحى من مشروع معايير الويب ، ويضغط على المطورين لتحسين منتجاتهم. لإقناع Google بتحسين العرض في Gmail ، على سبيل المثال، نشروا مونتاج فيديو لمطوري الويب المتجهمين، [10] مما أدى إلى اهتمام أحد الموظفين.

"مشروع معايير البريد الإلكتروني" مقارنة اختبارية حاسمة (حتى يناير 2013)[1] أرشيف 6 ديسمبر 2017 على موقع Wayback Machine
العملاء النتيجة (حتى الآن)
بريد الويب AOL دعم قوي (13 يوليو 2011)
ابل ايفون دعم قوي (13 يوليو 2011)
آيباد آبل
آيبود تاتش من آبل
بريد آبل دعم قوي (28 نوفمبر 2007)
أبل موبايل مي دعم قوي (15 أغسطس 2008)
يودورا
يودورا OSE الاسم الرمزي "بينيلوبي" 		دعم قوي (28 نوفمبر 2007)
مايكروسوفت إنتوراج دعم قوي (28 نوفمبر 2007)
موزيلا ثندربيرد دعم قوي (28 نوفمبر 2007)
بريد ويندوز لايف دعم قوي (28 نوفمبر 2007)
بريد ويندوز دعم قوي (28 نوفمبر 2007)
بريد ياهو! النسخة التجريبية دعم قوي (8 يوليو 2011)
ويندوز لايف هوتميل بعض التحسينات الموصى بها (8 يوليو 2011)
جوجل جيميل تحسين موصى به (13 يوليو 2011)
لوتس نوتس 8 تحسين موصى به (28 نوفمبر 2007)
مايكروسوفت أوت لوك 2007 تحسين موصى به (28 نوفمبر 2007)

أسلوب

قد يعتمد بعض المرسلين بشكل مفرط على الخطوط الكبيرة أو الملونة أو المشتتة للانتباه ، مما يجعل قراءة الرسائل أكثر صعوبة. [11] بالنسبة لأولئك الذين يزعجهم هذا التنسيق بشكل خاص، تتيح بعض وكلاء المستخدم للقارئ تجاوز التنسيق جزئيًا (على سبيل المثال، يسمح Mozilla Thunderbird بتحديد حجم خط أدنى)؛ ومع ذلك، فإن هذه القدرات غير متاحة عالميًا. علاوة على ذلك، يمكن أن يساعد الاختلاف في المظهر البصري بين المرسل والقارئ في التمييز بين مؤلف كل قسم، مما يحسن قابلية القراءة.

تنسيقات متعددة الأجزاء

يتم تكوين العديد من خوادم البريد الإلكتروني لتوليد نسخة نصية عادية من الرسالة تلقائيًا وإرسالها مع نسخة HTML، لضمان إمكانية قراءتها حتى بواسطة عملاء البريد الإلكتروني النصي فقط ، باستخدام ، كما هو محدد في RFC 1521. [12] [13] [14] الرسالة نفسها من النوع ، وتحتوي على جزأين، الأول من النوع ، الذي يقرأه عملاء النص فقط، والثاني مع ، الذي يقرأه عملاء HTML. ومع ذلك، قد تفتقر نسخة النص العادي إلى معلومات تنسيق مهمة. (على سبيل المثال، قد تفقد المعادلة الرياضية حرف علوي وتكتسب معنى جديدًا تمامًا.) Content-Type: multipart/alternativemultipart/alternativetext/plaintext/html

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

ترتيب الأجزاء مهم. تنص RFC1341 على أنه: بشكل عام، يجب على وكلاء المستخدم الذين يؤلفون كيانات متعددة الأجزاء/بديلة وضع أجزاء النص بترتيب تصاعدي للتفضيل، أي بالتنسيق المفضل أخيرًا. [15] بالنسبة لرسائل البريد الإلكتروني متعددة الأجزاء مع إصدارات html والنص العادي، فهذا يعني إدراج إصدار النص العادي أولاً وإصدار html بعده، وإلا فقد يضطر العميل افتراضيًا إلى إظهار إصدار النص العادي حتى لو كان إصدار html متاحًا.

حجم الرسالة

إن البريد الإلكتروني بتنسيق HTML أكبر من النص العادي. وحتى إذا لم يتم استخدام أي تنسيق خاص، فسوف تكون هناك تكلفة إضافية من العلامات المستخدمة في مستند HTML بسيط، وإذا تم استخدام التنسيق بكثافة فقد تكون التكلفة أعلى بكثير. تزيد الرسائل متعددة الأجزاء، مع نسخ مكررة من نفس المحتوى بتنسيقات مختلفة، من الحجم بشكل أكبر. ومع ذلك، يمكن استرداد قسم النص العادي في رسالة متعددة الأجزاء بمفرده، باستخدام أمر FETCH في IMAP . [16]

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

الثغرات الأمنية

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

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

تعتمد بعض هجمات التصيد الاحتيالي على ميزات معينة من HTML: [18]

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

غالبًا ما يتضمن عرض محتوى HTML قيام برنامج العميل باستدعاء روتينات خاصة لتحليل النص المشفر بلغة HTML وتقديمه؛ يمكن للمحتوى المشفر بشكل خاطئ عمدًا استغلال الأخطاء في تلك الروتينات لإنشاء انتهاكات أمنية. [ بحاجة لمصدر ] يمكن أن تؤثر طلبات الخطوط الخاصة وما إلى ذلك أيضًا على موارد النظام. [ بحاجة لمصدر ]

خلال فترات زيادة التهديدات الشبكية، قامت وزارة الدفاع الأمريكية بتحويل رسائل البريد الإلكتروني HTML الواردة للمستخدم إلى رسائل بريد إلكتروني نصية. [19]

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

يتم إرسال معظم رسائل البريد الإلكتروني العشوائية بتنسيق HTML [ بحاجة لمصدر ] لهذه الأسباب، لذا فإن مرشحات البريد العشوائي تمنح أحيانًا درجات بريد عشوائي أعلى لرسائل HTML. [ بحاجة لمصدر ]

في عام 2018 تم الكشف عن ثغرة أمنية ( EFAIL ) في معالجة HTML للعديد من عملاء البريد الإلكتروني الشائعين، حيث يمكن إرسال نص مفكك التشفير لأجزاء البريد الإلكتروني المشفرة باستخدام PGP أو S/MIME كسمة إلى عنوان صورة خارجي، إذا تم طلب الصورة الخارجية. كانت هذه الثغرة الأمنية موجودة في Thunderbird وmacOS Mail وOutlook وفي وقت لاحق، Gmail وApple Mail. [20]

انظر أيضا

مراجع

  1. ^ "البريد الإلكتروني النصي مقابل البريد الإلكتروني بتنسيق HTML – الإيجابيات والسلبيات | Thunder Mailer – برنامج إرسال بريد إلكتروني جماعي". thundermailer.com . تم الاسترجاع في 30 يناير 2016 .
  2. ^ البريد الإلكتروني HTML: عندما يكون ذلك ممكنا، قم بإيقاف تشغيله!
  3. ^ "الصفحة الرئيسية الرسمية لحملة شريط Ascii". مؤرشف من الأصل في 11 مارس 2010. تم الاسترجاع 30 يناير 2016 .
  4. ^ "إغلاق حملة شريط ASCII – منتدى Pale Moon". forum.palemoon.org . مؤرشف من الأصل في 3 فبراير 2016 . تم استرجاعه في 30 يناير 2016 .
  5. ^ البريد الإلكتروني HTML: الاستطلاع (يناقش سكوت هاكر، مبتكر السؤال الذي يرتبط كثيرًا بـ Why HTML in E-Mail is a Bad Idea، كيف تغيرت مشاعره منذ تسعينيات القرن العشرين)
  6. ^ "إحصائيات ومقاييس التسويق عبر البريد الإلكتروني – EmailLabs". 29 مارس 2007. مؤرشف من الأصل في 29 مارس 2007. تم الاسترجاع 30 يناير 2016. HTML يحظى باعتماد عالمي تقريبًا بين المستهلكين: وجد استطلاع رأي للمستهلكين أجرته شركة Jupiter Research أن 3% فقط يتلقون رسائل بريد إلكتروني نصية فقط.
  7. ^ Grossman, Edward (9 July 2002). "Real-World Email Client Usage: The Hard Data | ClickZ". clickz.com . تم الاسترجاع في 30 يناير 2016 . هل تفضل تلقي رسائل البريد الإلكتروني بتنسيق HTML أم بتنسيق نصي؟ HTML: 41.95%، نص: 31.52%، لا تفضيل: 26.53%
  8. ^ "علم التسويق عبر البريد الإلكتروني". slideshare.net . تم الاسترجاع في 30 يناير 2016. ما التنسيق الذي تفضله لتلقي رسائل البريد الإلكتروني من الشركات؟ HTML: 88%، نص عادي: 12%
  9. ^ Dialect <http://dialect.ca/>. "Premailer: جعل CSS مضمنًا للبريد الإلكتروني بتنسيق HTML". Premailer.dialect.ca . تم الاسترجاع في 24 يونيو 2012 . {{cite web}}: رابط خارجي في |author=( المساعدة )
  10. ^ "نداء Gmail لعام 2008 | مشروع معايير البريد الإلكتروني". Email-standards.org. مؤرشف من الأصل في 15 مايو 2012. تم الاسترجاع في 24 يونيو 2012 .
  11. ^ Shobe, Matt (12 October 2004). "A pretty fair argument against HTML Email". Burningdoor.com. مؤرشف من الأصل في 24 أبريل 2012. تم الاسترجاع في 24 يونيو 2012 .
  12. ^ RFC 1521 7.2.3. النوع الفرعي متعدد الأجزاء/البديل
  13. ^ "TN1010-11-2: Multipart/Alternative – التعامل بشكل أنيق مع عملاء البريد الإلكتروني الذين يخافون من HTML" (PDF) . تم الاسترجاع في 24 يونيو 2012 .
  14. ^ "إرسال رسائل بريد إلكتروني بتنسيق HTML ونص عادي في نفس الوقت". Wilsonweb.com. 28 أبريل 2000. تم الاسترجاع في 24 يونيو 2012 .
  15. ^ "RFC1341 القسم 7.2 نوع المحتوى متعدد الأجزاء" . تم الاسترجاع في 15 يوليو 2014 .
  16. ^ "هل نريد حقًا إرسال صفحات الويب عبر البريد الإلكتروني؟". Dsv.su.se . تم الاسترجاع في 24 يونيو 2012 .
  17. ^ البريد الإلكتروني HTML – لا يزال شريرًا؟
  18. ^ "تقنيات تحديد الاتجاهات في رسائل البريد الإلكتروني: كيف تختبئ رسائل التصيد الحديثة أمام أعين الجميع". Microsoft.com. 18 أغسطس 2021.
  19. ^ "وزارة الدفاع تحظر استخدام البريد الإلكتروني بتنسيق HTML وOutlook Web Access". nextgov.com. 22 ديسمبر 2006. تم الاسترجاع في 22 يونيو 2024 .
  20. ^ "عيوب Efail التي يعود تاريخها إلى عقد من الزمان قد تؤدي إلى تسريب النص العادي لرسائل البريد الإلكتروني المشفرة باستخدام PGP وS/MIME". arstechnica.com . 14 مايو 2018.
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=HTML_email&oldid=1230624916"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate