Направьте 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. Одна лишь настройка веб-прокси не даёт ни одной из этих почтовых функций.