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 മനസ്സിലാക്കുന്ന ഒരു വീട് നൽകുന്നു. വെബ് പ്രോക്സി ക്രമീകരണം മാത്രം ഈ മെയിൽ പ്രവർത്തനങ്ങളിൽ ഒന്നും നൽകുന്നില്ല.