راه اندازی ایمیل (بدون ایمیل در هرزنامه). از دست دادن پیام های پستی

راه اندازی ارسال ایمیل بدون وارد کردن آنها به اسپم.

امکان ارسال ایمیل از طریق سرورهای SMTP شخص ثالث (Mandrill، Mailgun، Yandex) و از طریق آدرس های شخصیمن خدمات پستی را در نظر نمی گیرم (همه چیز در آنجا بسیار ساده است، اگر دستورالعمل های نصب ارائه شده را دنبال کنید) - من فقط این گزینه را در نظر می گیرم که ما سرور خودمان را داریم که بر این اساس روی آن نصب شده است. سرور پست الکترونیکی، مانند exim (مانند اکثر هاست ها).

برای ویرایش رکوردهای DNS و حداقل مالکیت کنسول به دسترسی نیاز داریم تنظیمات DKIM(اگر ISPmanager وجود داشته باشد - و این مورد بی ربط می شود). در کل، باید 4 ورودی جدید را در رکوردهای DNS دامنه خود پیکربندی کنید (اضافه کنید): PTR, SPF, DKIMو DMARC.

• PTR- ضبط DNS به اصطلاح "معکوس". باید اجباری باشد، زیرا عدد بزرگخدمات پستی به نشانه نادرست آن غیرقابل تحمل است. در تئوری، باید توسط هاست شما نصب شود، به عنوان مثال DigitalOcean این کار را به صورت خودکار انجام می دهد. - اما یک گزینه و تنظیمات دستی آن وجود دارد.
• SPF- سابقه ای که نشان می دهد سرور شما مجاز به ارسال ایمیل از این دامنه و IP است. این سابقه وجود ندارد - ورود به هرزنامه تقریبا تضمین شده است. نصب بسیار ساده است - اطلاعات جامع با نمونه های راه اندازی را می توان در (اطلاعات در صفحه سبز) یا در به دست آورد.
• DKIM- امضای الکترونیکنامه های شما اگر دو تا هستند ورودی های قبلی- به دامنه و حروف شما "وزن" می دهد، که به لطف آن، همان Yandex، به عنوان مثال، حروف را با یک علامت سبز دلپذیر علامت گذاری می کند.

تنظیم این امضا شاید سخت ترین باشد - در نتیجه 90٪ سایت ها آن را ندارند، اما به شدت توصیه می شود. تنظیم آن در ISPmanager بسیار آسان است: پشتیبانی از DKIM را در برگه ویژگی‌ها در ویرایش فعال کنید. دامنه پستیچک باکس DKIM را علامت بزنید و ورودی آماده را در ویژگی های دامنه (NS) بگیرید. اگر ISPmanager وجود ندارد، به شما توصیه می کنم از این مقاله نسبتاً ساده استفاده کنید:.

• DMARC- استاندارد کاملاً جدید است، اما در حال حاضر به طور فعال توسط خدمات پستی اجرا می شود و امسال 100٪ باید داشته باشد. راه اندازی ساده ترین از تمام ورودی های بالا است، شما فقط باید یکی از نمونه های نشان داده شده در این صفحه زیر را اضافه کنید: - من دومی را توصیه می کنم.

سرور شما اکنون پیکربندی شده است و اگر همه چیز به درستی انجام شود، حتی یک حرف به هرزنامه نمی رود. به عنوان مثال، یک تصویر تأیید کننده از اداره پست mail.ru (وضعیت مشابه با غیبت کاملشناسایی ایمیل ها به عنوان هرزنامه و مطابق با Yandex):

راه اندازی جمع آوری نامه برگشتی.

XenForo مکانیزمی کاملاً شگفت‌انگیز دارد که تقریباً هیچ‌کس از آن استفاده نمی‌کند - جمع‌آوری کننده ایمیل برگشتی. من فکر می کنم همه با وضعیتی روبرو شده اند که پس از ارتکاب ارسال انبوهصندوق پستی تعداد زیادی نامه به شکل زیر دریافت می کند:

این پیام به طور خودکار توسط نرم افزار تحویل نامه ایجاد شد.

پیامی که شما ارسال کرده اید به یک یا چند مورد از آن تحویل داده نمی شود
گیرندگان این یک خطای دائمی است. آدرس(های) زیر ناموفق بود:

***@rambler.ru
خطای SMTP از سرور ایمیل راه دور پس از RCPT TO:<***@rambler.ru>:
میزبان imx1.rambler.ru : 540 5.7.1<***@rambler.ru>:
آدرس گیرنده رد شد: ایمیل های شما برگردانده شده است زیرا حساب ایمیل گیرنده مورد نظر به حالت تعلیق درآمده است. برای دریافت پیام های دریافتی، حساب باید دوباره فعال شود.

این ایمیل ها سیگنالی هستند که نشان می دهد کاربران شما آدرس های قدیمی دارند. پست الکترونیک(باکس ها مسدود، حذف شده، پر هستند)، یعنی نامه های جدیدی از شما دریافت نمی کنند و در صورت لزوم نمی توانند حساب خود را در انجمن بازیابی کنند. بسیاری از کاربران حتی نمی دانند که از یک آدرس ایمیل قدیمی استفاده می کنند، اما خدمات پستی، با دیدن تعداد زیادی ایمیل ارسال شده به آدرس هایی که وجود ندارند، می توانند دامنه شما را در لیست هرزنامه ها قرار دهند.

این باید مبارزه شود، زیرا حتی در انجمن من، جایی که این سیستم بیش از اولین لیست پستی کار می کند، در مقایسه با تعداد کاربران، نامه های "بازگردانده شده" زیادی وجود دارد:

• برای شروع، ما ایجاد می کنیم آدرس پستی، که نامه های برگشتی را به آن ارسال خواهیم کرد (جعبه یک سیستم است و نباید برای اهداف دیگری استفاده شود) - برای مثال جایی که google.com دامنه شماست.

• به بخش مدیریت بروید تنظیمات - تنظیمات ایمیل. در قسمت Return Address صندوق پستی را که ایجاد کرده اید وارد کنید. یک تیک بزنید پردازش خودکارنامه‌های تحویل‌نشده و داده‌های ورود به صندوق پستی سرویس خود را که قبلاً ایجاد کرده‌اید نشان می‌دهد: آدرس (در مورد سرور SMTP خودتان، سرور خود را مشخص کنید)، ورود به سیستم (آدرسی که ایجاد کرده‌اید) و رمز عبور از جعبه. من نمونه ای از تنظیمات خود را ارائه می دهم - من یک نامه تجاری از Mail.ru دارم - بنابراین، برای دریافت نامه از جعبه خدمات به سرور آنها متصل می شوم.

اساساً، این کل تنظیمات است. انجمن به طور خودکار در فواصل زمانی معینی به صندوق پستی سرویسی که مشخص کرده اید می رود، کپی نامه های برگشتی را که دریافت کرده است دانلود کرده و از آنجا حذف می کند. در بخش ابزار - گزارش شکست تحویل ایمیلمی توانید این آمار را مشاهده کنید. من به ویژه تأکید می کنم که این جعبه نمی تواند برای هیچ هدف دیگری استفاده شود، در غیر این صورت شما در معرض خطر ابتلا به برخی باگ های خنده دار در گزارش های پنل مدیریت هستید.

