Postfix، VPN و smarthost: صف، فایروال نیست

نگه داشتن ایمیل در صف تا بالا آمدن VPN یک مسئله زمان‌بندی است، و راه‌حل معمول متوقف کردن Postfix، تعویض main.cf و روشن کردن دوباره آن است. این کار می‌کند و شکل اشتباهی دارد، چون دو الزام را در هم می‌آمیزد: اینکه چه وقت باید تحویل را امتحان کرد، و اینکه کدام مسیر شبکه اجازه دارد آن را ببرد. دومی تصمیم فایروال است و هیچ دستور Postfix نمی‌تواند آن را بگیرد. وقتی این دو جدا شوند، هر کدام پاسخ کوچک و آزمون‌پذیری دارند.

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

دو الزامی که مردم در یکی ادغام می‌کنند

رله به Postfix می‌گوید ایمیل را کجا تحویل دهد؛ relayhost = [smtp.corp.example]:587 یک میزبان و پورت را نام می‌برد و براکت‌ها انتخاب مبتنی بر MX را برای آن گام بعدی سرکوب می‌کنند. مسیر به هسته می‌گوید بسته‌ها کجا اجازه رفتن دارند. یک relayhost درست بدون محدودیت مسیر باز هم به Postfix اجازه می‌دهد وقتی جدول مسیریابی اجازه دهد مستقیماً به اینترنت برسد، و فایروال درست با relayhost اشتباه ایمیل را به جای اشتباه می‌فرستد. هیچ‌کدام دیگری را ایجاب نمی‌کند.

نقشه‌های انتقال، بازنویسی‌های هر فرستنده و رله‌های پشتیبان هر یک همان خوانش را سزاوارند. relayhost پایدار دلیل آن نیست که هر مسیر تحویل پیکربندی‌شده از آن استفاده می‌کند، و مسیر پشتیبانی که رله را دور می‌زند همان خرابی با استتار بهتر است.

defer_transports در واقع چه می‌کند

defer_transports پیام‌ها را برای انتقال‌های نام‌برده نگه می‌دارد تا هیچ تلاش تحویلی انجام نشود مگر آنکه یک دور صف به آن‌ها برسد. این یک کنترل زمان‌بندی است و تخلیه صف آن را لغو می‌کند؛ این طراحی است نه عیب. از نام‌های واقعی انتقال در master.cf استفاده کنید، چون یک انتقال سفارشی یا یک انتقال رله با نام جداگانه فقط به این دلیل که برنامه‌اش SMTP هم صحبت می‌کند پوشش داده نمی‌شود. تلاش مجدد عادی مکانیزم دیگری است: با مسیر fail-closed، تلاش‌های تحویل صرفاً شکست می‌خورند و در صف می‌مانند، بدون هیچ دستور تعویقی.

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

مسیر را در لایه شبکه اعمال کنید

این محدودیت به مرز خروجی محلی یا درون یک فضای نام شبکه جدا تعلق دارد. باید نشانی‌های واقعی رله، انتقال و پورت را پوشش دهد، از جمله IPv6 اگر فعال است، چون قاعده‌ای که TCP 25 را مسدود می‌کند برای رله روی 587 یا 465 کاری نمی‌کند. loopback و مسیرهای ارسال محلی را جدا نگه دارید تا خود صف به کار ادامه دهد. سیاست باید بسته بماند وقتی مسیر تونل ناپدید می‌شود یا زیر نام واسط دیگری دوباره ظاهر می‌شود.

رویداد بالا آمدن واسط اثبات نمی‌کند که رله از آن طریق در دسترس است. به همین دلیل قلابی که پیوند را بررسی و سپس صف را تخلیه می‌کند یک راحتی است نه تضمین: پیوند می‌تواند بین بررسی و تلاش تحویل تغییر کند.

با یک پیام بی‌خطر اثباتش کنید

یک پیام بی‌خطر با VPN پایین بفرستید، سپس postqueue -p را برای دلیل تعویق و شناسه صف بررسی کنید. مسیر مورد نظر را بازگردانید و یک دور صف کنترل‌شده بخواهید و ببینید پیام از رله خارج می‌شود نه از جای دیگر. سپس مسیر را دوباره در میانه پرواز بشکنید و تأیید کنید پیام به صف برمی‌گردد. پیش از تصمیم درباره اینکه یک قطعی چقدر می‌تواند طول بکشد maximal_queue_lifetime را مرور کنید، چون مقدار صفر یعنی یک تلاش نه نگهداری نامحدود.

سن صف و مصرف دیسک را پایش کنید. سیاستی که منتظر VPN است اگر کسی متوجه نشود صف از جمعه در حال رشد است به قطعی ایمیل تبدیل می‌شود.

رله، انتقال، قاعده فایروال و طول عمر را با هم ثبت کنید. آن چهار چیز چیدمان را توصیف می‌کنند؛ هر یک از آن‌ها به‌تنهایی یک حدس را توصیف می‌کند.