رفع خطای no SASL authentication mechanisms در Postfix

شرح مسئله

سرور میل روی Debian/Ubuntu بالا می‌آید، پورت ۲۵ کار می‌کند و ایمیل‌های ورودی هم تحویل داده می‌شوند، اما هیچ‌کدام از کاربران نمی‌توانند از Thunderbird یا Outlook ارسال کنند. کلاینت روی پورت ۵۸۷ وصل می‌شود، هندشیک STARTTLS را انجام می‌دهد، ولی یا لیست AUTH در پاسخ EHLO وجود ندارد، یا بعد از تلاش برای احراز هویت اتصال بی‌دلیل قطع می‌شود.

در /var/log/mail.log چیزی شبیه این می‌بینید:

postfix/submission/smtpd[24112]: connect from unknown[203.0.113.45]
postfix/submission/smtpd[24112]: Anonymous TLS connection established from unknown[203.0.113.45]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
postfix/submission/smtpd[24112]: warning: SASL: Connect to private/auth failed: No such file or directory
postfix/submission/smtpd[24112]: fatal: no SASL authentication mechanisms
postfix/master[2310]: warning: process /usr/lib/postfix/sbin/smtpd pid 24112 exit status 1
postfix/master[2310]: warning: /usr/lib/postfix/sbin/smtpd: bad command startup -- throttling

سه نشانه کلیدی اینجاست: نبود مسیر private/auth، خطای fatal: no SASL authentication mechanisms و در نهایت throttling که باعث می‌شود master پست‌فیکس سرویس را حدود یک دقیقه خفه کند و کلاینت‌ها فقط تایم‌اوت ببینند. چون این خطا در سطح پروسه smtpd رخ می‌دهد، حتی ارسال داخلی از وب‌اپلیکیشن‌ها روی پورت ۲۵ هم اگر smtpd_sasl_auth_enable روشن باشد متأثر می‌شود.

علت ریشه‌ای

پست‌فیکس روی توزیع‌های خانواده Debian به‌صورت پیش‌فرض سرویس smtpd را در حالت chroot اجرا می‌کند؛ یعنی ریشه فایل‌سیستم این پروسه /var/spool/postfix است، نه /. بنابراین هر مسیری که در پست‌فیکس می‌نویسید نسبت به همان دایرکتوری تفسیر می‌شود.

از طرف دیگر Dovecot سوکت احراز هویت خودش را در مسیر پیش‌فرض /run/dovecot/auth-client می‌سازد. نتیجه این است که وقتی پست‌فیکس می‌خواهد به private/auth وصل شود، به‌دنبال /var/spool/postfix/private/auth می‌گردد و چیزی پیدا نمی‌کند.

سه خطای رایج در همین سناریو وجود دارد و هرکدام ریشه متفاوتی دارد:

• No such file or directory: سوکت اصلاً داخل chroot ساخته نشده است.
• Permission denied: سوکت ساخته شده، ولی مالک یا مجوز آن طوری نیست که کاربر postfix بتواند بنویسد.
• no SASL authentication mechanisms: پست‌فیکس پشتیبانی SASL را کامپایل/نصب ندارد یا smtpd_sasl_type اشتباه تنظیم شده است.

یک نکته ظریف هم این است که این خطا در زمان راه‌اندازی پروسه smtpd رخ می‌دهد، نه در زمان ریستارت Dovecot. پس اگر بعد از رفع مشکل، master همچنان در حالت throttling باشد، ممکن است چند ده ثانیه طول بکشد تا سرویس دوباره سالم شود.

راه‌حل گام‌به‌گام

گام ۱: تشخیص وضعیت فعلی

اول ببینید پست‌فیکس چه چیزی پشتیبانی می‌کند و مسیر فعلی چیست:

postconf -a
postconf smtpd_sasl_type smtpd_sasl_path smtpd_sasl_auth_enable
postconf -M submission/inet
ls -l /var/spool/postfix/private/
doveconf -n | grep -A8 'service auth'

خروجی postconf -a باید شامل dovecot باشد. اگر خالی بود، یعنی ماژول SASL نصب نیست و باید بسته postfix با پشتیبانی SASL نصب شود.

گام ۲: ساخت سوکت داخل chroot

در فایل /etc/dovecot/conf.d/10-master.conf بلوک service auth را به این شکل تغییر دهید تا Dovecot سوکت را مستقیماً داخل مسیر chroot پست‌فیکس بسازد:

service auth {
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }

  unix_listener auth-userdb {
    mode = 0600
    user = dovecot
  }
}

دقت کنید که mode = 0660 و مالک postfix:postfix باشد؛ در غیر این صورت دوباره به Permission denied می‌خورید. همچنین در /etc/dovecot/conf.d/10-auth.conf مطمئن شوید مکانیزم‌های لازم فعال‌اند:

auth_mechanisms = plain login