با توجه به شرایطی که تعیین کرده اید، هنگام بازگشت، به عنوان مثال، 3 نامه از یک آدرس، کاربر برای فعال سازی مجدد خودکار ارسال می شود - از او خواسته می شود آدرس ایمیل فعلی را نشان دهد و حساب را دوباره فعال کند. مشارکت شما الزامی نیست - کاربران خودشان آدرس ایمیل فعلی خود را نشان می دهند و بنابراین مشکل با گذشت زمان برطرف می شود. و هنگام ارسال پست، کاربرانی که آدرس ایمیل نادرست دارند می توانند از آن حذف شوند - در نتیجه از ضربه احتمالی در لیست های هرزنامه جلوگیری می شود.

متن های زیادی نوشته شده است، اما در واقع، اگر دقیقاً دستورالعمل ها را دنبال کنید، تنظیم همه چیز - هم سرور و هم جمع کننده نامه، چند دقیقه طول می کشد. یک بار آن را تنظیم کنید و فراموش کنید که ایمیل های انجمن شما به جایی نرسیده است یا دامنه شما در لیست های هرزنامه گنجانده شده است زیرا پایگاه داده قدیمی است.

برای ساده سازی برخی از کارهایی که در بالا توضیح داده شد، می توانید از هر کدام استفاده کنید - هر کدام که ترجیح می دهید. من از اولین مورد استفاده می کنم - اما انتخاب کاملاً به شما بستگی دارد. افزودن دامنه‌های خود در آنجا صندوق‌های پستی نامحدود و راحت با فیلترهای هرزنامه داخلی + مقداری ساده‌سازی تنظیمات سرور به شما می‌دهد (بعضی از رکوردها به‌طور خودکار ارائه می‌شوند (به استثنای DKIM، که باید به‌طور دستی برای ارسال نامه از سرور شما ایجاد شود. )).

نمونه نامه ها:

550 5.7.1 این پیام به دلیل خط مشی DMARC مالک دامنه (RFC 7489) پذیرفته نشد https://help.mail.ru/mail-help/postmaster/dmarc

550-5.7.1 ایمیل احراز هویت نشده از mail.ru به دلیل خط مشی DMARC 550-5.7.1 دامنه پذیرفته نمی شود. اگر این نامه 550-5.7.1 قانونی بود، لطفاً با مدیر دامنه mail.ru تماس بگیرید. لطفاً از 550 بازدید کنید. -5.7.1 https://support.google.com/mail/answer/2451690 برای آشنایی با DMARC

550 5.7.1 ایمیل بر اساس خط مشی DMARC برای ... رد شد

مشکل تحویل پیام مربوط به برنامه سیاست جدید DMARCمربوط به تشدید قوانین عبور از فیلترهای هرزنامه است.

DMARCیک پروتکل حفاظتی ضد هرزنامه و ضد هرزنامه از طرف یک دامنه، بر اساس مکانیسم های موجود است DKIM و SPF. سایت رسمی: dmarc.org.

اگر پیام‌هایی مشابه موارد فوق دریافت می‌کنید، به احتمال زیاد، ایمیلی از طرف سایت شما ارسال می‌شود صندوق پستیروی پایه @mail.ru, @bk.ru, @list.ruیا @inbox.ru. Mail.Ru پیام های ارسال شده از طریق phpmail را نمی پذیرد اگر سرصفحه های نامه حاوی صندوق پستی متعلق به mail.ru باشد. چنین پیام هایی طبق سیاست اعمال شده توسط Mail.Ru DMARC، رد می شوند.

چگونه یک مشکل را حل کنیم

دو راه برای حل مشکل وجود دارد:

روش 1: صندوق پستی که از آن پیام ها ارسال می شود را تغییر دهید

معمولا ایمیلی که از طرف آن پیام های ایمیل ارسال می شود، در بخش مدیریتی CMS ثبت می شود. همچنین می توان آن را مستقیماً در اسکریپتی که پیام می فرستد تغییر داد (فیلد "از").

برای مثال، لازم است که پیام ها از یک صندوق پستی بر اساس نام دامنه شما ارسال شود « [ایمیل محافظت شده]» ، جایی که domain.ru دامنه شماست. .

همچنین، صندوق پستی باید در فایل php.ini تغییر کند:

تغییر کادر در php.ini

1. 1 وارد کنترل پنل هاست شوید و فایل php.ini را برای ویرایش باز کنید: ;
2. 2

   یک خط مانند:
   

   sendmail_path = "/usr/sbin/sendmail -t -i -f [ایمیل محافظت شده]"

   در این خط، به جای « [ایمیل محافظت شده]» یک صندوق پستی غیر دامنه را مشخص کنید @mail.ru, @bk.ru, @list.ruو @inbox.ru.
   توصیه می شود یک صندوق پستی در دامنه خود مشخص کنید، به عنوان مثال، « [ایمیل محافظت شده]» ، جایی که domain.ru دامنه شماست.

   علاوه بر این، صندوق پستی مشخص شده در php.ini باید وجود داشته باشد. اگر از نامه در هاست استفاده می کنید، یک صندوق پستی در دامنه ایجاد کنید و آن را در فایل php.ini ثبت کنید.

روش 2: از مجوز SMTP استفاده کنید

با تنظیم مجوز SMTP می توانید از طرف صندوق پستی خود بر اساس Mail.Ru پیام ارسال کنید. در این صورت تمام پیام ها از طریق سایت شما مستقیماً از سرورهای Mail.Ru ارسال می شود.

اشتباهات سیستم پستیکدهایی هستند که در زمان دریافت یا رد دریافت به پیام ها اختصاص داده می شوند. کد خطا به شما امکان می دهد دلیل عدم امکان تحویل را پیدا کنید پیام پستی. به طور معمول، کد خطا یک عدد است، مانند #550 یا #2001. کدهای خطا در زیر توضیح داده شده است.

پیام های بدون کد

آدرس غیر قابل مسیریابی

تعیین سرور برای ارسال پیام ایمیل به آن انجام نشد. دلایل ممکن:

• دامنه ای که نامه به آن ارسال می شود وجود ندارد یا واگذار نشده است
• نه رکوردهای MX و نه A برای دامنه ثبت نشده است
• رکورد MX به نامی که وجود ندارد اشاره می کند

کاربر ناشناخته

این صندوق پستی وجود ندارد، یا آدرس پستی نادرست است

انتقال در حال انجام است. گوش به زنگ باشید

پیام هنگام ارسال ایمیل رخ می دهد مشتری ایمیل. این پیام از سیستم ایمیل ما نیست. یعنی کاربر دارد شبکه محلییک آنتی اسپم یا فایروال وجود دارد که تمام ایمیل های ارسالی را بررسی می کند.

بیش از سهمیه

