سؤال لماذا أحتاج إلى خادم SMTP؟


لماذا أحتاج إلى خادم SMTP وسيط لإرسال البريد؟ لماذا لا يستطيع عميلي (Outlook ، Thunderbird) إرسال الرسائل مباشرةً إلى نطاق SMTP الخاص بالمستلم؟

على سبيل المثال ، إذا كان لا بد لي من إرسال بريد إلكتروني إلى address@example.com مع حساب Gmail الخاص بي ، أرسله إلى smtp.gmail.com الخادم؛ ثم سيرسل هذا الخادم رسالتي إلى خادم MX الخاص بـ example.com.


91
2017-11-27 07:12


الأصل


ممكن نسخة من لماذا لا يستخدم عملاء البريد مباشرة خادم SMTP الخاص بالمستلم - WoDoSc


الأجوبة:


من الممكن تقنيا إرسال بريد إلكتروني مباشرة إلى خادم SMTP الخاص بالمستلم من جهاز الكمبيوتر الخاص بك.

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

بالانتقال إلى حيث تكون الإنترنت رخيصة ، لا يزال من المفيد امتلاك آليات لإعادة إرسال البريد الإلكتروني إذا كان الخادم غير متوفر ، وهو ليس مثاليًا لكتابة هذه الوظيفة إلى MUA (بريد المستخدم / برنامج بريد المستخدم النهائي). تناسب هذه الوظائف في MTA (خادم البريد / خادم SMTP).

