Skieruj Postfix na przekaźnik poczty, a nie na proxy internetowe

relayhost = proxy.example.net:3128 brzmi sensownie, dopóki obie strony nie zaczną rozmawiać. Postfix oczekuje partnera SMTP. Proxy internetowe na porcie 3128 oczekuje żądania proxy HTTP. Żadne nie otrzymuje rozmowy, na którą czekało.

Jeśli sieć udostępnia zatwierdzony przekaźnik poczty, skonfiguruj zamiast tego tę usługę SMTP. Typowy kształt to:

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

Nazwa hosta i port są przykładami. Nawiasy kwadratowe wyłączają wyszukiwanie MX dla tej nazwy przekaźnika. Nie dodają HTTP CONNECT, TLS ani uwierzytelniania. Skonfiguruj osobno wymagane ustawienia submission, SASL i TLS przekaźnika.

Oba konta mogą się też różnić. Hasło akceptowane przez proxy internetowe nie jest automatycznie poświadczeniem wysyłania poczty, a przekaźnik może odrzucić nadawcę nawet po przyjęciu połączenia.

A jeśli jedyną zatwierdzoną drogą jest tunel?

Proxy HTTP może przenosić SMTP przez CONNECT, gdy zezwala na cel i port. Nie powoduje to, że dowolny klient SMTP generuje CONNECT. Narzędzie takie jak curl ma jawną opcję tunelu proxy; ustawienie relayhost w Postfixie to inny interfejs.

Stałe przekierowanie SSH lub celowo zbudowany lokalny adapter transportowy może udostępnić jedną zatwierdzoną usługę SMTP jako lokalny punkt końcowy TCP. W takim projekcie Postfix rozmawia SMTP z punktem końcowym, a adapter zapewnia drugi transport. Ogranicz go i zachowaj tożsamość TLS zamierzonego serwera poczty: zmiana adresu połączenia na loopback może wpłynąć na politykę certyfikatów opartą na nazwie.

Preferuj przekaźnik poczty, gdy jest to usługa dostarczana przez operatora sieci. Daje kolejce, polityce nadawcy i błędom doręczania dom rozumiejący SMTP. Sama konfiguracja proxy internetowego nie zapewnia żadnej z tych funkcji poczty.