خطای LMTP پس از پایان داده ها: 552 5.2.2 بیش از سهمیه
این خطا زمانی رخ می دهد که صندوق پستی گیرنده پر باشد.

پیام های دارای کد

#1005

فرستنده تأیید تماس ناموفق بود
بررسی فرستنده نامه این خطا می تواند کامل باشد، همانطور که در زیر نشان داده شده است، یا به اختصار: "Sender verify named [#1005]". یک خطا توسط برخی از سرورهایی که پیاده سازی کرده اند ارسال می شود تلاش ناموفقیک ایمیل به سرور ما ارسال کنید. سرور ما در خط "... هنگام صحبت با mx3.site.:" فهرست شده است.

آدرس های زیر دارای خطاهای مرگبار دائمی هستند ----- (دلیل: 550-تأیید نشد ) ----- رونوشت جلسه به شرح زیر است ----- ... هنگام صحبت با mx3.site.: >>> ایمیل از: SIZE=523<<< 550-Verification failed for <<< 550-User unknown (200) <<< 550 Sender verify failed [#1005]. 554 5.0.0 Service unavailable

آدرس [ایمیل محافظت شده]- این آدرس گیرنده نامه است، فقط جهت کامل بودن ارائه شده است.
آدرس فرستنده [ایمیل محافظت شده]همانطور که در پیام نوشته شده بود آزمون را قبول نکرد.

برای هر حرف، فرستنده بررسی می شود. برای انجام این کار، سرور ما سعی می‌کند به سروری که نامه‌های مربوط به دامنه فرستنده را دریافت می‌کند (در مثال، example.com) متصل شود و یک ایمیل از آدرس ارسال کند.<>» به آدرس فرستنده (در مثال [ایمیل محافظت شده]). چنین ایمیل هایی باید همیشه پذیرفته شوند، زیرا پیام های مربوط به تحویل ناموفق به این شکل است. اگر سرور پاسخ دهد که چنین صندوق پستی وجود ندارد (در مثال، سروری که دامنه example.com را ارائه می‌کند به «550-User ناشناخته (200)» پاسخ داد) یا تلاش را به دلایل دیگر رد کرد، سپس نامه‌ای از آدرس [ایمیل محافظت شده]قابل قبول نیست.

بررسی آدرس برگشتی محافظت از هرزنامه نیست (اگرچه به فیلتر کردن برخی از آن کمک می کند). سرور باید بتواند پیامی را برای فرستنده ارسال کند در صورتی که قادر به تحویل پیام به گیرنده نبود. برای تضمین این امکان، آدرس برگشت بررسی می شود.
در این صورت شما از مشکل آگاه هستید زیرا سرور ما پیام را نپذیرفت (نشان دهنده مشکلات ارتباطی با دامنه فرستنده) و سرور ارسال کننده این موضوع را به فرستنده گزارش داد. اگر سرور ما پیام را بدون بررسی امکان تحویل برگشت پذیرفته بود، شما از مشکل مطلع نبودید.

نامه ای با آدرس برگشت نادرست مشکلی است که باید حل شود، اما در هیچ موردی با غیرفعال کردن ابزاری که به آن سیگنال می دهد، حل نمی شود.

#1004

متأسفیم، ما پیام‌های میزبان‌ها را بدون سابقه PTR نمی‌پذیریم
این خطا زمانی رخ می دهد که گره فرستنده رکورد PTR نداشته باشد.

#1007

ما آدرس های IP پویا را نمی پذیریم، لطفاً از smtp ارائه دهنده خود استفاده کنید [#1007]یا آی پی پویا رد شد [#1007]
این خطا برای کاربرانی رخ می دهد که از یک مجموعه آدرس پویا برای اتصال خود استفاده می کنند. بررسی بر اساس آدرس IP کاربر (وجود کلمات dial، ppp، pool، dsl، dynamic، static و موارد دیگر در آن) انجام می شود.

#1008

تأیید فرستنده انجام نشد
ایمیل از هدر جلسه smtp حاوی یک آدرس برگشتی نامعتبر است (مثلاً یک دامنه وجود ندارد).

#1009

ما آدرس های IP پویا را نمی پذیریم، لطفاً از smtp ارائه دهنده خود استفاده کنید [#1009]
این خطا عمدتاً برای کاربرانی که از اتصالات DSL یا DialUp استفاده می کنند و از رایانه محلی خود نامه می فرستند و به عبارت دیگر از سرور SMTP ارائه دهنده خود استفاده نمی کنند رخ می دهد. چک بر اساس یک عبارت منظم برای:
^((1,3)\D+)(2)((1,3)[^\d\.]*).*\.(\w|-)+\.\w(2,4)$
اگر به دلایلی نمی توانید از سرور SMTP ارائه دهنده خود استفاده کنید، یک درخواست برای پشتیبانی فنی بنویسید که آدرس IP خود را نشان می دهد، به لیست سفید اضافه می شود.

#1014

نامه رد شد، به http://www.spamcop.net/w3m?action=checkblock&ip= آدرس IP مراجعه کنید [#1014]
ما از لیست سیاه DNS spamcop.net برای محافظت از هرزنامه استفاده می کنیم. آدرس فرستنده در لیست سیاه spamcop.net است

#1020

رله مجاز نیست
تلاشی برای ارسال ایمیل به دامنه‌ای که توسط سرورهای ایمیل ما ارائه نمی‌شود، انجام شد.

#1024

تأیید گیرنده ناموفق بود
بررسی گیرنده نامه اگر دامنه توسط سرورهای ما ارائه شود، خطا رخ می دهد، اما چنین آدرسی در دامنه وجود ندارد.

#1025

پیام تأیید گیرنده ناموفق بود
بررسی گیرنده نامه اگر سرور راه دور پاسخ دهد که چنین گیرنده ای وجود ندارد، خطایی رخ می دهد.

#1305

شما پیام های زیادی ارسال می کنید
از محدودیت ارسال ایمیل از طریق smtp فراتر رفته است. برای افزایش محدودیت، باید با خدمات پشتیبانی فنی تماس بگیرید.

#2002

احراز هویت لازم است
برای ارسال، باید با نام کاربری و رمز عبور احراز هویت کنید.
نمونه هایی از پیکربندی صحیح کلاینت های ایمیل را می توان مشاهده کرد

مبارزه با هرزنامه برای همه مدیران مسئول ایمیل دردسر است. چیزی که آنها برای بهتر کردن زندگی کاربران مورد علاقه خود اختراع نمی کنند. با این حال، همانطور که تمرین برقراری ارتباط با بسیاری از مدیران سیستم نشان داده است، به دلایلی، همه نمی دانند چگونه به درستی اسپم را فیلتر کنند.

رایج ترین رویکرد این است که "یک دسته RBL (DNSBL) اضافه کنید و از زندگی لذت ببرید". این رویکرد کمی بیشتر از کامل درست نیست. دومین فیلتر محبوب، فیلترهای محتوا است که اغلب با پول کلان خریداری می شود. این رویکرد نیز در بیشتر موارد کاملاً غیر قابل توجیه است.

اما همه چیز بسیار ساده است، برای یک زندگی آرام، کافی است به سه سرصفحه جلسه SMTP ورودی با دقت نگاه کنید. با جست و جو در هابره و خیابان های عقب اینترنت، مقاله جامعی در مورد تنظیم صحیح سرور SMTP از نظر مقابله با هرزنامه ها پیدا نکردم. بنابراین، تصمیم گرفتم هر آنچه را که می دانم در این موضوع خودم و آنچه با موفقیت استفاده می کنم نقاشی کنم.

به هر حال: این مقاله البته در درجه اول مدیرانی است که می خواهند یک فیلتر اسپم با کیفیت بالا ایجاد کنند. با این حال، از سوی دیگر، حاوی اطلاعات بسیار مهمی برای کسانی است که به سادگی باید با پست کار کنند، اما در تمام پیچیدگی های فرآیند ارسال نامه الکترونیکی آشنایی کافی ندارند.

بنابراین، اگر می خواهید از کاربران خود در برابر هرزنامه ها محافظت کنید، یا برعکس، اگر می خواهید شخصی به طور تصادفی از کاربران در برابر نامه های شما محافظت نکند - به زیر گربه خوش آمدید.

یک نکته کوچک: مقاله با توجه به راه اندازی یک سرور ایمیل نوشته شده است پسوند، اما به طور کلی نسبتاً نظری است. گزینه های Postfix شرح داده شده باید در قسمت مربوطه مشخص شوند *_محدودیتگزینه های فایل پیکربندی، برای جزئیات بیشتر به هر راهنمای پیکربندی Postfix مراجعه کنید.

کمی در مورد پروتکل SMTP

ایمیل شباهت های زیادی با نامه های معمولی دارد. اکنون مهمترین چیز برای ما این است که تمام اطلاعات روی "پاکت" الکترونیکی فقط دو آدرس است: گیرنده و فرستنده و همچنین مهر پستچی که پاکت را تحویل داده است.

بیایید کمی منحرف شویم: تصور کنید که فردی با ظاهر بسیار نفرت انگیز به سمت شما می آید و بسته ای محکم با آدرس برگشت "Tryam from Tilimilithryamdia" به شما تحویل می دهد. جرات پذیرش و باز کردن؟ به ندرت. بنابراین، ایمیل نیز تنها بر اساس اطلاعات آدرس می تواند به راحتی بررسی و فیلتر شود، و دامنه اقدامات ممکن در اینجا بسیار گسترده تر است.

همانطور که باید آگاه باشید، ایمیل در اینترنت با استفاده از پروتکل SMTP بین سرورهای پست الکترونیکی منتقل می شود. هر ارتباطی با استفاده از این پروتکل با سه هدر اجباری شروع می شود: سلام, پست ازو RCPT به. یعنی قبل از شروع به انتقال هر داده، سرور ابتدا خود را ارائه می دهد (HELO)، سپس آدرس برگشتی فرستنده (MAIL FROM) و سپس آدرس گیرنده (RCPT TO) را گزارش می دهد. این سه سربرگ امضای روی پاکت الکترونیکی هستند و تقریباً تمام هرزنامه ها را می توان فقط بر اساس تجزیه و تحلیل آنها فیلتر کرد. بیشتر تلاش‌ها برای ارسال چیزی به سرور من، از MAIL FROM عبور نمی‌کنند، یعنی پیام‌ها قبل از پذیرش واقعی فیلتر می‌شوند، که بارگذاری را تا حد زیادی کاهش می‌دهد. یعنی به جای اینکه بسته را از Tryam باز کنم و هاگ سیاه زخم را آنجا پیدا کنم، بلافاصله پستچی را به جهنم می فرستم.

بنابراین، برای جلوگیری از دریافت ایمیل هایی که به عنوان اسپم شناخته می شوند، چه باید کرد؟ به ترتیب بریم

کمی در مورد DNS

در روزهای اولیه اینترنت، نامه به طور مستقیم به میزبان های مشخص شده در آدرس پستی تحویل داده می شد. یعنی نامه ای به [ایمیل محافظت شده]سرور ایمیل آدرس IP domain.com را جستجو کرد و سعی کرد بسته ای را به IP یافت شده ارسال کند. سپس رکوردهای MX ظاهر شد که به یکباره اکثر مشکلات چنین سازمانی از تعامل نامه را حل کرد. با این حال، برخی از برنامه‌ها همچنان می‌توانند هنگام تحویل نامه با رکوردهای A کار کنند. اما مطمئناً حداقل یک رکورد MX برای دامنه خود دارید، اینطور نیست؟

رکوردهای MX حاوی آدرس های سرور هستند، بر رویکه باید نامه هایی برای دامنه مشخص شده تحویل داده شود. با این حال، به منظور مبارزه با هرزنامه، یک فناوری ظاهر شده است که به شما امکان می دهد در DNS آدرس سرورها را نیز مشخص کنید. از جانبکه می تواند حروف را از دامنه مشخص شده دریافت کند. نام آن چارچوب سیاست فرستنده است.

من با جزئیات وارد تمام پیچیدگی های فناوری نمی شوم، فقط می گویم که رکورد TXT

V=spf1 +mx-all

همیشه یک رکورد SPF برای دامنه تنظیم کنید، و همچنین بررسی SPF را در سرورهای ایمیل خود فعال کنید. من توصیه می کنم ایمیل ها را از دامنه خود از همه میزبان ها به جز سرورهای MX خود ممنوع کنید. همراه با بررسی SPF در سرور شما، چنین تنظیماتی بلافاصله تمام نامه‌های ارسال شده از میزبان‌های شخص ثالث از طرف کاربران دامنه شما به آدرس‌های کاربران دامنه شما را قطع می‌کند. و تقریباً نیمی از این هرزنامه ها، زیرا معمولاً سرورهای SMTP در برابر حروف دامنه خود بسیار ضعیف محافظت می شوند و هرزنامه ها به طور فعال از آن استفاده می کنند. SPF یک بار برای همیشه شما را از نامه هایی به Vasya Pupkin که بر اساس پاکت نامه نوشته شده توسط Vasya Pupkin اما از سروری در برخی از نیکاراگوئه نوشته شده اند، نجات می دهد.

گوگل به شما می گوید که چگونه SPF را در Postfix پیکربندی کنید، اطلاعات زیادی وجود دارد و شما نمی توانید اشتباه کنید، بنابراین ما زمان را برای جزئیات فنی تلف نمی کنیم.

چند نکته بسیار مهم در مورد DNS وجود دارد. احتمالاً می دانید که رکوردهای DNS اصلی، به اصطلاح رکوردهای A، یک نام را به آدرس IP ترجمه می کنند. علاوه بر آنها، رکوردهای CNAME نیز وجود دارد که نام مستعار را به نامی که از قبل موجود است اختصاص می دهد. این دو نوع رکورد هستند که اساس کل سیستم نام دامنه را تشکیل می دهند.

اما تعداد کمی از کاربران می دانند که سوابق معکوس نیز وجود دارد که IP را به نام دامنه تبدیل می کند. آنها PTR نامیده می شوند. بنابراین، دو قانون نانوشته (به بیان دقیق) وجود دارد که همه هنوز از آنها پیروی می کنند:

• برای هر رکورد A باید وجود داشته باشد آینهرکورد PTR، یعنی با نام میزبان از طریق DNS IP دریافت می کنیم و با IP همان نام میزبان را برمی گردانیم.
• آدرس در رکورد MX همیشه باید باشد نام(نه IP!) میزبانی که یک ورودی برای آن وجود دارد. یعنی نمی توانید IP یا نام مستعار (CNAME) در رکورد MX داشته باشید.

اگر یکی از این شرایط را ندارید، آماده باشید که حداقل یک چهارم ایمیل از دامنه شما به عنوان هرزنامه شناخته شود. این به دلیل یک تز ساده است: یک فرستنده قابل اعتماد همیشه همه چیز را با رعایت قوانین تنظیم می کند، به ترتیب، اگر قوانین رعایت نشود، نباید به فرستنده اعتماد کرد، به این معنی که شما نیز نباید از او نامه دریافت کنید.

خوب، برای فعال کردن PTR check برای خود، از گزینه استفاده کنید

Reject_unknown_client_hostname

این مستلزم آن است که IP که از آن اتصال برقرار شده است از طریق PTR به یک نام تبدیل شود و این نام نیز به نوبه خود به IP مورد نظر بازگردد.

همچنین یک محدودیت کمتر سختگیرانه توسط این گزینه وجود دارد

Reject_unknown_reverse_client_hostname

در این حالت سرور فقط وجود یک رکورد PTR را بررسی می کند، اما نیازی به وجود رکورد A مربوطه نخواهد داشت.

بررسی سلام

بنابراین، شخصی می خواست نامه ای به سرور شما ارسال کند. انتقال با یک سلام آغاز می شود - هدر HELO. HELO باید به ترتیب حاوی نام دامنه کاملا واجد شرایط (FQDN) فرستنده باشد، اگر اینطور نیست، می توانید با خیال راحت از پذیرش آن بلافاصله خودداری کنید. Postfix دو گزینه برای این کار ارائه می دهد:

Reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname

اولی دریافت پیام از میزبان هایی را که با نحو نادرست پیام تبریک ارسال می کنند، غیرفعال می کند، دومی - از میزبان هایی که یک غیر FQDN را در یک درخواست HELO ارسال می کنند.

با این حال، فقط احمق ترین هرزنامه ها (و محصولات MS، اما همانطور که می دانید قوانین برای آنها نوشته نشده است) FQDN ها را منتقل می کنند، از این گذشته، معرفی خود به عنوان gmail.com دشوار نیست. بنابراین، ما باید نگاه دقیق تری به HELO بیندازیم. برای این، گزینه

Reject_unknown_helo_hostname

که دریافت نامه هایی از سرورهایی را که به نظر آدرسی هستند که هیچ رکورد A یا MX برای آن وجود ندارد، ممنوع می کند.

فرستنده - آیا باید به او اعتماد کرد؟

بنابراین، سرور با موفقیت خود را به شما معرفی کرد، مورد بعدی در برنامه آدرس فرستنده است. همچنین می توانید اطلاعات مفید زیادی از آن استخراج کنید. می‌خواهم فوراً توجه داشته باشم که آدرس فرستنده نباید از همان دامنه خود سرور باشد. این یک تصور غلط رایج است، بنابراین توجه داشته باشید که اینطور نیست. یک سرور ایمیل می تواند به راحتی چندین دامنه را ارائه دهد.

با این حال، اگر آدرس فرستنده حاوی دامنه‌ای باشد که اصلاً وجود ندارد، واضح است که نامه ارزش پذیرش ندارد. و قطعاً نامه ای را که در آن چیزی به عنوان آدرس برگشتی درج شده باشد که اصلاً آدرس نیست را قبول نکنید. دو گزینه برای امتناع از پذیرش چنین نامه هایی وجود دارد:

Reject_non_fqdn_sender
reject_unknown_sender_domain

اول بررسی آدرس برای املا، دوم بررسی وجود دامنه.

این خیلی خوب است، اما کارهای بیشتری می توان انجام داد. می توانید از سروری که آدرس فرستنده مشخص شده را ارائه می دهد پرس و جو کنید تا ببینید آیا کاربری با آن آدرس در آن وجود دارد یا خیر. در واقع، به نظر می رسد ایده خوبی باشد که مطمئن شویم آدرس برگشتی واقعاً وجود دارد، در غیر این صورت ممکن است نامه ای از یک فانتوم زودگذر دریافت کنیم که هیچ کس تا به حال نام آن را نشنیده است.

از نظر فنی، این بسیار ساده اجرا می شود: سرور ما یک جلسه SMTP شمارنده را باز می کند و سعی می کند نامه ای را به آدرس فرستنده ارسال کند. اگر بتوان با این آدرس مرحله ارسال RCPT TO را با موفقیت پشت سر گذاشت، یعنی. اگر سرور دریافت کننده به طور ناگهانی اعلام نکند که صندوق پستی مشخص شده روی آن نیست، در نظر گرفته می شود که آدرس برگشتی ارسال شده به ما وجود دارد. به طور طبیعی، هیچ داده ای (یعنی یک نامه) در طول بررسی ارسال نمی شود، جلسه پس از RCPT TO قطع می شود.

گزینه

Reject_unverified_sender

با توجه به موارد بالا، چنین استنباط می شود که برای هر آدرسی که از دامنه خود نامه ارسال می کنید، باید یک صندوق پستی روی سرور شما وجود داشته باشد. در غیر این صورت، نامه های شما از بررسی آدرس برگشت از طرف گیرنده عبور نمی کند و بر این اساس به مقصد تحویل نمی شود. این در مورد همه نوع پستی و سایر انواع ارتباطات یک طرفه که نیازی به پاسخ ندارند صادق است. همیشه برای همه آدرس هایی که از آنها نامه ارسال می کنید، صندوق پستی ایجاد کنید. اگر نمی‌خواهید به یک آدرس پاسخ دریافت کنید، کافیست به آن ایمیل در /dev/null ارسال کنید، اما نمی‌توانید این ایمیل‌ها را بپذیرید. موظف است.

آیا گیرنده اصلا وجود دارد؟

بنابراین به آخرین هدر پاکت - به گیرنده رسیدیم. همه چیز در اینجا ساده است: اولاً، خوب است بررسی کنیم که اطلاعاتی که به ما منتقل می شود به طور کلی یک آدرس ایمیل است. برای این، بخشنامه

Reject_non_fqdn_recipient

علاوه بر این، ما نمی‌خواهیم نامه‌هایی را به آدرس‌هایی که صندوق پستی برای آنها نداریم بپذیریم. برای پیکربندی این رفتار، ابتدا باید لیستی از صندوق های پستی ارائه شده ایجاد کنید، سپس از طریق یکی از آنها به Postfix در مورد آن بگویید. *_نقشه_گیرندهپارامترهای فایل پیکربندی، خوب، سپس از پارامتر فایل پیکربندی استفاده کنید

smtpd_reject_unlisted_recipient = بله

یا با یک گزینه غیرفعال که همان اثر را دارد:

Reject_unlisted_recipient

در هر صورت، Postfix پذیرش ایمیل را متوقف خواهد کرد. برای دامنه های پذیرفته شدهاگر صندوق پستی برای گیرنده وجود نداشته باشد. با این حال، این محدودیت بر ارسال نامه به آدرس‌هایی که در دامنه‌های پذیرفته‌شده نیستند تأثیری نخواهد داشت.

و در نهایت، می توانید به طور کلی ارسال باز نامه ها را از طریق Postfix خود غیرفعال کنید و فقط امکان دریافت نامه ها را به آدرس های شناخته شده باقی می گذارید. برای این منظور، گزینه

Reject_unauth_destination

از ارسال ایمیل به همه کاربران ثبت نشده جلوگیری می کند (بله، شما باید مجوز SMTP را پیکربندی کنید). همیشه از این گزینه استفاده کنید!در غیر این صورت، به سرعت وارد انواع DNSBL ها خواهید شد.

به عنوان یک جمع فرعی

به این ترتیب می توانید حجم عظیمی از هرزنامه ها را بر اساس تجزیه و تحلیل سه هدر پاکت فیلتر کنید. با این حال، هرزنامه ها حیله گر هستند، بنابراین این هنوز کافی نیست.

فهرست خاکستری

گاهی اوقات سرورهای ایمیل بیش از حد بارگذاری می شوند و نمی توانند نامه را بپذیرند. فکر می کنید در این مورد چگونه به درخواست های دریافتی پاسخ می دهند؟ به اندازه کافی عجیب، آنها پاسخ می دهند - سرور به طور موقتدر دسترس نیست، لطفاً بعداً دوباره امتحان کنید. هیچ یک از فرستنده های عادی هرگز در این مورد فکر نمی کنند که نامه ای با تمام عواقب بعدی قابل تحویل نیست. در مقابل، فرستنده با قرار دادن نامه در صف ارسال، سعی می کند نامه را بعداً تحویل دهد. این واقعیت را می توان (و بدون شک باید!) بسیار مؤثر مورد استفاده قرار داد: در هر اولین تلاش برای اتصال از یک میزبان ناآشنا، سرور ما یک پیام خطای موقت ارسال می کند و فقط برای بار دوم اجازه ارسال پیام را می دهد. این کار تقریباً تمام هرزنامه‌های باقی‌مانده را به یکباره فیلتر می‌کند، زیرا سرورهای هرزنامه تقریباً هرگز بیش از یک بار تلاش نمی‌کنند تا نامه‌ای را تحویل دهند (در غیر این صورت به سادگی از سرریز شدن صف «افتاده» می‌کنند). این فناوری Greylisting نام دارد و استفاده از آن در واقعیت های مدرن به سادگی ضروری است.

نقطه ضعف برنامه تاخیر کوچک (معمولاً بیش از نیم ساعت) در تحویل نامه است. در ابتدااتصال از یک میزبان ناشناس یعنی اگر سروری که هنوز برای postfix ما شناخته نشده است بخواهد نامه ای ارسال کند، در اولین تلاش برای اتصال، خطای عدم دسترسی موقت به آن ارسال می شود. اگر سرور دوباره سعی کند وصل شود، نامه پذیرفته می شود و سرور در گره های قابل اعتماد وارد می شود و نامه های بعدی از آن بدون تاخیر دریافت می شود.

همچنین پیشنهاد می کنم در مورد راه اندازی لیست خاکستری در پست فیکس در گوگل مطالعه کنید، این کار آسان است و نمی توانید اشتباه کنید.

فهرست‌های بلاک یا کارهایی که نباید انجام داد

برخی از مدیران ایمیل برای فیلتر کردن هرزنامه ها به DNSBL ها (RBL) متکی هستند - لیست سیاه میزبان هایی که در حال ارسال هرزنامه هستند. پس اینجاست هرگزاضافه نکن بدون بررسی DNSBLبه سرورهای ایمیل شما دو دلیل برای این امر وجود دارد: اولین و مهمترین آن در قسمت دوم جمله اول این بخش نهفته است. هاست ها به صورت کاملا تصادفی وارد این لیست ها می شوند و هیچ تضمینی وجود ندارد که یک هاست معمولی به آنجا نرسد (که شاید در مقطعی ویروسی که هرزنامه می فرستد تسویه شود، اما اکنون ویروس قبلاً درمان شده است یا آسان تر و خیلی زیاد است. واقعی تر - یک IP خارجی برای یک شبکه بزرگ که در آن یک هرزنامه شروع شده است). دلیل دوم پیش پا افتاده تر است: مکانیسم فیلتر پیشنهادی در بالا بسیار کارآمدتر از هر DNSBL است و به داده های تایید نشده از اشخاص ثالث متکی نیست.

وارونه، یا از آن سوی سنگرها نگاه کنید

ما یاد گرفتیم که چگونه هرزنامه ها را فیلتر کنیم، اما اکنون سعی می کنم تمام اطلاعات مربوط به این موضوع را که باید انجام شود برای نهوارد اسپم شوید

برای مدیران سرور ایمیل:

• همیشه رکوردهای MX را به رکوردهای A ارجاع دهید.
• رکورد A برای سرور ایمیل همیشه باید یک رکورد PTR آینه ای داشته باشد.
• میزبان در هدر HELO باید یک رکورد A یا MX داشته باشد.
• همیشه رکوردهای SPF ایجاد کنید (بله، بله، این فقط ضروری نیست، اما فقط یک تمرین خوب است).
• برای تمام نامه‌های ارسال شده از یک دامنه پذیرفته شده، یک جعبه آدرس برگشتی باید وجود داشته باشد و نامه را بپذیرد.

برای کسانی که نامه ارسال می کنند (از برنامه ها، وب سایت ها و غیره):

• همیشه نامه را فقط با یک آدرس برگشتی موجود ارسال کنید.
• هرگز بدون بررسی قوانین SPF از دامنه ای که کنترل آن را ندارید، نامه ارسال نکنید. به عنوان مثال، gmail.com در حال حاضر به شما امکان می دهد نامه هایی را از طرف خود به هر سروری ارسال کنید، اما yandex.ru و mail.ru از طریق SPF گزارش می دهند که ارسال از طرف آنها از سرورهای شخص ثالث باید توجه زیادی را به خود جلب کند، که توسط smart تفسیر می شود. فیلترهای هرزنامه به عنوان افزایش امتیاز هرزنامه برای یک ایمیل معین.
• هرگز از طریق سرورهای SMTP پیکربندی نادرست نامه ارسال نکنید. طبق لیست بالا سرور را برای شپش بررسی کنید - این ابزار در مدت 5 دقیقه به شما کمک می کند حفر کردنیا nslookup.

خلاصه

البته تنظیمات پیشنهادی همه هرزنامه ها را فیلتر نمی کند. بنابراین، کاملاً ممکن است که شما نیاز به استفاده از فیلتر زمینه داشته باشید که محتوای ایمیل ها را تجزیه و تحلیل می کند، به عنوان مثال،

وقتی با استفاده از حساب ایمیل خانگی خود در حالی که خارج از خانه هستید پیام ایمیلی ارسال می کنید، ممکن است پیام با خطای 550، 553 یا رله برگردد. زمانی که خارج از دفتر هستید و می‌خواهید با استفاده از حساب ایمیل کاری خود ایمیلی ارسال کنید، همین اتفاق می‌افتد.

شرح

رله زمانی اتفاق می‌افتد که یک پیام ایمیل به آدرس ایمیلی ارسال می‌شود که دامنه آن (نام پس از نماد @، مانند adatum.com) توسط پروتکل SMTP یا سرور ایمیل خروجی که درخواست تحویل پیام را از فرستنده دریافت می‌کند، پردازش نمی‌شود. سرور SMTP برای ارسال پیام باید به سرور SMTP دیگری متصل شود.

اگر هنگام ارسال یک پیام ایمیل خطای رله رخ دهد، سرور SMTP (ایمیل خروجی) شما ممکن است پیام شما را همراه با یک پیام خطایی مانند زیر برگرداند:

موضوع:<тест>، حساب:<тест>، سرور: ، پروتکل: SMTP، پاسخ سرور: "550 Relay Denied، پورت: 25، امن (SSL): هیچ، خطای سرور: 550، شماره خطا: 0x800CCC79".

"پیام ارسال نشد زیرا سرور از پذیرش آدرس یکی از گیرندگان خودداری کرد. آدرس در نامه مشخص شده بود:<адрес эл. почты>. موضوع:<тест>، حساب:<тест>، سرور: ، پروتکل: SMTP، پاسخ سرور: "553 متأسفانه، این دامنه در لیست میزبان های مجاز من نیست (#5.7.1)"، پورت: 25، امنیت (SSL): خیر، خطای سرور: 553، شماره خطا: 0x800CCC79 "

متن دقیق پیام خطا به ISP شما بستگی دارد. برخی از ارائه دهندگان هنگامی که پیام های خروجی را به عنوان هرزنامه شناسایی می کنند، پیغام خطایی را باز نمی گردانند. در این موارد، به نظر می‌رسد که پیام شما به طور عادی ارسال می‌شود (در Outlook، در قسمت باقی می‌ماند برونگراو در پوشه ظاهر می شود ارسال شد، اما به گیرنده تحویل داده نمی شود.

پیام شما رد شد زیرا سرور SMTP (ایمیل خروجی) شما را به عنوان یک کاربر مجاز شناسایی نکرد.

SMTP یک پروتکل (استانداردهایی است که توسط رایانه ها برای برقراری ارتباط استفاده می شود) که توسط اکثر سرورهای ایمیل برای ارسال پیام در اینترنت استفاده می شود. اگر از یک برنامه ایمیل (مانند Outlook) استفاده می کنید که به شما امکان می دهد پیام ها را در رایانه خود ذخیره کنید، برای ارسال پیام باید به یک سرور SMTP دسترسی داشته باشید.

توجه داشته باشید:سیستم های ایمیل مبتنی بر وب (مانند Windows Live Mail یا Yahoo! Mail) متفاوت عمل می کنند و در این مقاله به آنها پرداخته نمی شود.

هرزنامه و رله باز

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

هنگام ایجاد ساختار اولیه اینترنت، هیچ کس عواقب ارسال میلیون ها پیام ناخواسته را با هزینه ناچیز پیش بینی نکرد. از طریق قابلیت رله سرورهای SMTP، فرستنده‌های هرزنامه منبع واقعی هرزنامه را با عبور دادن آن از طریق سرورهای شخص ثالث که اجازه چنین رله‌های باز را می‌دهند، پنهان می‌کنند. در نتیجه، به نظر می رسد هرزنامه از سایتی می آید که پیام را ارسال می کند و هویت فرستنده واقعی را پنهان می کند.

تا همین اواخر، اکثر سرورهای ایمیل SMTP بر اساس یک سیستم باز قابل اعتماد بودند. در چنین سیستمی، هر کسی از هر کجا می‌تواند یک پیام ایمیل به سرور SMTP ارسال کند و سرور باید آن را بپذیرد و آن را به گیرنده یا سرور پست دیگری که میزبان صندوق پستی گیرنده است، ارسال کند. با استفاده از این رله باز، هیچ محدودیتی برای جلوگیری از ارسال نامه توسط یک سرور SMTP وجود ندارد.

محدودیت های ISP در رله نامه

با افزایش حجم هرزنامه ها، مدیران شبکه (افرادی که مسئول مدیریت سرورهای ISP هستند) شروع به اعمال محدودیت بر روی سرورهای ایمیل SMTP خود کرده اند. این محدودیت ها مانع از استفاده همه از سرور پست می شود. تصور کنید در لابی سازمان شما تلفنی وجود دارد که برای همه از جمله کسانی که کارمند سازمان نیستند در دسترس است. اکنون فقط کارمندان مجاز به استفاده از تلفن هستند.

امروزه چندین نوع محدودیت در حال استفاده است.

به احراز هویت SMTP نیاز دارد.همانطور که از نام کاربری و رمز عبور برای دسترسی به سرور POP3 (ایمیل ورودی) و پیام های ایمیل خود استفاده می کنید، برای ارسال پیام های ایمیل از طریق سرور SMTP باید نام کاربری و رمز عبور را وارد کنید. این معمولاً همان نام کاربری و رمز عبور سرور POP3 است، اما ممکن است منحصر به فرد باشد.

ابتدا باید به سرور POP3 (ایمیل ورودی) ISP خود متصل شوید.برای دریافت پیام‌های ایمیل جدید، معمولاً به سرور POP3 (صندوق ورودی) متصل می‌شوید. برای دسترسی به صندوق پستی خود باید یک نام کاربری و رمز عبور وارد کنید. سرپرست شبکه می‌تواند سرور را به گونه‌ای پیکربندی کند که اگر ابتدا به سرور POP3 ورودی متصل شده و احراز هویت را انجام دهید، تمام درخواست‌های ارسال پیام‌های ایمیل از طریق سرور SMTP خروجی را تأیید می‌کند، که در غیر این صورت محدود می‌شود.

نیاز به اتصال از یک مکان مجاز در شبکه دارد.اگر از خانه خود از طریق خط تلفن، کابل یا مودم DSL به یک ISP متصل شوید، اتصال مستقیماً به شبکه ISP می رود. شما قابل اعتماد هستید زیرا یک حساب کاربری با نام کاربری و رمز عبور ارائه شده توسط ISP خود دارید. شما به عنوان یک مشتری مجاز به استفاده از سرور SMTP برای ارسال پیام های ایمیل هستید.

نیاز به اتصال از یک آدرس IP خاص یا محدوده ای از آدرس های IP دارد. ISP شما ممکن است به افرادی که مستقیماً به شبکه متصل نیستند اجازه دسترسی به سرور SMTP را بدهد. به عنوان مثال، می تواند یک کاربر از راه دور در دفتر باشد. مشکل اصلی این است که آدرس های IP پویا در بسیاری از مکان ها استفاده می شود. با این حال، نمی توانید مطمئن باشید که هر بار که متصل می شوید آدرس IP یکسانی دارید. برخی از سازمان ها ممکن است بلوک یا محدوده ای از آدرس های IP را رزرو کرده باشند. ISP ممکن است کسانی را که از این آدرس های IP متصل می شوند، کاربران تایید شده در نظر بگیرد. او می تواند اطلاعات بیشتری ارائه دهد.

سناریوهای رله احتمالی زیادی وجود دارد. در زیر رایج ترین موقعیت ها آورده شده است. شاید یکی از آنها شبیه شما باشد.

وضعیت	رله هست؟
شما در خانه هستید و یک حساب ISP دارید که به @proseware.com ختم می شود، که از طریق شماره گیری، کابل یا مودم DSL به آن متصل می شوید. شما در حال ارسال پیام به شخص دیگری هستید که آدرس ایمیل او نیز به @proseware.com ختم می شود.
مانند حالت اول، با این تفاوت که برای شخصی که آدرس ایمیلش به @adatum.com ختم می‌شود پیام ارسال می‌کنید.	بله، اما مسدود نیست. شما مستقیماً به یک ISP متصل می‌شوید و در نتیجه این اختیار را به دست می‌آورید که از طریق سرور SMTP آن (ایمیل خروجی) به هر آدرسی، بدون توجه به مکان صندوق پستی گیرنده، نامه ارسال کنید.
سر کاری. آدرس ایمیل کاری شما به @thephone-company.com ختم می شود و یک حساب ISP خانگی دارید که به @proseware.com ختم می شود و از طریق شماره گیری، کابل یا مودم DSL به آن متصل می شود. در Outlook، همان تنظیمات سرور SMTP را دارید که در خانه پیکربندی شده است. شما در حال ارسال پیام به شخصی هستید که آدرس ایمیل او نیز به @proseware.com ختم می شود.	خیر نامه شما به روش معمول پردازش می شود.
شما در یک هتل اقامت کرده اید یا از یک ترمینال اینترنتی در فرودگاه استفاده کرده اید که دسترسی به اینترنت را فراهم می کند. شما یک حساب ISP خانگی دارید که به @proseware.com ختم می شود که از طریق شماره گیری، کابلی یا مودم DSL با آن ارتباط برقرار می کنید. در Outlook، همان تنظیمات سرور SMTP را دارید که در خانه پیکربندی شده است. شما در حال ارسال پیام به شخص دیگری هستید که آدرس ایمیل او نیز به @proseware.com ختم می شود.	خیر نامه شما به روش معمول پردازش می شود.
مانند بالا، با این تفاوت که برای شخصی که آدرس ایمیلش به @adatum.com ختم می شود پیام ارسال می کنید.	بله، و این پیام را می توان به عنوان ایمیل ارسالی مسدود کرد. شما در حال تلاش برای استفاده از سرور SMTP خانگی (ایمیل خروجی) ISP خود هستید، اگرچه به شبکه آنها متصل نیستید. سرور SMTP نمی تواند شما را به عنوان مشترک مجاز ISP احراز هویت کند. علاوه بر این، از سرور SMTP می‌خواهید پیام را بپذیرد و به سرور SMTP دیگری متصل شود تا آن را به صندوق پستی گیرنده تحویل دهد.

راه حل ها

اگر وضعیت شما به عنوان یک رله در نظر گرفته می شود، باید پیام را از طریق سروری که در حال حاضر به آن متصل هستید ارسال کنید. یعنی اگر در محل کار یا خارج از خانه هستید و از ISP خود برای اتصال به اینترنت استفاده نمی کنید، اما می خواهید پیامی را از حساب خانه خود که توسط آن ISP ارائه شده است ارسال کنید، باید تنظیمات حساب ایمیل خود را تغییر دهید تا به آن اشاره کنید. آن سرور SMTP، که در جایی که هستید از آن استفاده می کنید (به عنوان مثال، یک سرور SMTP در حال کار). برای دستورالعمل های گام به گام به مقاله مراجعه کنید.

اگر این کار نمی کند، یا اگر ترجیح می دهید از یک حساب خانگی استفاده کنید، باید با ISP خود تماس بگیرید و بپرسید که آیا گزینه هایی که قبلا توضیح داده شد در دسترس شما هستند یا خیر. با توجه به دو محدودیت اول (نیاز به احراز هویت SMTP دارد و شما را ملزم می کند ابتدا به سرور POP3 ورودی ISP متصل شوید)، می توانید تنظیمات حسابدر Outlook. برای دستورالعمل ها به تغییر تنظیمات حساب ایمیل خود مراجعه کنید.

پیام ها هنوز ارسال نشده اند؟

شما تنظیمات SMTP را در Outlook تغییر داده اید یا تنظیماتی را پیدا کرده اید که به شما امکان می دهد پیام های ایمیل ارسال کنید. اما هنوز نمی توانید ایمیل بفرستید و پیغام خطا دریافت کنید.

ممکن است همه کارها را درست انجام داده باشید، اما مدیران شبکه از برخی ویژگی های امنیتی دیگر برای جلوگیری از جعل هویت استفاده می کنند. جعل هویت به سادگی راهی برای ارسال یک ایمیل است که در آن شما شخصی که هستید را پنهان می کنید.

در Outlook، مانند اکثر برنامه‌های ایمیل، می‌توانید یک «نام نمایشی» و یک آدرس ایمیل برگشتی را مشخص کنید که هنگام پاسخ به پیام شما ظاهر شود. در هرزنامه ها، این فیلدها تقریباً همیشه حاوی اطلاعات نادرست هستند. آیا واقعاً باور دارید که پیام‌های سریع ثروتمند شدن از سوی یک سوپر مدل یا یک رهبر جهانی آمده است؟

برای جلوگیری از جعل هویت، برخی از ISP ها توانایی درج اطلاعات نادرست را در قسمت آدرس در پاسخ ها محدود می کنند. به عنوان مثال، اگر نام دامنه ISP شما به proseware.com ختم شود، ISP ممکن است شما را از ارائه آدرس بازگشت منع کند. [ایمیل محافظت شده]. این محدودیت به همان اندازه که قبلا توضیح داده شد استفاده نمی شود، اما می تواند برای همه کاربران صرف نظر از مکان و روش اتصال آنها اعمال شود. در این صورت هیچ جایگزینی وجود ندارد. اگر مدیر سرور از این روش استفاده می کند، باید دامنه مربوط به اتصال فعلی خود را در آدرس برگشتی مشخص کنید.