اگر disable_plaintext_auth = yes باشد (که پیش‌فرض درست و امنی است)، احراز هویت فقط روی اتصال TLS انجام می‌شود؛ پس حتماً سرویس submission را با smtpd_tls_security_level=encrypt تنظیم کنید.

گام ۳: تنظیم main.cf

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = no
smtpd_sasl_security_options = noanonymous
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname

مقدار smtpd_sasl_auth_enable را در main.cf روی no بگذارید و فقط در سرویس submission آن را روشن کنید. این کار جلوی افشای AUTH روی پورت ۲۵ در بستر بدون رمزنگاری را می‌گیرد.

گام ۴: پیکربندی سرویس submission در master.cf

بلوک submission را در /etc/postfix/master.cf به این شکل کامل کنید (ستون chroot همان y است و مشکلی ندارد، چون سوکت داخل chroot ساخته شده):

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_tls_auth_only=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_sasl_path=private/auth
  -o smtpd_reject_unlisted_recipient=no
  -o smtpd_client_restrictions=$mua_client_restrictions
  -o smtpd_helo_restrictions=$mua_helo_restrictions
  -o smtpd_sender_restrictions=$mua_sender_restrictions
  -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
  -o milter_macro_daemon_name=ORIGINATING

استفاده از متغیرهای $mua_*_restrictions باعث می‌شود قوانین پیش‌فرض کانال MUA حفظ شوند و لازم نباشد برای هر سرویس، لیست قوانین را دستی تکرار کنید.

گام ۵: اعمال تغییرات و بررسی سوکت

systemctl restart dovecot
systemctl restart postfix
ls -l /var/spool/postfix/private/auth
postfix check
postfix status

خروجی ls باید چیزی شبیه این باشد:

srw-rw---- 1 postfix postfix 0 Aug 12 09:14 /var/spool/postfix/private/auth

گام ۶: تست دستی احراز هویت

ابتدا فقط چک کنید مکانیزم‌ها در پاسخ EHLO ظاهر می‌شوند:

openssl s_client -starttls smtp -crlf -connect 127.0.0.1:587

بعد از اتصال، دستور EHLO test.local را تایپ کنید. باید خط 250-AUTH PLAIN LOGIN را ببینید. سپس واقعاً یک ایمیل تستی بفرستید:

swaks --to me@example.org --from user@example.com \
  --server 127.0.0.1:587 --tls --auth PLAIN \
  --auth-user user@example.com --auth-password 'secret'

روش بررسی اینکه مشکل واقعاً حل شده است

سه سطح تأیید را با هم چک کنید، نه فقط یکی:

1. لاگ: در /var/log/mail.log دیگر نباید no SASL authentication mechanisms یا bad command startup ببینید. در عوض باید خطوطی مثل sasl_method=PLAIN, sasl_username=user@example.com و SASL PLAIN authentication successful ثبت شود.
2. پروسه‌ها: خروجی systemctl status postfix باید active باشد و postfix status هم بدون خطا برگردد. اگر master همچنان در حالت throttling بود، بعد از حدود ۶۰ ثانیه خودش رفع می‌شود؛ در غیر این صورت postfix reload بزنید.
3. مسیر واقعی کاربر: یک ایمیل از کلاینت واقعی (Thunderbird در ویندوز و یک موبایل) به یک دامنه بیرونی مثل Gmail بفرستید و در هدر پیام بررسی کنید که Received از postfix/submission عبور کرده باشد.

پیشگیری و بهترین روش‌ها

• فایل‌های پیکربندی را در IaC نگه دارید. بلوک سوکت Dovecot و بلوک submission در master.cf باید از یک مخزن نسخه‌بندی‌شده بیایند؛ چون هر آپدیت بسته ممکن است master.cf را بازنویسی کند.
• مانیتورینگ سینتتیک بگذارید. یک چک دوره‌ای با swaks روی پورت ۵۸۷ که احراز هویت را واقعاً تست کند، این خطا را قبل از کاربران می‌گیرد. برای لاگ‌ها هم روی الگوی no SASL authentication mechanisms هشدار بگذارید.
• وابستگی سرویس را صریح کنید. با systemctl edit postfix می‌توانید After=dovecot.service اضافه کنید تا ترتیب بوت قابل پیش‌بینی‌تر شود.
• روی RHEL و مشتقاتش SELinux را چک کنید. اگر بعد از ساخت سوکت همچنان Permission denied می‌گیرید، با ausearch -m avc -ts recent دنبال denial بگردید و context دایرکتوری private را با restorecon -Rv /var/spool/postfix/private اصلاح کنید.
• پورت‌ها را تفکیک کنید. احراز هویت را فقط روی submission (۵۸۷) و در صورت نیاز smtps (۴۶۵) فعال کنید؛ پورت ۲۵ باید بدون AUTH و فقط برای تبادل سرور‌به‌سرور بماند.
• بعد از هر تغییر، postfix check را فراموش نکنید. این دستور خطاهای نگارشی پیکربندی را قبل از ریستارت نشان می‌دهد و از downtime جلوگیری می‌کند.