Postfix କୁ ମେଲ୍ ରିଲେ ଆଡ଼କୁ ନିର୍ଦ୍ଦେଶ କରନ୍ତୁ, ୱେବ୍ ପ୍ରକ୍ସି ଆଡ଼କୁ ନୁହେଁ

relayhost = proxy.example.net:3128 ଦୁଇ ପ୍ରାନ୍ତ କଥା କହିବା ଆରମ୍ଭ ନହେବା ପର୍ଯ୍ୟନ୍ତ ବିଶ୍ୱାସନୀୟ ଦେଖାଯାଏ। Postfix ଏକ SMTP ସାଥୀ ଆଶା କରେ। 3128 ରେ ଥିବା ୱେବ୍ ପ୍ରକ୍ସି ଏକ HTTP ପ୍ରକ୍ସି ଅନୁରୋଧ ଆଶା କରେ। କାହାକୁ ମଧ୍ୟ ଆଶା କରାଯାଉଥିବା କଥାବାର୍ତ୍ତା ମିଳେ ନାହିଁ।

ଯଦି ନେଟୱାର୍କ ଏକ ଅନୁମୋଦିତ ମେଲ୍ ରିଲେ ଯୋଗାଏ, ତେବେ ତା ପରିବର୍ତ୍ତେ ସେହି SMTP ସେବା ବିନ୍ୟାସ କରନ୍ତୁ। ସାଧାରଣ ରୂପ ହେଉଛି:

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

ହୋଷ୍ଟନାମ ଏବଂ ପୋର୍ଟ ଉଦାହରଣ। ବ୍ରାକେଟ୍ ସେହି ରିଲେ ନାମ ପାଇଁ MX ସନ୍ଧାନକୁ ଦମନ କରେ। ସେମାନେ HTTP CONNECT, TLS କିମ୍ବା ପ୍ରମାଣୀକରଣ ଯୋଡ଼ନ୍ତି ନାହିଁ। ରିଲେର ଆବଶ୍ୟକ submission, SASL ଏବଂ TLS ସେଟିଂସ୍ ଅଲଗା ବିନ୍ୟାସ କରନ୍ତୁ।

ଦୁଇଟି ଖାତା ମଧ୍ୟ ଅଲଗା ହୋଇପାରେ। ୱେବ୍ ପ୍ରକ୍ସି ଗ୍ରହଣ କରୁଥିବା ପାସୱାର୍ଡ ସ୍ୱୟଂଚାଳିତ ଭାବେ ମେଲ୍ submission ପ୍ରମାଣପତ୍ର ନୁହେଁ, ଏବଂ ସଂଯୋଗ ଗ୍ରହଣ କରିବା ପରେ ମଧ୍ୟ ରିଲେ ପ୍ରେରକକୁ ଅସ୍ୱୀକାର କରିପାରେ।

ଯଦି ଏକମାତ୍ର ଅନୁମୋଦିତ ପଥ ଏକ ଟନେଲ୍ ହୁଏ?

HTTP ପ୍ରକ୍ସି ଗନ୍ତବ୍ୟ ଏବଂ ପୋର୍ଟକୁ ଅନୁମତି ଦେଲେ SMTP କୁ CONNECT ମାଧ୍ୟମରେ ବହନ କରିପାରେ। ଏହା କୌଣସି SMTP କ୍ଲାଏଣ୍ଟକୁ CONNECT ସୃଷ୍ଟି କରିବାକୁ ବାଧ୍ୟ କରେ ନାହିଁ। curl ପରି ସାଧନରେ ସ୍ପଷ୍ଟ ପ୍ରକ୍ସି-ଟନେଲ୍ ବିକଳ୍ପ ଅଛି; Postfix ର relayhost ସେଟ୍ କରିବା ଅନ୍ୟ ଇଣ୍ଟରଫେସ୍।

ଏକ ସ୍ଥିର SSH ଫରୱାର୍ଡ କିମ୍ବା ଉଦ୍ଦେଶ୍ୟ-ନିର୍ମିତ ସ୍ଥାନୀୟ ପରିବହନ ଆଡାପ୍ଟର ଏକ ଅନୁମୋଦିତ SMTP ସେବାକୁ ସ୍ଥାନୀୟ TCP ଅନ୍ତିମ ବିନ୍ଦୁ ଭାବରେ ପ୍ରକାଶ କରିପାରେ। ସେହି ଡିଜାଇନରେ Postfix ଅନ୍ତିମ ବିନ୍ଦୁ ସହିତ SMTP କହେ, ଏବଂ ଆଡାପ୍ଟର ଅନ୍ୟ ପରିବହନ ଯୋଗାଏ। ଏହାକୁ ସୀମିତ ରଖନ୍ତୁ ଏବଂ ଉଦ୍ଦିଷ୍ଟ ମେଲ୍ ସର୍ଭରର TLS ପରିଚୟ ରକ୍ଷା କରନ୍ତୁ: ସଂଯୋଗ ଠିକଣାକୁ loopback କୁ ବଦଳାଇଲେ ନାମ-ଆଧାରିତ ପ୍ରମାଣପତ୍ର ନୀତି ପ୍ରଭାବିତ ହୋଇପାରେ।

ନେଟୱାର୍କ ଅପରେଟର ଯୋଗାଉଥିବା ସେବା ଯଦି ମେଲ୍ ରିଲେ, ତେବେ ତାହାକୁ ପ୍ରାଥମିକତା ଦିଅନ୍ତୁ। ଏହା ଧାଡ଼ି, ପ୍ରେରକ ନୀତି ଏବଂ ବିତରଣ ତ୍ରୁଟିକୁ SMTP ବୁଝୁଥିବା ଘର ଦିଏ। କେବଳ ୱେବ୍ ପ୍ରକ୍ସି ସେଟିଂ ଏହି ମେଲ୍ କାର୍ଯ୍ୟଗୁଡ଼ିକରୁ କିଛି ଦିଏ ନାହିଁ।