Насочете 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. Само настройка на уеб прокси не предоставя нито една от тези пощенски функции.