محتوای آموزشی وبلاگ نت‌آرام
ایمیل‌های سایت یا هشدارهای سرور ارسال نمی‌شوند و در گزارش پیامی مانند
Connection timed out به مقصد پورت ۲۵ می‌بینید. ممکن است اتصال خروجی SMTP محدود شده باشد؛ اما از روی یک timeout نمی‌توان گفت حتماً ارائه‌دهنده سرور آن را بسته است. مقصد، DNS، فایروال داخلی، مسیر شبکه یا خود سرویس ایمیل هم می‌توانند دخیل باشند.در این آموزش اول محل توقف را پیدا می‌کنیم، سپس یا محدودیت واقعی را در مسیر مجاز رفع می‌کنیم یا از یک سرویس واسط ارسال ایمیل، یعنی SMTP relay، استفاده می‌کنیم. دستورها برای یک سرور لینوکسی با Postfix هستند. این موضوع در سرور مجازی ایران و سرور اختصاصی ایران کاربرد دارد. اگر ایمیل را cPanel، DirectAdmin یا برنامه دیگری مدیریت می‌کند، تنظیمات همان ابزار را به کار ببرید؛ تغییر مستقیم تنظیمات Postfix ممکن است توسط پنل بازنویسی شود یا به سرویس کاربران دیگر آسیب بزند.
۱. پورت ۲۵ و ۵۸۷ یک کار را انجام نمی‌دهند
وقتی سرور ایمیل شما پیام را مستقیماً به سرور ایمیل دامنه گیرنده تحویل می‌دهد، معمولاً به پورت TCP شماره ۲۵ مقصد وصل می‌شود. پورت ۵۸۷ معمولاً برای تحویل پیامِ احراز هویت‌شده به سرویس ارسال استفاده می‌شود. نمی‌توان صرفاً عدد ۲۵ را برای هر سرور مقصد به ۵۸۷ تغییر داد؛ مقصد باید سرویس submission و حساب مجاز شما را ارائه کند.
ممکن است اتصال خروجی ۲۵ محدود باشد اما دریافت ایمیل روی پورت ورودی ۲۵ همچنان کار کند؛ این دو مسیر جدا هستند. همچنین برقرارشدن اتصال به پورت، تضمین نمی‌کند پیام در صندوق ورودی قرار می‌گیرد. اعتبار دامنه، تنظیم SPF و DKIM، سیاست گیرنده و پاسخ سرویس واسط نیز بر تحویل اثر دارند.
۲. از گزارش واقعی همان پیام شروع کنید
ابتدا وضعیت Postfix و صف را ببینید:
کد / دستورsystemctl status postfix --no-pager
postqueue -p
در خروجی صف، شناسه پیام و علت تأخیر را بخوانید. آدرس فرستنده و گیرنده اطلاعات خصوصی‌اند؛ آن‌ها را در گزارش عمومی قرار ندهید.
deferred یعنی تحویل فعلاً عقب افتاده، نه اینکه پیام حتماً برای همیشه از بین رفته است. خطای رمز، رد شدن فرستنده و timeout شبکه راه‌حل یکسانی ندارند.گزارش همان بازه را نیز ببینید:
کد / دستورsudo journalctl -u postfix --since '1 hour ago' --no-pager
در برخی توزیع‌ها گزارش ایمیل در فایل دیگری مانند
/var/log/mail.log ثبت می‌شود. Connection timed out نشانه نگرفتن پاسخ در زمان تعیین‌شده است؛ Connection refused معمولاً پاسخ رد اتصال است؛ خطای 535 به احراز هویت اشاره می‌کند. برای مورد آخر راهنمای خطای SMTP 535 را دنبال کنید.۳. مسیر مقصد و اتصال خروجی را جداگانه آزمایش کنید
از یک دامنه آزمایشی متعلق به خودتان یا دامنه‌ای که اجازه آزمون آن را دارید، رکورد MX بگیرید. این مثال را با دامنه واقعی جایگزین کنید:
کد / دستورdig example.com MX
کد پاسخ DNS و نام میزبان‌های MX را بخوانید. نبود رکورد MX صریح همیشه به معنی نبود امکان تحویل نیست؛ بعضی دامنه‌ها با قواعد DNS به نشانی خود دامنه رجوع می‌کنند، و رکورد Null MX نیز اعلام می‌کند دامنه ایمیل نمی‌پذیرد.
SERVFAIL یا timeout DNS را ابتدا جداگانه رفع کنید.اگر میزبان MX مناسب را می‌شناسید و ابزار
کد / دستورnc نصب است، از خود سرور اتصال TCP را آزمایش کنید:nc -vz -w 5 mx.example.com 25
نام نمونه را با مقصد مجاز واقعی جایگزین کنید. پیام موفقیت یعنی دست‌کم اتصال TCP به آن مقصد برقرار شده است؛ timeout می‌تواند در هر بخش مسیر رخ دهد و
refused معمولاً پاسخ رد از مقصد یا میان‌راه است. برای نتیجه قابل اتکاتر، در صورت مجازبودن، با یک مقصد مستقل دیگر و زمان مشابه نیز امتحان کنید. آزمون را بی‌وقفه تکرار نکنید و هیچ ایمیل ناخواسته‌ای نفرستید.اگر فقط IPv6 مشکل دارد، گزارش DNS و مسیریابی IPv4 و IPv6 را جداگانه مقایسه کنید. در صورت استفاده از UFW، وضعیت سیاست خروجی را ببینید:
کد / دستورsudo ufw status verbose
اگر UFW فعال نیست، از ابزار واقعی فایروال نصب خود استفاده کنید. وجود قانون باز برای پورت ورودی به معنی بازبودن مسیر خروجی نیست. محدودیت ممکن است در فایروال سرور، پنل شبکه، ارائه‌دهنده یا سمت مقصد باشد. از ارائه‌دهنده خود درباره سیاست خروجی TCP ۲۵ و روش مجاز رفع محدودیت سؤال کنید؛ برای همه شرکت‌ها یک سیاست ثابت فرض نکنید.
۴. اگر پورت ۲۵ محدود است، چه انتخابی داریم؟
اگر به ارسال مستقیم نیاز دارید، پس از تأیید سیاست ارائه‌دهنده و آماده‌بودن هویت دامنه، درخواست دسترسی خروجی مناسب بدهید. در غیر این صورت یک سرویس ارسال معتبر انتخاب کنید که ارسال از دامنه شما و پورت در دسترس سرور را پشتیبانی می‌کند. ارائه‌دهنده باید آدرس SMTP، نوع TLS، نام کاربری، رمز یا کلید مخصوص و رکوردهای لازم دامنه را اعلام کند.
برای ایمیل یک برنامه خاص، معمولاً می‌توانید همین اطلاعات را در تنظیم SMTP همان برنامه وارد کنید. اگر فقط Postfix محلی پیام‌ها را می‌فرستد و قصد دارید تمام ایمیل خروجی آن از واسط عبور کند، مراحل نمونه زیر یک راه عملی است. همه ارائه‌دهندگان پورت ۵۸۷ را باز نمی‌گذارند؛ ابتدا مقصد واقعی را آزمایش کنید:
کد / دستورnc -vz -w 5 smtp.example.com 587
برای سرویس دارای STARTTLS روی ۵۸۷، با نسخه سازگار OpenSSL می‌توانید گواهی و نام میزبان را هم بررسی کنید:
کد / دستورopenssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -verify_hostname smtp.example.com -verify_return_error
نام نمونه را با نام دقیق ارائه‌دهنده عوض کنید. موفقیت ارتباط و تأیید گواهی باید در خروجی دیده شود؛ پس از آزمون با
QUIT یا کلیدهای پایان نشست از آن خارج شوید. این آزمون پیام نمی‌فرستد و نباید رمز را در آن وارد کنید. پورت ۴۶۵ معمولاً TLS ضمنی دارد و با همین دستور -starttls smtp آزمایش نمی‌شود؛ تنظیم دقیق را از ارائه‌دهنده بگیرید.۵. تنظیم نمونه Postfix برای relay روی ۵۸۷
این نمونه مخصوص نصب ساده‌ای است که تمام ایمیل خروجی راه دورش باید از یک relay عبور کند؛ اگر transport اختصاصی، چند فرستنده با حساب متفاوت یا پنل مدیریتی دارید، ابتدا روش مناسب همان محیط را پیدا کنید. از تنظیم قبلی نسخه قابل بازگشت بگیرید و نام فایل پشتیبان را طوری انتخاب کنید که از قبل وجود نداشته باشد:
کد / دستورsudo cp -an /etc/postfix/main.cf /root/main.cf.before-smtp-relay
postconf -m
دستور دوم نوع‌های جدول قابل استفاده را نشان می‌دهد. مثال زیر از
hash استفاده می‌کند؛ اگر در خروجی نیست، نوع پشتیبانی‌شده و postmap متناسب با توزیع را طبق راهنمای Postfix انتخاب کنید. اگر فایل پشتیبان نمونه از قبل وجود دارد، نام تازه‌ای انتخاب کنید و محتوای نسخه قبلی را بازنویسی نکنید.یک فایل جدید و خصوصی برای رمز بسازید. دستور زیر در صورت وجود فایل هم‌نام باید شکست بخورد؛ اگر شکست خورد، دلیل را بررسی کنید و فایل موجود را پاک یا بازنویسی نکنید:
کد / دستورsudo sh -c 'umask 077; set -C; : > /etc/postfix/netaram-relay-passwd'
sudoedit /etc/postfix/netaram-relay-passwd
در ویرایشگر یک خط با آدرس و اطلاعات واقعی سرویس بگذارید. مقدارهای زیر فقط جای‌نگهدارند و نباید به‌عنوان حساب واقعی استفاده شوند:
کد / دستور[smtp.example.com]:587 USERNAME:PASSWORD
براکت، نام و پورت باید دقیقاً با مقصد relay در تنظیم بعدی یکسان باشند. رمز واقعی را در فرمان، تاریخچه shell، تیکت یا فایل عمومی سایت قرار ندهید. پیش از ساخت جدول، فایل‌های هم‌نام را ببینید:
کد / دستورsudo ls -l /etc/postfix/netaram-relay-passwd*
در این مرحله باید فقط فایل متنی تازه‌ای را که ساخته‌اید ببینید. اگر فایل جدول هم‌نام از قبل وجود دارد، بدون شناسایی مالک و محتوای آن ادامه ندهید؛
کد / دستورpostmap می‌تواند جدول را بازنویسی کند. پس از اطمینان:sudo postmap hash:/etc/postfix/netaram-relay-passwd
sudo ls -l /etc/postfix/netaram-relay-passwd*
فایل رمز و جدول تولیدشده باید فقط برای کاربر مجاز قابل خواندن باشند. اگر نوع جدول سیستم شما متفاوت است، نام فایل خروجی و دستور را با همان نوع تطبیق دهید. حالا با ویرایشگر، فقط تنظیمات مربوط را در
کد / دستور/etc/postfix/main.cf اضافه یا مقادیر موجود همان گزینه‌ها را اصلاح کنید:relayhost = [smtp.example.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/netaram-relay-passwd
smtp_sasl_tls_security_options = noanonymous
smtp_tls_security_level = secure
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
مسیر CA در خط آخر نمونه متداول اوبونتو است؛ باید فایل گواهی‌های معتبر سیستم خود را پیدا کنید و آن را برای توزیع خود جایگزین کنید. سطح
secure برای relay مشخص، TLS و بررسی هویت گواهی را الزام می‌کند. اگر نام گواهی با نام relay سازگار نیست، نام اعلام‌شده توسط ارائه‌دهنده و زنجیره گواهی را اصلاح کنید؛ اعتبارسنجی را برای عبور از خطا خاموش نکنید. تنظیمات موجودِ transport_maps یا relay وابسته به فرستنده ممکن است بر این مسیر اثر بگذارند؛ قبل از تغییر آن‌ها را بشناسید.پیش از بارگذاری، صحت کلی و وضعیت سرویس را ببینید:
کد / دستورsudo postfix check
sudo postfix reload
systemctl status postfix --no-pager
اگر
postfix check خطا داد، ابتدا آن را رفع کنید و reload نکنید. سپس یک پیام آزمایشی با ابزار خود برنامه به صندوقی که متعلق به خودتان است بفرستید. گزارش همان پیام و شناسه صف را ببینید؛ خطای ۵۳۵ معمولاً یعنی اطلاعات ورود یا سیاست حساب باید اصلاح شود، و خطای گواهی یعنی نام یا زنجیره TLS را باید بررسی کنید.۶. رسیدن پیام و بازگشت را تأیید کنید
فقط موفقیت دستور ارسال کافی نیست. بررسی کنید سرویس واسط پیام را پذیرفته، پیام به صندوق آزمایشی رسیده و در بخش مشخصات پیام نتیجه احراز هویت دامنه با تنظیمات مورد انتظار هماهنگ است. اگر پیام در صف مانده، علت تازه را در
کد / دستورpostqueue -p و گزارش Postfix بخوانید. برای تلاش مجدد یک پیام مشخص پس از رفع علت، می‌توانید شناسه همان پیام آزمایشی را جایگزین کنید:sudo postqueue -i QUEUE_ID
این دستور پیام مشخص را برای تلاش دوباره زمان‌بندی می‌کند، نه اینکه تحویل را تضمین کند. ارسال مکرر کل صف ممکن است بار و پیام تکراری ایجاد کند. اگر لازم شد به حالت قبل برگردید، تنظیمات ثبت‌شده را در زمان مناسب بازگردانید، بررسی و reload کنید؛ نسخه پشتیبان و اطلاعات محرمانه را در محل خصوصی نگه دارید. اگر ارسال فقط از یک برنامه انجام می‌شود، مطمئن شوید تغییر کلی Postfix واقعاً انتخاب مناسبی برای همه سرویس‌های سرور بوده است.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام