Ուղղեք 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-ի նման գործիքն ունի պրոքսի թունելի բացահայտ ընտրանք. Postfix-ի relayhost-ի կարգավորումը այլ ինտերֆեյս է։

Ֆիքսված SSH փոխանցումը կամ հատուկ նախատեսված տեղական տրանսպորտային ադապտերը կարող են մեկ հաստատված SMTP ծառայություն բացահայտել որպես տեղական TCP վերջնակետ։ Այդ ձևավորման մեջ Postfix-ը SMTP-ով խոսում է վերջնակետի հետ, իսկ ադապտերը ապահովում է մյուս տրանսպորտը։ Պահեք այն սահմանափակ և պահպանեք նախատեսված փոստային սերվերի TLS ինքնությունը. կապի հասցեն loopback-ի փոխելը կարող է ազդել անվան վրա հիմնված վկայագրի քաղաքականության վրա։

Նախընտրեք փոստային ռելեն, երբ դա այն ծառայությունն է, որ տրամադրում է ցանցի օպերատորը։ Այն հերթին, ուղարկողի քաղաքականությանը և առաքման սխալներին տալիս է SMTP հասկացող տուն։ Միայն վեբ պրոքսիի կարգավորումը չի ապահովում այդ փոստային գործառույթներից ոչ մեկը։