Спрямуйте Postfix на поштовий релей, а не на вебпроксі

relayhost = proxy.example.net:3128 виглядає правдоподібно, доки обидві сторони не почнуть розмовляти. Postfix очікує SMTP-партнера. Вебпроксі на 3128 очікує запит HTTP-проксі. Ніхто не отримує розмови, на яку чекав.

Якщо мережа надає схвалений поштовий релей, налаштуйте натомість ту службу SMTP. Типова форма така:

relayhost = [smtp-relay.example.net]:587

Ім'я хоста й порт — приклади. Квадратні дужки вимикають пошук MX для цього імені релея. Вони не додають HTTP CONNECT, TLS чи автентифікацію. Налаштуйте окремо потрібні релею параметри submission, SASL і TLS.

Два облікові записи теж можуть різнитися. Пароль, прийнятий вебпроксі, не стає автоматично обліковими даними для надсилання пошти, і релей може відхилити відправника навіть після прийняття з'єднання.

А якщо єдиний схвалений шлях — тунель?

HTTP-проксі може передавати SMTP через CONNECT, якщо дозволяє пункт призначення й порт. Це не змушує довільний SMTP-клієнт створювати CONNECT. Такий інструмент, як curl, має явну опцію проксі-тунелю; налаштування relayhost у Postfix — інший інтерфейс.

Фіксоване SSH-перенаправлення або спеціально створений локальний транспортний адаптер можуть представити одну схвалену службу SMTP як локальну кінцеву точку TCP. У такій схемі Postfix говорить SMTP з кінцевою точкою, а адаптер забезпечує інший транспорт. Тримайте його обмеженим і зберігайте TLS-ідентичність цільового поштового сервера: зміна адреси з'єднання на loopback може вплинути на політику сертифікатів на основі імені.

Віддавайте перевагу поштовому релею, коли це послуга, яку надає оператор мережі. Він дає черзі, політиці відправника й помилкам доставки дім, що розуміє SMTP. Лише налаштування вебпроксі не дає жодної з цих поштових функцій.