لكن الأمور تسوءالاطر. معظم رسائل البريد الإلكتروني (أكثر من 80٪) هي رسائل غير مرغوب فيها. لذا يفعل مزودو البريد ما بوسعهم للحد من هذه المشكلة - وعدد كبير من التقنيات يضع افتراضات حول طريقة تسليم البريد الإلكتروني - وفيما يلي اعتبارات مهمة:

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

  2. سمعة: من الأرجح أن يكون شخص ما يرسل البريد الإلكتروني من خلال خادم SMTP معروف ومعروف شرعياً من الخادم الذي يعمل بالليل. للحصول على الشعور بالسمعة ، يقوم مقدمو الخدمات بعدد من الأشياء:

    1. حظر عناوين الديناميكي / العميل (ليس 100 ٪ ، ولكن تم تعيين أجزاء كبيرة من الإنترنت بها).

    2. انظروا أن عكس DNS يطابق DNS إلى الأمام: ليس من الصعب جدًا القيام بذلك ، ولكن يظهر مستوى معين من المساءلة والمعرفة بأفضل الممارسات - وشيء لا يوجد لدى الكثير من كتل عناوين العميل.

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

    4. SPF و DKIM: هذه الآليات ربط موارد DNS إلى المجال اسم لجعل تزوير البريد أصعب ، وسيكون من الصعب (ولكن ليس كذلك من المستحيل بالضرورة نشر إذا كان برنامج البريد (MUA) مسؤولة عن البريد الصادر. (أضيفت لجعل هذه الإجابة أكثر اكتمالاً كما تم قبوله بالفعل. يجب أن يذهب الائتمان لذلك إلى الملصقات أدناه لأنها تراجعت عن ذهني ، ولكنها ، مع ذلك ، صالحة جدًا)

ربما تكون هناك مخاوف ثانوية أخرى ، لكن ستكون هذه هي المشكلات الرئيسية.


113
2017-11-27 07:32



لا تنسى هذا ليس قاصرا أشياء مثل SPF (قائمة بيضاء بالمضيفين المسموح لها بإرسال البريد لأحد النطاقات) و DKIM (توقيع الرسائل رقمياً على مستوى المجال) - خاصة أن الأخير ممكن فقط مع مرحل مخصص. - grawity
grawity بالتأكيد يستحق ذكره ، ولكن لماذا لا DKIM "ممكن" دون تتابع مخصص؟ لا تكون محددات DKIM مرتبطة بطلب الإرسال أو عنوان IP. إذا كان عميل البريد الخاص بك يمكنه توقيع الرسالة باستخدام مفتاح منشور ، فإنه يكون صالحًا مثل أي موقّع آخر. - Mathias R. Jessen
ManuH: وفقًا للمقاييس في الإجابة الدقيقة ، يتسبب البريد العادي في اختراق 1/5 حجم البريد. حسب المقاييس على لي الخادم والبريد العادي يعرض 1/20 من حجم البريد. إنها تجارة رائعة. - dotancohen
manuh: يتم إرسال القائمة الرمادية عن طريق إغلاق ملف الاتصال قبل إرسال البريد الإلكتروني - يستمع فقط حتى يتلقى المرسل والمتلقي - الموجود في الرأسية. أيضا ، فإن بعض أنظمة greylist سوف ommediatelly. قبول جميع رسائل البريد الإلكتروني من خادم SMTP الذي يحتوي على سجل لإعادة المحاولة. للأسف ، فعالة جدا. - davidgo
يمكن أن يضيف أنه في "أيام ol جيدة" كان غالبا ما يتم إرسال البريد من خادم SMTP إلى آخر ، ثم آخر ، ثم آخر قبل الوصول إلى وجهتها. عادة ما يكون هذا جيدًا ، ولكن على سبيل المثال أثناء هجوم rtm-worm ، كان أحد أجهزة الكمبيوتر الأساسية أحد المرحلات الأساسية للبريد ، لذلك قد تستغرق رسائل البريد الإلكتروني مع التحذيرات والحلول والإصلاحات إلى الدودة 48 ساعة للوصول إلى المتلقين. - Baard Kopperud


لماذا أحتاج إلى خادم SMTP وسيط لإرسال البريد؟ لماذا لا أستطيع   العميل (توقعات ، ثندربيرد) إرسال رسائل مباشرة إلى   نطاق SMTP الخاص بالمستلم؟

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

عند استخدام خدمة SMTP "حقيقية" ، يتم تعيين الأشياء مثل سجلات PTR وسجلات نظام التعرف على هوية المرسل وحتى DomainKeys التي تم إنشاؤها جميعًا لغرض واحد وغرض واحد فقط: التأكد من أن SMTP الذي يرسل الرسالة شرعيًا. وإذا لم يكن كذلك؟ قم بتصفية الرسالة في مجلد الرسائل الاقتحامية (SPAM) أو "الهاوية العظيمة" للحذف. في ما يلي تفاصيل عن كل عنصر من هذه العناصر:

  • PTR (سجل مؤشر / سجل DNS العكسي): التحقق من مستوى الخادم. مثل وأوضح هنايتم استخدام سجل PTR لتعيين واجهة شبكة (IP) إلى اسم مضيف. يعني إذا كان لديك عنوان 123.456.789.0 على خادم SMTP إرسال رسائل البريد الإلكتروني ل smtp.example.com ثم سجل PTR المناسب لذلك سيكون smtp.example.com. يبدو الأمر بسيطًا جدًا ، ولكنه يعمل لأن الشخص الوحيد الذي يمكنه تعيين سجل PTR هو مالك عنوان IP ولا يمكن تعيينه إلا على أجهزته. لذا فإنها تعمل كنقطة تحقق نحو من يملك / يدير / يدير عنوان IP هذا.

  • SPF (إطار سياسة المرسل): اسم المضيف DNS مستوى التحقق. سجل SPF -كما هو موضح هنا—أساسًا سجل DNS تم تعيينه بواسطة حامل اسم النطاق الذي يوفر قائمة بعناوين IP وأسماء مضيفي الخوادم المسموح لها بإرسال رسائل البريد الإلكتروني لاسم النطاق هذا. هذا مرة أخرى هو خطوة تحقق أخرى تضمن أن مالك اسم المجال الحقيقي فقط لخادم SMTP يمكنه إرسال رسائل البريد الإلكتروني. لنفترض خادمًا بعنوان IP لـ 123.456.789.9 هو ارسال رسائل البريد الالكتروني ل example.com. نحن نعرف ذلك بالفعل smtp.example.com الاستخدامات 123.456.789.0، ولكن إدخال سجل SPF لـ example.com يمكن أن يقول "يا! 123.456.789.9 هو خادم جيد! إنه شرعي! احترم رسائل البريد الإلكتروني الخاصة به! "

  • DKIM (MailKeys Identified Mail): التحقق من مستوى رسالة البريد الإلكتروني. مثل وأوضح هنا و على ويكيبيديا"DKIM عبارة عن نظام التحقق من البريد الإلكتروني المصمم للكشف عن انتحال البريد الإلكتروني من خلال توفير آلية تسمح لمبادلات البريد بالتحقق من أن البريد الوارد من أحد النطاقات مأذون به من قبل مسؤولي النطاق وأنه لم يتم تعديل البريد الإلكتروني (بما في ذلك المرفقات) أثناء النقل باستخدام تجزئة التشفير ، تتحقق DKIM من أن البريد نفسه لم تتم تصفيته أو العبث به أثناء النقل. هذا أيضا بمثابة نقطة تحقق أخرى في سلسلة "هل أنت شرعي أو أنت الرسائل الاقتحامية؟".

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


32
2017-11-27 19:36





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


15
2017-11-27 07:23



تكتب "معظم موفري خدمات الإنترنت السكنية حظر منفذ TCP 25 (SMTP)" <- هل يمكنك شرح ما يعنيه ذلك. هل تعني أنها لن تسمح لك بإجراء اتصال صادر إلى خادم SMTP على المنفذ 25؟ أو تقصد أنها لن تسمح لك باستقبال اتصال على المنفذ 25؟ - barlop
barlop الأولى - تمنع الاتصالات الصادرة على 25 من الروابط السكنية للآلات بخلاف خوادم البريد الخاصة بهم (أو في الواقع إلى أي مكان ، لأنها قد تستخدم 587 أو 465 لخوادمهم الخاصة). ومع ذلك ، فمن المبالغة إلى حد ما القول بأن معظم مزودي خدمات الإنترنت يفعلون ذلك. - hobbs
hobbs - خبرتي (وجزء من عملي جزءًا) مختلفان. في حين أن الكثير من مزودي خدمات الإنترنت سوف يمنع حركة المرور من مغادرة شبكتهم مع هدف المنفذ 25 (الذي يجبر 25 منفذ حركة المرور من خلال خوادم البريد الخاصة بهم) ، فإن نفس الشيء لا ينطبق بشكل عام على المنفذ 587 أو 465 - وهذا بالفعل منطقي. المنفذ 587 و 465 عموما المصادقة REQUIRE ، وحظر وعلى وجه التحديد هو MUA MTA بدلاً من MTA-MTA - حظر هذه المنافذ ستولد رد فعل ضخم كما تتطلب العديد من الشركات ذلك للسماح بالتجوال والمساءلة وليس كسر SPF. - davidgo
hobbs ، لم أكتب أبدًا أن معظم مزودي خدمة الإنترنت يفعلون ذلك ؛ ما كتبته هو أن معظم مزودي خدمات الإنترنت السكنية افعل هذا. على سبيل المثال ، يقوم كل من AT & T و Comcast و TWC و Verizon وغير ذلك بعمل ذلك لعملاء السكن ، ولكنهم لا يفعلون ذلك لعملاء شركاتهم. - Ron Maupin


الإجابات الأخرى كلها ممتازة ، والرسائل الاقتحامية لديها الكثير لتفعله حيال ذلك.

ولكن في الحقيقة هناك إجابة أبسط وأكثر عامة: ميزات. يعد إرسال البريد الإلكتروني عبر SMTP مهمة معقدة للغاية. حتى بدون البريد الإلكتروني العشوائي ، لن ترغب في تطبيق مجموعة الميزات الكاملة من بروتوكول SMTP في كل عميل بريد إلكتروني ؛ كنت أفضل حالا مع قطعة مخصصة من البرامج (sendmail ، postfix الخ هي الكبيرة في العالم * نيكس ، صرف في عالم ويندوز).

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

وهذه هي الوظيفة الأساسية التي يجب أن لا يعمل الملقم بدونها. لا تتضمن حتى أشياء مثل إعادة كتابة العنوان ، mailertables. ناهيك عن عشرات أو غيرها من البروتوكولات التي تدعم sendmail آخرون ، مثل UUCP.

تطبيق SMTP في Outlook ، Thunderbird الخ هو الحد الأدنى جدا - في أحسن الأحوال ، ما يعادل تقريبا استخدام مضيف ذكية على sendmail ، إذا كان ذلك.

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


6
2017-11-30 00:04



هذه نقطة جيدة. الأمر لا يتعلق فقط بالميزات الفعلية للصفوف وما إلى ذلك: توفر من الخادم يحدث فرقا لبعض هذه الميزات. إذا كانت هناك مشكلة وقمت بإيقاف تشغيل الكمبيوتر المحمول الخاص بك ، فلا يمكن إعادة المحاولة حتى يتم تشغيلها في المرة التالية - من المرجح أن يكون خادم البريد متاحًا على مدار 24 ساعة طوال أيام الأسبوع على الرغم من أنه في وضع أفضل بكثير لإدارة قائمة انتظار الرسائل. بمجرد إرسال رسالتك إلى الخادم بواسطة SMTP ، لا يحتاج عميل البريد الخاص بك إلى البقاء على الإنترنت لضمان التسليم. - David Spillett


لماذا أحتاج إلى خادم SMTP وسيط لإرسال البريد؟ لماذا لا يستطيع عميلي (Outlook ، Thunderbird) إرسال الرسائل مباشرةً إلى نطاق SMTP الخاص بالمستلم؟

يمكنك إنشاء برنامج بريد إلكتروني يقوم بذلك ، وليس لدي شك في أن الآخرين فعلوا (أو حاولوا) ذلك من قبل.

من المفترض أن تقوم بكتابة أداة تمثل كل من MUA (وكيل مستخدم البريد) و MTA (وكيل نقل البريد) في أحدهما.

السبب في أن هذا عادةً ما يتم فصله إلى أدوات مختلفة ، مع MTA المقيمة "server-side" ، هو أن MTA الذي يرسل البريد عبر الإنترنت المفتوح يكون أكثر تعقيدًا للكتابة والتكوين ، بالإضافة إلى أنه يستفيد من الإقامة على موثوقة "دائما على" الخادم.

يجب على MTA:

  • ابحث عن الخوادم التي لا تثق بها أو اتصل بها ، أو التي قد تسيء التصرف ، والتعامل مع حالات الخطأ بطريقة معقولة لا تفقد البريد.

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

  • التعامل مع مجموعة من قدرات الخادم المختلفة ، وضبط السلوك وفقًا لإمكانيات خادم الاستلام.

  • أبلغ المستخدم عن حالات الخطأ أو عندما يكون البريد غير قابل للتسليم ، بحيث لا يتم فقد البريد فقط.

  • تمتع بممارسات أمان ممتازة وكن واعًا جدًا بالأمان.

  • من الناحية المثالية ، يمكنك الإقامة على خادم موثوق به متصل دائمًا مع عنوان IP ثابت وإدخال DNS عكسي ، أي اتصال إنترنت مناسب للخوادم المواجهة للعموم. يساعد ذلك الأنظمة الأخرى على عدم الكشف عن البريد المرسل كرسالة غير مرغوب فيها.

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


4
2017-12-01 01:09





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

يعد GMail و Outlook 365 و Yahoo Mail أمثلة على خدمات البريد الإلكتروني التي يستخدمها الأفراد الذين يرسلون البريد الإلكتروني. لإرسال البريد الإلكتروني التجاري ، هناك خدمات مثل MailChimp و Marketo و Eloqua جيدة جدًا في إرسال البريد الإلكتروني الجماعي لشركة ما والتعامل مع أشياء مثل الارتداد والاختناق وإمكانية التوصيل.

نرى: https://en.m.wikipedia.org/wiki/Bounce_address


1
2017-11-27 19:01



لا أفهم لماذا أحتاج إلى عنوان IP ثابت للحصول على ردي ... يجب تسليم الرد إلى خادم MX (مثل Gmail) وليس إلى الكمبيوتر. هل انا على حق؟ - Tobia
نعم انت على حق. أعتقد أن وجهة نظري هي أن علبة الوارد موجودة عادة على خادم في مكان ما لكي يتم إرسال البريد الإلكتروني الصادر. منطقياً ، من المنطقي أن يتعامل ذلك الخادم مع البريد الصادر أيضًا. وإلا فستفقد أشياء مثل وجود مجلد بريد إلكتروني "مرسل". - dana
لم يذكر اسمه: من المعقول. ولكنني حر في إرسال رسالة إلى Gmail تحتوي على عنوان "من" أو "replyto" غير معروف بإلغاء خادم SMTP الخاص به ... - Tobia
إذا كنت تستخدم GMail ، فيجب استخدام مصادقة smtp. لذلك ، تم تعيين عنوان FROM على عنوان @ gmail.com. وإلا ، فستتمكن من استخدام خدمتهم للانتحال. - dana
في هذه الأيام ، لا يهتم الكثير من المستخدمين بالارتدادات ، ولكن الإعداد الذي لا يقبل الارتداد يعتبر مصدرًا محتملًا للرسائل غير المرغوب فيها. - rackandboneman